🚀 go-pugleaf

In article <1993Jan5.060332.5262@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> In article <1993Jan4.200625.5680@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
|> >In article <9300300.29980@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|> >|> 
|> >|> As I noted in a previous article, I don't agree with Scott Turners belief
|> >|> that base class subobjects are objects. To me, these are absurd 
|> >|> consequences, and thus I conclude that the assumption used in deriving them
|> >|> must be flawed.
|> >
|> >Perhaps fjh would specify some of these "absurd consequences".  I
|> >agree with Scott.  Base class subobjects are objects. Anything else 
|> >would be incomprehensible to me.

|> 
|> 	If an 'object' is something whose attributes are computed
|> from its internal state, then clearly subobjects need not
|> be objects. In the sense an object is 'self contained',
|> an 'instance' of an abstract class cannot be an object.
|> 


I completely disagree with the premise. Maybe we are using 
"object" in different senses.  An important "attribute" of
an object (defined as a region of storage by both the C 
standard and the ARM) is its relationship to other regions
of storage.

To take a simple example

	int a[10];

It is an important attribute of a[2] that it is the 3rd
subobject of a 10 element array.  

struct S { int i ; int j ; } s ;

It is an important attribute of s.j that it is the "j" subobject
of s.   

If you prefer to use a word other than "subobject" to describe
this relationship, I suppose you can do so.  But however you
describe it, it is an important concept in the semantics of C++.

Perhaps you disagree that a[2] or s.j are "objects"?  If so
then I think you should reconsider your terminology.  "object"
is the term used throughout the C standard and ARM for this
concept. 

And a "base subobject" bears an analogous relationship to the
containing object(s).  

|> 	In particular, the semantics of a virtual function
|> in a subobject are not encapsulated in the subobject class
|> definition (especially for pure virtuals :-)
|> 

That is correct.  A virtual function call (as I noted in
another item I posted recently) requires taking a base object
and finding the appropriate derived object containing the base
object.  This can't be done based solely on the contents of
the base object.  


|> 	I suspect that only 'complete objects' can really
|> qualify to be genuine, true blue objects. 
|> Which is not to say they shouldn't support object identity.
|> However the current rules do seem to provide object
|> identity --- if at all -- only for complete objects.

The data members of a class are also subobjects according to
my understanding.  You're even disallowing that?  

|> 
|> 	Is the issue not simple: either we waste bytes
|> to obtain object identity for subobjects or we dont.
|> 

I can phrase begging questions too. Either we implement the
language correctly or we fudge, save a byte and hope nobody
notices. 

Apparently the issue isn't simple.  There is a fundamental
disagreement about the semantics of C++.  If that disagreement
is resolved it will tell us what is a legal implementation.
We can use the consequences for storage layout and sizes as
a criterion for determining the semantics, but it can't be
the sole criterion.

   -- Jerry Schwarz