NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/std/cplus/1976

Text File | 1993-01-05 | 3.8 KB | 106 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
From: [e-mail] (Jerry Schwarz)
Subject: Re: pointer comparisons
Message-ID: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jerry Schwarz)
Organization: Lucid, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jan 93 22:23:00 GMT
Lines: 93

In article <[e-mail]>, [e-mail] (John MAX Skaller) writes:
|> In article <[e-mail]> [e-mail] (Jerry Schwarz) writes:
|> >In article <[e-mail]>, [e-mail] (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