Re: C++ ABI Issues

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Joe Buck <Joe.Buck@synopsys.com> writes:

| I wrote:
| 
| > | It seems that even if it does, we can preserve libstdc++'s binary
| > | compatibility by adding a dummy field that exactly fills up any padding.
| 
| Gaby writes:
| > Isn't this the compiler should be doing (with appropriate flags if
| > necessary)?  It certainly does know where to fill things.  I would
| > certainly prefer that to clutering V3 with pad0, pad1, ...
| 
| How could we do that?  We'd have to either tell the compiler somehow which
| classes to compile in the old way and which classes to compile in the new
| way, or else use the 3.2 ABI for everything, forever.

Well, if the compiler were to be issueing a warning about a class
being laid out differently according to ABI differences, then it
certainly should be possible to tell the nature of the difference and
how things change from one set to the other.  That means, the compiler
should be able to do the adjustment.

Now, why should we really uglify the class definition?  According to
your statement, it is because we wanted the library to accomodate the
compiler deficiencies.  But then, the library isn't the only thing to
be changed to accomodate the compiler deficiencies, programs being
linked against the library also presumably need the same uglification.
Which means that a way to solve the problem ought to be in the compiler.

-- Gaby