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

[Gabriel Dos Reis]

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