From -698319949307094268
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,acc78eb1decc3ccc
X-Google-Attributes: gid109fba,public
X-Google-Thread: f78e5,c503251d87cf889e,start
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1994-09-18 20:17:25 PST
Newsgroups: comp.lang.c++,comp.std.c++
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!news.dell.com!tadpole.com!uunet!psinntp!ses.com!jamshid
From: jamshid@ses.com (Jamshid Afshar)
Subject: Re: size of a "empty" class
Message-ID: <CwB62G.7M6@ses.com>
Followup-To: comp.std.c++
Summary: will ANSI/ISO guarantee that different different objects have different addresses?
Sender: usenet@ses.com
Nntp-Posting-Host: sleepy
Organization: SES, Inc., Austin, TX, USA
References: <344l8n$4cn@vishnu.jussieu.fr> <CBARBER.94Sep1141903@apricot.bbn.com> <778976946snz@protech.demon.co.uk>
Date: Sun, 18 Sep 1994 04:35:03 GMT
Lines: 55
Xref: bga.com comp.lang.c++:29612 comp.std.c++:4354

Redirected to comp.std.c++.

In article <778976946snz@protech.demon.co.uk>,
Mark Strange <Mark@protech.demon.co.uk> wrote:
>In article <CBARBER.94Sep1141903@apricot.bbn.com>
>cbarber@bbn.com "Christopher Barber" writes:
>[...]
>> The ARM states that "objects of an empty class have a nonzero size"
>> (section 9, p164 of the 1st edition).  This is so that such objects
>> can be allocated and have addresses.  [I think Chris meant "unique"
>> addresses]
>
>Yes, empty classes have a size of 1. You are correct in saying that it is
>so that they are given an address. Since each object, even 'empty' ones
>have an address, it is possible to distinguish, by comparing addresses,
>between objects of the same class.

I wish C++ guaranteed this to be true, but last I heard it will not.
Of course I'm not talking about comparing addresses after casting them
to void*.  The first member of a struct is guaranteed to be at the
same (void*) address as the enclosing object and the first member of
an array is at the same address as the array itself.  I'm referring to
comparisons involving standard conversions (no casts) like:

	class B {};

	class D1 : public B {};

	class D2 : public B {
	   D1 d1;
	};

	D2 d2;

	D1* p1 = &d2.d1;   // pointer to subobject
	D2* p2 = &d2;

As far as I know, a compiler may make `p1' equal `p2' even though they
are *not* pointing to the "same" object (by an practical definition of
"same").

How could this cause a problem in real code?  Say the B constructor
stores `this' in a static Set<B*> to keep track of all "live" B
objects.  If B::~B() removes `this' from the set, we would get an
error when d2 is destroyed because the destructors for both d2 and
d2.d1 would try to remove the same B* address from the set.

Yes, B would usually have a virtual function or destructor and because
of the vtable pointer the compiler could not optimize away the
object's size, but a vtable pointer is not the only way for a C++
compiler to implement polymorphism.  Has ANSI/ISO looked into this
problem?

Jamshid Afshar
jamshid@ses.com