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

David Vandevoorde daveed at edg.com
Sat Jul 18 09:53:08 UTC 2009


On Jul 17, 2009, at 8:05 AM, Lawrence Crowl wrote:
[...]
> Remember that the internal implementation of std::string is part of  
> the
> ABI because of the inline functions.

It would be part of it even for non-inline functions: Both sides have  
to agree on how to interpret the objects "blob of data".

>  A consequences is that introducing
> the new implementation of string will break the ABI.

Most implementation don't have to change their internal representation.

>  This new
> implementation is actually fairly important to my company, to the  
> extent
> that we have redirected all our code to it, suffering interoperability
> problems with the current standard.
>
> The C++0x library now requires an O(1) size operator.

Not yet :-)  That will be voted on in a few hours (at the time of the  
time of this writing).

>  This will cause
> an ABI breaking change in something like half of the std::list
> implementations, one of which is gcc.


The discussion at the Frankfurt meeting (yesterday, at the time of  
this writing) suggested GCC was the _only_ implementation requiring a  
change.

>  Other types are affected, though
> we don't know how many will actually change the ABI.


Which types were you thinking of?

> Howard Hinnant informs me that Apple plans to not have any binary
> compatibility between the two versions of the standard, except that
> standard exceptions are binary compatible and hence can cross from one
> version to another.


And certainly every vendor is at liberty to change their library  
signatures.  However, some vendors also plan to  avoid breaking  
library compatibility if they can and with the current standard  
revision, that is entirely possible (because they already have an O(1)  
std::list::size() and a non-reference-counted std::string).

Even those vendors that will have to break compatibility may provide  
binary compatibility options with e.g. inline namespaces.

In either case, I am not willing to foil such goals by changing the  
underlying ABI.

     Daveed





More information about the cxx-abi-dev mailing list