From -1491009828406429784 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,acc78eb1decc3ccc X-Google-Attributes: gid109fba,public X-Google-Thread: f78e5,c503251d87cf889e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-09-19 08:55:39 PST Newsgroups: comp.lang.c++,comp.std.c++ Path: bga.com!news.sprintlink.net!uunet!world!tob From: tob@world.std.com (Tom O Breton) Subject: Re: size of a "empty" class Message-ID: Followup-To: comp.std.c++ Reply-To: tob@world.std.com Organization: BREnterprises References: Date: Sun, 18 Sep 1994 21:38:18 GMT X-Posted-By: My own casual posting program Lines: 60 Xref: bga.com comp.lang.c++:29649 comp.std.c++:4368 [ Followups to comp.std.c++ ] jamshid@ses.com (Jamshid Afshar) writes: > How could this cause a problem in real code? Say the B constructor > stores `this' in a static Set 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. I do not believe the language should be guarding against such a remote special case. It should simply not guarantee pointer uniqueness for empty classes. In the very, very, very rare case where you want to use an empty class in that manner, add a dummy variable. (Frankly, I suspect there are zero real cases of empty class + virtual functions + want to hold all the virtuality data elsewhere.) The current decision is against the spirit of C, which is not paying for overhead that you don't use. Funny thing, I don't hear the people who usually yell "too tough to implement" complaining about this ~status quo~ kluge. If it is desired to let the dummy variable disappear in not-empty derived classes, it would be no more complex than what is being done now, just explicitly noted. But _I_ think that should be left up to the user, who will have to make their inheritance tree a bit odd (reminder: in a very, very, very rare case) but be otherwise unaffected. > 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. True -- in fact I could wish the vtable dereference had been left user-definable, as copy CTORs, operator=, and new/delete are. When that's useful, it's _very_ useful. IE, for multitudes of small objects that dare not waste memory, or for objects that want to handle their functionality-state themselves. Or for reading heterogeneous objects from file. But IMO in principle _some_ member data is required for virtuality. The idea of using the address to supply that information is simply a roundabout way of using the object's data. You have to add data to make the address unique -- well, why not just put the data in the object where it belongs in the first place? It seems to come down to the fact that there is no way to reliably get instance-dependent information (in the Shannon sense) from an object without holding information in the object. > Has ANSI/ISO looked into this problem? They did, and they agree with you. Take that as a bad sign. }:) Tom -- finger me for how Tehomega is coming along (at tob@world.std.com) Author of The Burning Tower (from TomBreton@delphi.com) (weekly in rec.games.frp.archives)