std::move(x) же ничего не вычисляет

я в этих двух штуках ваще не вижу разницы результата

а как так мерить?

На всякий случай перепроверил. Вариант a -= (b < 0); занимает всегда один такт if (b < 0) { a--; } занимает 0.51 такт в случае угадывания branch predictor и НЕ трогает память. А вот если не угадал - то стоимость будет 1.49 тактов Если честно - хз какой вариант быстрее :)

спс

А я думаю тут PGO может помочь 😊

спс

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

Что? Я-то как раз все определил, и да, я и предлагал shared_ptr от string. Еще раз, сейчас использование string_view при сохранении его куда-то, а не просто создал-пропихнул_туда_сюда_по_стеку-удалил, требует помнить, кто владеет строкой и т.п. Хочу что-бы я об этом не думал, и чтобы string_view не превращался в тыкву. Собственно, вопрос был, есть ли уже где-то такое и разве я хочу странного?

Типо map<std::cref<std::string>,...> ? Но у меня работы с парсингом и подстроками много, из-за чего и перешел на string_view

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

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

А вам не пора пиликать персистентные структуры, если у вас такая фигня?

или оно есть всегда

Так то, что я предлагаю, и является, по сути, персистентной структурой — у меня все readonly.

Ну с моим классом оно и будет всегда

Не immutable а persistent

Я понимаю, переразирую: в мем случае я хочу получать view на immutable container, при чем view не дадут умереть контейнеру, пока хоть один из них жив. И я не особо понимаю, зачем мне тут чистая персистентность: массив строк создается 1 раз, после этого только появляются на него вьюхи.

Я понимаю, переразирую: в мем случае я хочу получать view на immutable container, при чем view не дадут умереть контейнеру, пока хоть один из них жив. И я не особо понимаю, зачем мне тут чистая персистентность: массив строк создается 1 раз, после этого только появляются на него вьюхи.

или оно variant<string, string_view>

Я понял предложение, но оно мне вообще не нравится. 1. Тогда уж создать специальную пару, чтобы самому не париться, где s_w где string, иначе это начинает походить на ручной менеджмент памяти. 2. Это какой-то оверкилл и переусложнение, модель с shared_ptr про то же, но в ней нет плывущих ролей, там нельзя в них ошибиться.

у вас же сейчас все концептуально чисто, зачем добавлять оверхед с shared?

Ну да, текущая модель типична для плюсов, поэтому ее бремя не вызывает у C++'сников отторжения. Я внезапно понял, что после полугода программирования на языке со сборкой мусора у меня появилось отторжение к любой зависимости со владением, которая хоть как-то может сломаться и заставляет помнить о себе при смене иерархии. Наверное, пора снова привыкать к плюсам. Просто, ну вот добавили же shared_ptr, а захотел применить — "нинужна!!".

Так реализовали в одной джаве, потом передумали - очень неприятные способы получить мусор в памяти

Можно, кстати, вопрос, как? За исключанием циклических ссылок, которых в данном случае быть не может, кажется, мусор при использовании shared_ptr появляться не должен.

Выбор подстроки как shared_ptr захватывает хозяина

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

Типа легендарной std::rope

это что? на хабре нашёл что-то

Проблема что нужна подстрока, а основная строка давно не нужна, так что ради подстроки в 32 буквы храним 10к

А, понял, если это мусор, то да. Но ведь там есть глобальных пулл строк, так что они это специально. Если это так принципиально, то мы все равно придем к подобию COW 😞

Так COW правильная концепция в действительности)

Нет явное лучше неявного

Что? Я-то как раз все определил, и да, я и предлагал shared_ptr от string. Еще раз, сейчас использование string_view при сохранении его куда-то, а не просто создал-пропихнул_туда_сюда_по_стеку-удалил, требует помнить, кто владеет строкой и т.п. Хочу что-бы я об этом не думал, и чтобы string_view не превращался в тыкву. Собственно, вопрос был, есть ли уже где-то такое и разве я хочу странного?

Угу, поэтому C должно быть явное

Нет явное лучше неявного