[cxx-abi-dev] C++0x POD
David Vandevoorde
daveed at edg.com
Tue Jul 21 22:38:26 UTC 2009
On Jul 21, 2009, at 6:17 PM, Lawrence Crowl wrote:
> On 7/18/09, David Vandevoorde <daveed at edg.com> wrote:
>> On Jul 17, 2009, at 8:05 AM, Lawrence Crowl wrote:
>
[...]
>>> 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.
Indeed.
[...]
>>> 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.
Maybe. However, although concepts are out of C++0x, they are still
"on the horizon". Concepts change the library-ABI very drastically.
I suspect that several vendors will therefore consider delaying other
ABI-breaking transitions to coincide with the implementation of
concepts (in whatever form they reappear). (That's also why I voted
against the O(1) size change: I find it unwise to break the library
ABI piece-by-piece instead of wholesale at distant release points.)
Daveed
More information about the cxx-abi-dev
mailing list