[cxx-abi-dev] C++0x POD

[Mark Mitchell]

David Vandevoorde wrote:

> Maybe.  However, although concepts are out of C++0x, they are still "on
> the horizon".  Concepts change the library-ABI very drastically.  I
> suspect that several vendors will therefore consider delaying other
> ABI-breaking transitions to coincide with the implementation of concepts
> (in whatever form they reappear).

There are of course significant users of C++ that make essentially no
use of the standard library, particularly on embedded systems.

I think the key point here is that we don't really know what's going on.
 Lawrence may be right: implementing C++0x, particularly on the library
side, so breaks everything that maintaining ABI compatibility is just
impossible; you have to recompile your entire world.  Then again, maybe
not.

So, I think we should avoid making changes to the ABI that break
compatibility.  The only harm is "opportunity cost"; we're leaving some
performance on the table.  Not updating our definition of POD isn't
going to make any existing programs slower, or break compatibility.  So,
let's leave it alone.

Then, if we wake up realizing that C++0x is a totally different language
 with a totally incompatible library ABI, we can always make a C++0x
version of the C++ ABI that is smarter about PODs.  At that point, we
can overhaul other aspects of the C++ ABI that are suboptimal as well;
we know, for example, that we ended up with suboptimal bits for virtual
base classes, and I still think that hashing mangled names down to
1024-bit hashes would win, and we've had ideas about implementing
std::type_info, and the decision not to have constructors return "this"
loses on some architectures and so forth...

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713