🚀 go-pugleaf

In article <9236102.3238@mulga.cs.mu.OZ.AU> (Fergus James HENDERSON) writes:
> One of the most important principles of C was that if you didn't use a
> feature, you shouldn't have to pay for it. This principle was carried
> through to C++. On the topic "Design Notes", Bjarne Stroustrup wrote
> 	"Features that would incur run-time or memory overheads even when
> 	not use were avoided" [C++PL, 2nd Ed. pg 3].
> 
> As a feature, padding empty base classes fits this description exactly.

"Padding empty base classes" is not the feature -- it's the
simplest implementation.  The desired feature is:
    Two pointers to the same type, which point to distinct objects
    of that type, compare not equal.

> It has a very significant memory overhead, especially if there
> are multiple levels of derivation involved. 

A smart implemetation would typically have no overhead.  The most practical
example which has come up is Jamshid Afshar's, which incurs no overhead
even with existing implementations.  The example which requires padding
(originally Johan Bengtsson's) is contrived.

> In the case of deriving from empty structures, it is absolutely TRIVIAL
> to insert padding yourself *IF* you really need the addresses to be different.

This is getting away from my point, but how do you know a compiler will 
provide storage space for unused padding within a struct/class?

> Furthermore, if the programmer didn't
> ask for the padding and didn't want it, how could you say it was
> anything other than "uncalled for"?

There's a good chance the programmer needs data or object code compatibility 
with other code.  The other code may use the above-described feature.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com