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

[Lawrence Crowl]

On 7/16/09, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:
> On Thu, Jul 16, 2009 at 4:59 PM, David Vandevoorde<daveed at edg.com> wrote:
> > On Jul 16, 2009, at 4:00 PM, Lawrence Crowl wrote:
> >> On 7/16/09, Mark Mitchell <mark at codesourcery.com> wrote:
> >>> Lawrence Crowl wrote:
> >>>> With all the changes in the standard library, I do not see much
> >>>> value in preserving the ABI of the core language.  Programmers
> >>>> can reasonably expect some change to the ABI in a major release
> >>>> of the standard.
> >>>
> >>> Not when they're not using the new features!
> >>>
> >>> If a user gets a new compiler, compiles their application without
> >>> changes, and can't link with the library they have from a third-party
> >>> provider, I think we've made a mistake.  Of course, I'm fine with the
> >>> idea that using C++0x features causes the ABI to change.
> >>
> >> The standard library uses new features of the language heavily.  Most
> >> programs use the standard library, and will therefore use the new
> >> features of the language.
> >>
> >> My understanding is that in some cases, compiling existing code with
> >> the new standard library results in calling new functions.  The most
> >> prominent class is the move functions.  Among other things, this change
> >> means that some calls within inline functions in the third-party library
> >> headers will be calling one function in the user's code and another
> >> function inside the library.  That is not binary compatible, independent
> >> of the mangling.  It may work by accident, but I wouldn't guarantee it.
> >>
> >> My understanding is that some functions in the C++03 standard library
> >> no longer exist in the C++0x standard library, though the existing call
> >> expressions will continue to work.  Even so, the old third-party library
> >> will not link with the C++0x standard library.  My memory could be wrong
> >> (the library does change frequently), so I will need to verify that
> >> claim.  Anyway, if so, that is not binary compatible.
> >>
> >> There are some customers that do not use the standard library, and they
> >> could perhaps avoid an ABI change.  Is protecting those customers worth
> >> the long-term cost of a less efficient ABI?
> >>
> >> At the very least, I recommend keeping a list of possibilities and then
> >> if testing shows that the language-and-library combination is not
> >> compatible, going ahead and changing the language ABI.
> >
> >
> > I _think_ that now that concepts have been removed, many uses of the
> > standard library are binary compatible with C++03 as far as establishing
> > APIs.
>
> I'm not sure that is true given the addition of rvalue references  and the
> modification of the standard library -- clients don't change source code,
> but generated codes differ.
>
> > I.e., the internal structure of the data types and their mangled
> > names are unchanged.  It's true that a caller might now e.g. "move" and
> > rvalue std::string to a caller instead of "copying" to it, but that's done
> > on the C++0x caller side, and the result can be a blob of data that's
> > perfectly compatible with C++03 std::string.

Remember that the internal implementation of std::string is part of the
ABI because of the inline functions.  A consequences is that introducing
the new implementation of string will break the ABI.  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.  This will cause
an ABI breaking change in something like half of the std::list
implementations, one of which is gcc.  Other types are affected, though
we don't know how many will actually change the ABI.

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.

-- 
Lawrence Crowl