Ты кроме тупого троллинга на что-нибудь способен?

A new implementation of std::string is enabled by default, using the small string optimization instead of copy-on-write reference counting.

https://gcc.gnu.org/gcc-5/changes.html

Что? 1) Copy on write это деталь реализации кода 2) в STL строки ЕМНИП реализованы без COW (в отличие от Qt, например). О чём речь?

я это читал. но у меня не работает:(
g++ -v

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-23ubuntu1~14.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151031 (Ubuntu 5.2.1-23ubuntu1~14.04.2)

Спасибо за твой ответ

1) Copy on write это деталь реализации кода

Нет, для std::string не получится оставить это деталью реализации не нарушая стандарт.

2) в STL строки ЕМНИП реализованы без COW

Поинтересуйся вопросом.

--with-default-libstdcxx-abi=gcc4-compatible

Вот из-за этого беда. Отключить можно только пересобрав всё, увы.

1) Copy on write это деталь реализации кода

Начиная с C++11 нельзя сделать cow для std::string(и правильно).

2) в STL строки ЕМНИП реализованы без COW

STL разные бывают.

Мне интересно, а как ты это определяешь?

элементарно

#include <iostream>
#include <string>

int main()
{
    std::string orig = "abc";
    std::string copy = orig;
    std::cout << (void*) orig.data() << std::endl;
    std::cout << (void*) copy.data() << std::endl;
}

Зачем вообще сейчас этот COW при наличии move semantics?

Зачем вообще сейчас этот COW при наличии move semantics?

И как мув поможет пошарить RO данные в строках, например, между несколькими потоками? Многие этим раньше пользовались, а теперь могут словить приличный прирост в RSS на новых строках.

Ты реально собираешься использовать COW строку в нескольких потоках, не защитив ее блокировками?

Ты реально собираешься использовать COW строку в нескольких потоках, не защитив ее блокировками?

Вот как можно было умудриться в одно предложение вместисть столько ерунды? А именно...

• RO объект можно шарить между потоками какой угодно,
• CoW семантика выглядит примерно как ниже написали, т.е. работает в конструкторе копирования где самого копирования не происходит.
• и таки да, CoW в старых строках потокобезопасный.

Нет, для std::string не получится оставить это деталью реализации не нарушая стандарт.

А почему?

Читаю STL из gcc-4.1, там правда string с COW.

если оно RO, чем оно лучше const ссылок?

Нагуглил: вызов неконстантного operator[] не должен портить итераторы и значения, полученные из data() / c_str(). Это запрещает COW.

Потому что

std::string str = "text";
std::string str2 = str;
str2.c_str()[0] = 'e';
std::cout << str; // WTF??

c_str() возвращает const char*

Ты реально собираешься использовать COW строку в нескольких потоках, не защитив ее блокировками?

А зачем пихать блокировки туда, где хватает атомарных типов?

Скастить никто не мешает

Блин, скастить reinterpret_cast<char*>(&s)[3]=42; тоже никто не мешает, но это же не значит, что так надо делать.

Так никто не делает, а вот например использовать данные std::string в iostream'овских rdbuf() - видел много раз.

Суть в том, что если функция возвращает const, значит туда писать нельзя. Потенциально такая память вообще спроецирована как RO может быть. То, что детали реализации конкретной функции позволяют писать по const-указателю, ничего не значит. Вспомни историю с memcpy. Стандарты надо чтить.

если оно RO, чем оно лучше const ссылок?

Не все RO объекты нужно держать вечно, т.е. без полноценного std::shared_ptr не обойтись. А старый std::string с CoW имеет свой, встроенный, аналог.

Не все RO объекты нужно держать вечно, т.е. без полноценного std::shared_ptr не обойтись. А старый std::string с CoW имеет свой, встроенный, аналог.

Если тебе было достаточно std::string, значит тебе хватит unique_ptr, shared_ptr тут не нужен.

И как мув поможет пошарить RO данные в строках, например, между несколькими потоками?

А чем, в этом случае, плохи ссылки/указатели?

Да, с CoW можно меньше с временем жизни заморачиваться, зато то, что это «RO данные» становится не так очевидно.