Re: Status of std::string ABI change

[Dan Kegel <dank at kegel dot com>]

For comparison, Apple made the switch to non-copy-on-write strings
recently when they released, XCode 5, which switched the default
C++ standard library from libstdc++ to clang's libc++, which I think
has a completely different ABI.

ABI changes are never fun.  I wonder how they got away with this
without a huge outcry...

On Sun, Nov 24, 2013 at 3:01 PM, Peter A. Bigot <pab@pabigot.com> wrote:
> TL;DR: When will the underlying implementation of std::string in GCC
> provde a non-copy-on-write implementation by default, through a
> supported configuration-time option, or by selecting alternative
> header/library configurations during application build?
>
> Background: It's been known for a long time that libstdc++ std::string's
> copy-on-write behavior causes problems.  It's also now non-conformant
> under --std=c++11 (see
> e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334#c45).
>
> <ext/vstring.h> provides __gnu_cxx::__vstring which behaves correctly,
> but using it in current form appears to require source changes to the
> application.  gcc 4.9.0 trunk as of 2013-11-24 still uses the
> non-conforming std::string implementation for applications built with
> --std=c++11.
>
> Other libstdc++ bugs like 58265 are in suspended status with comments
> like "until we break the ABI basic_string will remain nonconforming in
> many serious ways."  I understand that "break the ABI" refers to the
> consequences of switching out the string implementation and that this
> has been delayed because of its significant impact on existing systems.
>
> I've searched through bug reports, the 4.9 Changes page, the libstdc++
> ISO status page in the manual, mailing list archives, Google, etc. and
> have been unable to find an answer to the question above.
>
> Thanks.
>
> Peter