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

[Lawrence Crowl]

On 7/18/09, David Vandevoorde <daveed at edg.com> wrote:
> 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.

Yes, but gcc is one of those compilers that will need to change its
string implementation.  My company is a heavy user of a non-standard
string simply because the gcc standard string is reference counting.

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

And that vote passed.  The requirement is now in the working draft.

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

This conclusion came from discussions with Howard Hinnant, and he
was not specific.

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

First, let me note that I argued strongly in favor of taking some
position on binary compatiblity, but was unable to get the committee
to adopt a policy.  As a result, we have inconsistent expectations
on compatiblity.

Second, my concern is that we probably will not have effective
binary compatibility anyway, and not taking advantage of that
incompatibility has real performance costs.

I would dearly like an experiment in compatibility between a fully
baked C++0x implementation and a C++03 implementation.  I do not
see that experiment happening any time soon.  On the other hand,
we probably can defer binary compatibility decisions until later.

-- 
Lawrence Crowl