This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ ABI Issues


Gaby writes:
> 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.

The compiler can warn that gcc 3.2 and a compiler that implements the ABI
document correctly will lay out a class differently.  But given this
knowledge, how is it supposed to figure out what the user wants to happen?
It doesn't know which compiler compiled the "other half" of the code: the
library being called, or the caller of the library.

Of course the compiler can and will do the adjustment if it implements
-fabi-gcc-3.2 or whatever we call it.  But if the code being called is
compiled by Intel, it had better *not* do the adjustment.  Again: how can
it "know"?

> 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.

Rather, *if* a warning appears, *and* it is important to the developer of
the code that gcc 3.2 and Intel's compiler and a future, fixed gcc will
agree on the layout of some class, then the only safe thing to do is to
design the class in such a way that the warning goes away.  Library
versioning won't suffice, and in any case is much more difficult to do
than simply adjusting the class layout.

As I said, it appears that libstdc++ is unaffected.  C++ implementations
of CORBA should be looked at, as they are likely to use multiple
inheritance.

You appear to assume that these padding objects will be needed all over
the place.  In practice, I expect the need for them to be extremely rare,
because even to use virtual base classes is rare (I despise the things
myself: they violate encapsulation severely unless the virtual base has no
data members, since the most-derived class always has to explicitly
construct the virtual base.  And if there are no members, then the ABI bug
does not arise).






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]