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

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

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

С++ и Move тем и хороши, что нет неожидаемого, неявного копирования и управления памятью. Всё предсказуемо и детерминировано.

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

Но он объективно устарел, не?

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

Ну ваще с++98 был сильно похож на то что пишут джависты, а теперь не похож

Но он объективно устарел, не?

Считается, что он плохо сочетается с оптимизациями современных процессоров. Да, это скорее философия и вера, тут я согласен. Но мне как-то Move тоже ближе, чем COW. Он лучше сочетается с семантикой объектной модели С++

Считается, что он плохо сочетается с оптимизациями современных процессоров. Да, это скорее философия и вера, тут я согласен. Но мне как-то Move тоже ближе, чем COW. Он лучше сочетается с семантикой объектной модели С++

Не столько с процами, сколько с многопоточностью, имхо

И это тоже

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

Да и компилятору легче и процу легче

Вон в стек ио посмотрите

Дичь полная

Проверки в рантайме флажков

На каждом чаре

Пздц

Тут было то же

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

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

Например, тот же Qt, его контейнеры с PIMPL и COW — ЛЮБАЯ неконстантная фукнция требует синхронизированного доступа к счётчикам использования. Надо ли говорить, что для ОДНОПОТОЧНОГО приложения это как бы перебор (Оверкил)

Во времена ков

Считается, что он плохо сочетается с оптимизациями современных процессоров. Да, это скорее философия и вера, тут я согласен. Но мне как-то Move тоже ближе, чем COW. Он лучше сочетается с семантикой объектной модели С++

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

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

Спэн и прочее

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

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

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

++

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

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

Я имел ввиду разделение перемещения и копирования на 2 разных операции

Да, а что не так? Пока у меня есть хоть одна подстрока, мне нужен этот хозяин, все же верно. Как только последняя построка перестанет быть нужна, она в своем деструкторе похоронит и хозяина.

SHARED+PIMPL и всё.

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

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

Сделай хозяина явно

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

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

Сделай пул строк и дергай из него

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

Это все правда, когда у нас частые модификации. Я привел чуть-чуть другой сценарий.

Переживать пул строки не должны

Если строка переживает родителя который содержит пул родитель должен просто передать пул дальше

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

вообщем, не вижу смысла здесь что-то придумывать и помещать строки под управление std::shared_ptr

А киньте в сообщение, где кейс/вопрос. Я чото нипонил

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

Не надо

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

Не надо

Вы теряете явный контекст жизни строк

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

Странное желание. А что таким образом предполагается решать?

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

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

Короче контекст это как блок кода с фигурными скобками или типа того

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

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

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

Что если половина ИФА будет у вас в одной функции а остальная часть в другой? Это норма?

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

Вот это решать.

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

нога в опасности, да и память последовательно ради этого выделять ниохота

foo(){ if (n){ return bar(); } -------------------- bar(){ dosmth }endif }

Удобно?

То же самое с неявным контекстом и cow

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

Можно пропосаль закинуть

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

И вот мотивация

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

Я не вижу особой универсальности у того, что ты описал. Похоже это на таблицу атомов, но они на самом деле редко кому нужны, и без них можно обойтись.

Мелкие строки ваще же в ссо

Стрингвью поди дольше чем Стринг для них

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

Да бог с тобой, делай :)

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

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

Это интернет. Велкам

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

а потому что с практической точки зрения container<std::string> + std::string_view гораздо эффективнее container<std::shared_ptr<std::string>> + shared_ptr_string_view

Я не вижу особой универсальности у того, что ты описал. Похоже это на таблицу атомов, но они на самом деле редко кому нужны, и без них можно обойтись.

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

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

Кстати не проще ли тогда напилить свой аллокатор чтобы «творить» угар

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

Ты же понимаешь что эти расходы не небольшие?

Оно будет раз в 10 дольше работать

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

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

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

Там внутри атомарный счетчик

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

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

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

Как раз наоборот, конструкторы и деструкторы это правило задающее контекст, а у тебя контекст непонятен, следовательно не понятна иерархия

Следовательно не понятна архитектура приложения целиком

Там внутри атомарный счетчик

Я для доступа к строке буду ходить по обычному указателю. Атомарный счетчик будет задействован только при создании/копировании/удалении, что в современной действительности c move semantics + copy ellision + ... будет происходить не так уж часто.

Следовательно не понятна архитектура приложения целиком

Мне кажется, это могут быть проблемы твоего восприятия. В мое нормально укладывается модель "последний уходящий закрывает дверь^W^W убивает объект".

А в мое нет

Дверь должен закрывать деструктор комнаты

Дверь должен закрывать деструктор комнаты

Плохая и неверный аналогия. В плюсах дверь закрывает и уничтожает объект обычно его владелец, который действительно обычно 1. Это не значит, что невозможны другие сценарии.

Да и слово последний это уже отсылка к последовательности действий

Да и слово последний это уже отсылка к последовательности действий

Которая есть, ведь атомики. Я не вижу логической проблемы.

Да и слово последний это уже отсылка к последовательности действий

Это не структурная последовательность а задокументированная

В случае с контекстом она структурная

Грубо говоря все знают что если комнаты нет то дверь закрылась

У меня нет проблемы с тем, что объект может пережить контекст, в котором был объявлен, если он потом все-равно гарантированно будет уничтожен. Я правильно понял, что для тебя проблема в этом?

Это плохой дизайн для меня

Видимо, на вкус и цвет.

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

Особенно мне нравится желание не давать выстрелить в ногу. Так просто НЕ СТРЕЛЯЙ В НОГУ, И ВСЁ! В этом — дзен разработчиков на С и С++!

Особенно мне нравится желание не давать выстрелить в ногу. Так просто НЕ СТРЕЛЯЙ В НОГУ, И ВСЁ! В этом — дзен разработчиков на С и С++!

иногда начинаешь скучать по боли в ноге

У меня нет проблемы с тем, что объект может пережить контекст, в котором был объявлен, если он потом все-равно гарантированно будет уничтожен. Я правильно понял, что для тебя проблема в этом?

Ты же ЗНАЕШЬ, как делать, чтобы ВЫСТРЕЛИТЬ В НОГУ? Так?

Ладно, это уже полушутка...

Особенно мне нравится желание не давать выстрелить в ногу. Так просто НЕ СТРЕЛЯЙ В НОГУ, И ВСЁ! В этом — дзен разработчиков на С и С++!

Не все стрелки делали это по желанию. Иногда, лучше предусмотреть в конструкции предохранитель, если ты уверен, что он не создаст проблем со скоростью достал-выстрелил.

Блин, вы про все то же?!

Кастомный аллокатор все разрулит

а потому что с практической точки зрения container<std::string> + std::string_view гораздо эффективнее container<std::shared_ptr<std::string>> + shared_ptr_string_view

Я понял, что мне не особо понравилось в самом существовании контейнера на верхнем уровне: он вообще не должен ничего знать о своем сроке жизни, и умирать должен, по хорошему, когда все вьюхи на него померли. Его уместно сравнить с прокси-объектом доступа к ресурсу — пока хоть кому-то нужен ресурс, этот объект должен жить. Как только последний пользователь ушел, он должен закрыть ресурс и умереть (дропнуть базу/соединение/пулл строк). Наверное, в этом месте было основное различие в понимании. Без shared_ptr такие вещи действительно обычно располагаются на высоком уровне, где их деструктор будет гарантированно вызван после сметри всех пользователей, тут вы скорее правы. Спасибо за разъяснение! (конец холивора)

Я просто оставлю это здесь: https://www.phoronix.com/scan.php?page=news_item&px=45-Linux-Kernel-CXX-Patches

вот это норм шутеечка (или не шутеечка)

Я просто оставлю это здесь: https://www.phoronix.com/scan.php?page=news_item&px=45-Linux-Kernel-CXX-Patches

И Линус такой "ок, мержим".

какие шутки

скорее фак ю

в 21 стандарте не будет указателей

*в 23

в 20 они просто станут deprecated

И Линус такой "ок, мержим".

лол