@ProCxx

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

Михаил
02.04.2018
09:27:21
А я думаю тут PGO может помочь ?
Ну или просто профиль нагрузки снять и все понятно будет

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> если надо

но врятли тебе надо

ты просто не смог определить контекст

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

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

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
Типо map<std::cref<std::string>,...> ? Но у меня работы с парсингом и подстроками много, из-за чего и перешел на string_view
ну это нормально, а зачем хранить string_view? храните string и образовывайте string_view из хранимых объектов или гарантируйте, что string переживет string_view

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

Andrew
02.04.2018
10:20:19
А вам не пора пиликать персистентные структуры, если у вас такая фигня?
Так то, что я предлагаю, и является, по сути, персистентной структурой — у меня все readonly.

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

Andrew
02.04.2018
10:20:39
или оно есть всегда
Ну с моим классом оно и будет всегда

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 раз, после этого только появляются на него вьюхи.

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

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

Andrew
02.04.2018
10:36:37
Так реализовали в одной джаве, потом передумали - очень неприятные способы получить мусор в памяти
Можно, кстати, вопрос, как? За исключанием циклических ссылок, которых в данном случае быть не может, кажется, мусор при использовании shared_ptr появляться не должен.

Andrew
02.04.2018
10:40:05
Выбор подстроки как shared_ptr захватывает хозяина
Да, а что не так? Пока у меня есть хоть одна подстрока, мне нужен этот хозяин, все же верно. Как только последняя построка перестанет быть нужна, она в своем деструкторе похоронит и хозяина.

Александр
02.04.2018
10:43:08
Типа легендарной std::rope
это что? на хабре нашёл что-то

Constantine
02.04.2018
10:43:27
это что? на хабре нашёл что-то
Реализация строкового класса на персистентных структурах

Andrew
02.04.2018
10:45:31
Проблема что нужна подстрока, а основная строка давно не нужна, так что ради подстроки в 32 буквы храним 10к
А, понял, если это мусор, то да. Но ведь там есть глобальных пулл строк, так что они это специально. Если это так принципиально, то мы все равно придем к подобию COW ?

Aidar
02.04.2018
10:47:21
Constantine
02.04.2018
10:47:36
Нет явное лучше неявного
Угу, поэтому C должно быть явное

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 остался в легаси

Типа кьюта

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

Andrew
02.04.2018
11:00:59
Если я COW на std::wstring заменю у меня вся программа сломается за 20 минут
О том и разговор. COW не заменяется move semantics, последнее банально не может предложить неявного совместного использования памяти. Мне кажется, аргументы против COW вообще всегда чаще всего носят финатичный оттенок.

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

Страница 1927 из 2477