
Михаил
02.04.2018
09:25:09

Antony
02.04.2018
09:25:47
спс
Сам о ней пару недель наза узнал. До этого ходил и ныл "хочу тулзу, которая в статике анализирует производительность куска кода"

Михаил
02.04.2018
09:27:21

Antony
02.04.2018
09:27:23
спс
НО там тулза своеобразная. Она хорошо работает на прямом участке кода, без ветвлений и циклов. Но при этом считает что всё поместилось в кеши! Что она считает в случае цикла - или ветвления мне не понятно.

Google

Matwey
02.04.2018
09:49:37
А в STL не завезли indirect_iterator еще?
И не планируют?

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

Aidar
02.04.2018
10:00:57
зачем оно
юзай string

Andrew
02.04.2018
10:01:23
Так не хочу кучу копий

Aidar
02.04.2018
10:01:31
cow ненужен

Andrew
02.04.2018
10:01:46
1. Бывает полезен

Aidar
02.04.2018
10:01:47
не хочешь копии юзай стрингвью

Andrew
02.04.2018
10:01:58
2. Это не cow

Aidar
02.04.2018
10:02:14
не бывает он полезен это невявное управление ресурсами

Andrew
02.04.2018
10:02:54
Да? А shared_ptr тоже ошибка?

Aidar
02.04.2018
10:03:20
в некоторых местах явно сделать невозможно

Google

Andrew
02.04.2018
10:04:06
Если shared_ptr не ошибка, то я не понимаю, как объект = shared_ptr + 2 поля связанные с ним может быть ошибкой.

Aidar
02.04.2018
10:05:09
сделай shared_ptr<string> если надо
но врятли тебе надо
ты просто не смог определить контекст

I
02.04.2018
10:08:57
https://github.com/Microsoft/GSL/blob/master/include/gsl/string_span

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

I
02.04.2018
10:09:17
возможно с небольшим допилом это то что тебе нужно

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

Andrew
02.04.2018
10:13:59
Да, и поэтому, его нельзя нормально сохранять в контейнеры, переживающие своего создателя, в чем и проблема. В моем случае я понял, что при выдаче наружу некоторых мест мне придется конвертировать руками u_map<string_view,...> в u_map<string, ...>

Aidar
02.04.2018
10:14:12
и если тебе надо чтото хранить тебе надо юзать не стрингвью а стринг
и передавать стринг
по копии

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

Aidar
02.04.2018
10:15:45
нет зачем там ссылки если ты хочешь пережить создателя
вся проблема в нечеткости иерархии

Constantine
02.04.2018
10:17:04
У меня, кстати, безумная идея
Вот представьте класс
struct some {
std::string first:
std::string second;
};
а нельзя как-нибудь хачить SSO чтобы если первая строка короткая, в нее вторая влезала?

Google

Anatoly
02.04.2018
10:17:54

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

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

Aidar
02.04.2018
10:19:43
или оно есть всегда

Andrew
02.04.2018
10:20:19

Aidar
02.04.2018
10:20:20
или оно variant<string, string_view>

Andrew
02.04.2018
10:20:39

Constantine
02.04.2018
10:20:40
Типа легендарной std::rope

Aidar
02.04.2018
10:21:32
ну не в родителе
а в коде родителя

Constantine
02.04.2018
10:22:03
Здесь вопрос, нужна ли вам последовательность в памяти
Для этих строк

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

Constantine
02.04.2018
10:24:03

Anatoly
02.04.2018
10:24:58

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

Aidar
02.04.2018
10:26:25

Google

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

Aidar
02.04.2018
10:32:23
ваще не понимаю например в чем проблема такой штуки:
string_view cache::push(string);

Andrew
02.04.2018
10:36:37

Constantine
02.04.2018
10:37:38

Andrew
02.04.2018
10:40:05

Constantine
02.04.2018
10:42:25

Александр
02.04.2018
10:43:08

Constantine
02.04.2018
10:43:27

Andrew
02.04.2018
10:45:31

Constantine
02.04.2018
10:45:55

Aidar
02.04.2018
10:47:21

Constantine
02.04.2018
10:47:36

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

Aidar
02.04.2018
10:47:51

Constantine
02.04.2018
10:48:37
Там просто надо вешать SSO до длины в 50, видимо

Andrew
02.04.2018
10:51:37
Нет явное лучше неявного
Так это не про детали реализации. В случае правильной COW строки и ее типового использования, пользователю до фени, что там внутри происходит.

Aidar
02.04.2018
10:52:26
Мне вот не до фени когда оно лагает а когда нет
Строки один из самых частоиспользуемых ресурсов

Google

Andrew
02.04.2018
10:54:27
Так и начинаются специальные использования, это не делает COW строку плохой в своих границах применимости.

Aidar
02.04.2018
10:54:54
Делает

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

Aidar
02.04.2018
10:55:46
Из-за невозможности использования cow была придумана move semantics
Когда оверхед начал что-то значить

Andrew
02.04.2018
10:56:37
Но move semantics же не полностью заменяет COW...

Aidar
02.04.2018
10:57:10
Ну никто не пишет cow ибо он говно

Andrew
02.04.2018
10:57:13
И ничто не мешает сделать COW класс moveable

Aidar
02.04.2018
10:57:26
Cow остался в легаси
Типа кьюта

Constantine
02.04.2018
10:59:05

Anatoly
02.04.2018
11:00:54
нужна ли COW реализация в виде самопала? не нужна, поскольку есть стандарный std::shared_ptr

Andrew
02.04.2018
11:00:59

Ilia
02.04.2018
11:01:09


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

Aidar
02.04.2018
11:03:05