🚀 go-pugleaf

In article <5450@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>Jim Adcock (jimad@microsoft.com) wrote:
>: On the contrary, requiring unnecessary and unexpected padding within
>: structures just to meet your new requirements would be extremely 
>: undesirable, in my opinion.
>
>But the cases where "unnecessary" padding would be required would
>have very minor impact on the majority of programs, at least if I
>may consider the current implementation of virtuals (vtbl).  After all,
>inheriting from a truly empty base class (no virtuals) is quite uncommon,
>don't you think?

The fact the following idiom works under all current C++
implementations, and that it will probably continue to work no matter
what ANSI says, is what most worries me and why I originally posted
this question.  Programmers will continue to do things like
	class Register {
	   Set<Register*> alive;
	protected:
	   Register() { alive += this; }
	   virtual ~Register() { alive -= this; }
	   static void foo();  // do something to all registered objects
	};

If a special-case rule is not added making the above safe on *any* C++
implementation, I hope more C++ literature will point out the fact
that the above idiom is incorrect.  I've been doing stuff like this
for years and never gave it a second thought.  I guess the correct way
to do this would be to always add a dummy char to empty base classes,
but then that's a waste on existing implementations.  Besides, if we
are all going to do this, then why not instead make the compiler do it
-- it could do a much better job of determining when padding is
necessary.

>If pointer distinctness (as defined above) allows useful semantic constructs,
>such as the very common idiom for operator=:
>"if ( &other == this ) return", then a small and rare storage overhead
>in examples such as the one below could easily be tolerated (IMHO).

I hadn't thought about this situation.  I'm sure there are many other
cases besides operator=() where a member function wants to know if
'this' compares equal to the address of a parameter.  Yes, I know
there are many cases when the address of two distinct objects compare
equal when cast to |void*|, but as far as I know this is the only
situtation where the address of two distinct objects compare equal
without the aid of an eye-catching cast.

I'm still not sure how I feel about this situation.  I'm going to take
a closer look at my code after the holidays to see how often I
erroneously assume that when two EmptyAbstractClass*'s compare equal
they are both pointing to the same object.

Jamshid Afshar
jamshid@emx.utexas.edu