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

[David Vandevoorde]

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

       Daveed