🚀 go-pugleaf

pkt@lpi.liant.com (Scott Turner) writes:

>In article <1992Dec19.001851.22116@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
>> On the contrary, for the test to not prove true would
>> mean that the empty base class part has to be implemented by the compiler
>> using gratuitous padding, and gratuitous padding is an anathema to
>> traditional C/C++ implementation.  
>
>"Gratuitous" is your own judgment.  Some of us disagree.
>Moreover, such padding is in the C++ tradition.  

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.
It has a very significant memory overhead, especially if there
are multiple levels of derivation involved. Such padding could easily
double (or worse!) the memory required for classes derived from
abstract base classes.

Stroustrup goes on to say
	"For example, ideas that would make it necessary to
	store ``housekeeping information'' in every object
	were rejected; if a user declares a structure consisting
	of two 16-bit quantities, that structure will fit into
	a 32-bit register" [Ibid.]

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.
If such padding were to be inserted by the compiler, then there would be
NO WAY to turn this feature off in cases where you weren't using it.

To force implementations to insert such padding would go against one of
the strongest guiding design principles for both C and C++.

As a final point, I believe that requiring padding when deriving from
abstract base classes would strongly discourage their use, for efficiency
reasons. This would be a very bad thing IMHO, because abstract base classes
are a very important design tool, and if the design can't be represented
directly in the programming language, then there is a significant cost
in terms of productivity and maintainability.

The concise OED defines "gratuitous" as (amoung other things)
"uncalled for, unwarranted". Given the above arguments, I would
definitely describe inserting padding when deriving from empty
classes as "unwarranted". 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"?

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!