Так это не про детали реализации. В случае правильной COW строки и ее типового использования, пользователю до фени, что там внутри происходит.

Ну никто не пишет cow ибо он говно

Тут начинаются тонкости с тем, насколько у тебя часто происходят copy-write-delete на эти самые строки. Не везде это становится проблемой. не везде подойдут COW строки на атомиках.

Если я COW на std::wstring заменю у меня вся программа сломается за 20 минут

Критики в чатике 😊 Собственно, изначальный вопрос и был в том, сделано ли это уже где-нибудь и почему нет в стандарте, где есть string_view и shared_ptr по отдельности. Это потом все скатилось в "ты хочешь явную иерархию владения".

Потомучто это не джава и никто не хочет чтобы ты писал как на джаве

О том и разговор. COW не заменяется move semantics, последнее банально не может предложить неявного совместного использования памяти. Мне кажется, аргументы против COW вообще всегда чаще всего носят финатичный оттенок.

"Страдай, как деды с ANSI C"

Подождите, вот есть сценарий: создаются строки, которые редко меняются и шарятся по многим местам/контейнерам и т.п. COW тут работает как добрый малый, который делает все довольно эффективно для использования, практически нулевой ценой для программиста. Я не понимаю, как тут поможет move, если у меня _копии_.

Ну поэтому завезли вью

Подождите, вот есть сценарий: создаются строки, которые редко меняются и шарятся по многим местам/контейнерам и т.п. COW тут работает как добрый малый, который делает все довольно эффективно для использования, практически нулевой ценой для программиста. Я не понимаю, как тут поможет move, если у меня _копии_.

здесь спасает не move/не COW, а string_view/span

Подождите, вот есть сценарий: создаются строки, которые редко меняются и шарятся по многим местам/контейнерам и т.п. COW тут работает как добрый малый, который делает все довольно эффективно для использования, практически нулевой ценой для программиста. Я не понимаю, как тут поможет move, если у меня _копии_.

@breakneck11 ты все сделал правильно, но хочешь привнести в свой проект сборку мусора. я бы трижды подумал, поскольку пул как раз и выполняет контроль над временем жизни строк, а string_view обеспечивает незатратный способ передачи строк

Так у нас же нет родного пулла в плюсах, нет?

Так Антон же в докладе показал, что ни хрена не вера, а на самом деле страдает перф: https://habrahabr.ru/company/oleg-bunin/blog/352280/

а если поместить пул под управление того же shared_ptr решится задачи и с передачей пула

Не надо

А есть какой-то shared_string_view? Хочется как string_view, но с shared_ptr на строку внутри, чтобы не париться по владению памятью; чтобы не перепридуать COW — пусть указатель будет на константную строку. Если такого нет, почему не добавили в стандарт: сильно медленнее и т.п? Вроде не сложно написать, но странно, почему никто такого не захотел раньше.

std::vector<std::string> pool или std::deque или std::set

я бы не стал делать string_view на vector<string> :)

Блин, да потому что у меня например 1к уникальных длинных строк, и в программе будут храниться до, пусть, 100к их подстрок. Я могу сохранить высоко-высоко, на global уровне вектор длинных строк, тогда все string_view остануться валидны, примерно так оно сейчас и сделано (без глобальных переменных, разумеется). Но я не уверен, что вообще хочется тут думать об этом владении.

it depends, v.reserve() и все

А есть какой-то shared_string_view? Хочется как string_view, но с shared_ptr на строку внутри, чтобы не париться по владению памятью; чтобы не перепридуать COW — пусть указатель будет на константную строку. Если такого нет, почему не добавили в стандарт: сильно медленнее и т.п? Вроде не сложно написать, но странно, почему никто такого не захотел раньше.

Вот объясните мне, я не могу вас понять. Казалось бы, это естественный путь: сделать все минимальными усилиями, с использованием максимально "самоумных" инструментов, где это модет пригодиться: COW, если много копий строк, автоматическое управление владением через shared_ptr, чтобы не думать над этим при изменениях через 2 месяца. А потом, посмотреть на узкое место, которое с огромной вероятностью окажется не в COW и нев shared_ptr. А если оно оказалось там, то, если написан корошо разделяемый код с надежной инкапсуляцией, то и заменить на специально вылизанные аналоги. Но почему-то тут многие ругают "умные" инструменты, приводя в пример ситуации, где их накладные расходы начинают выпирать, и игнорируют случаи, где эти расходы минимальны.

Вот объясните мне, я не могу вас понять. Казалось бы, это естественный путь: сделать все минимальными усилиями, с использованием максимально "самоумных" инструментов, где это модет пригодиться: COW, если много копий строк, автоматическое управление владением через shared_ptr, чтобы не думать над этим при изменениях через 2 месяца. А потом, посмотреть на узкое место, которое с огромной вероятностью окажется не в COW и нев shared_ptr. А если оно оказалось там, то, если написан корошо разделяемый код с надежной инкапсуляцией, то и заменить на специально вылизанные аналоги. Но почему-то тут многие ругают "умные" инструменты, приводя в пример ситуации, где их накладные расходы начинают выпирать, и игнорируют случаи, где эти расходы минимальны.

Да нет, меня просто действительно удивила позиция людей, что-то вроде небольшого культурного шока. 😊

Да нет, меня просто действительно удивила позиция людей, что-то вроде небольшого культурного шока. 😊

Да нет, меня просто действительно удивила позиция людей, что-то вроде небольшого культурного шока. 😊

Мое отличается от существующего string_view в 2 местах: 1. Оно добавляет небольшие накладные расходы. 2. Оно не дает выстрелить себе в ногу. Не возьмусь голословно говорить, какое из них более общее.

Из-за вечных хождений по указателю? Наверное ты прав, я над большими строками думал, там это бы компенсировалось. Хотя, а разве если у меня константный указатель на const string, она не может положиться в кеш?

3) оно даёт право не определять для себя правила написания кода и писать как попало

Есть мнение, что так же можно раскритиковать конструкторы и деструкторы. Кажется, так делал Торвальдс.