Здравствуйте, rg45, Вы писали:
R>Вот и я пытаюсь представить сценарий, в котором два вектора были бы выигрышнее вектора пар.
Да запросто если идет большая серия проверок на наличие ключа в map-е.
Например, у нас flat_map<int, std::array<std::byte, 64>>. И нам нужно пробежаться по 100500 значениям ключей, чтобы проверить, какие из них уже есть в словаре.
Когда ключи лежат в отдельном векторе, то для кэша процессора такая пробежка будет более щадящей, чем когда и ключ, и значение, лежат парами в одном общем векторе.
Здравствуйте, so5team, Вы писали:
S>Да запросто если идет большая серия проверок на наличие ключа в map-е. S>Например, у нас flat_map<int, std::array<std::byte, 64>>. И нам нужно пробежаться по 100500 значениям ключей, чтобы проверить, какие из них уже есть в словаре. S>Когда ключи лежат в отдельном векторе, то для кэша процессора такая пробежка будет более щадящей, чем когда и ключ, и значение, лежат парами в одном общем векторе.
Типа, серия обращений к contains, без заныривания во второй контейнер? Ну, тоже странноватый сценарий, по-моему.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, so5team, Вы писали:
S>Да запросто если идет большая серия проверок на наличие ключа в map-е. S>Например, у нас flat_map<int, std::array<std::byte, 64>>. И нам нужно пробежаться по 100500 значениям ключей, чтобы проверить, какие из них уже есть в словаре. S>Когда ключи лежат в отдельном векторе, то для кэша процессора такая пробежка будет более щадящей, чем когда и ключ, и значение, лежат парами в одном общем векторе.
Я вот смотрю, flat_map заточена на раздельную работу с двумя контейнерами. И такое действительно иногда полезно. Типа, мы строим-строим, инкапсулируем, а по итогу имеем возможность раздать коллекцию значений отдельно от ключей без дополнительных накладных расходов. Типа, есть класс с инкапсулированной мапой, который умеет что-то там акккумулировать, а наружу выставляет константный аксессор, возвращающий константную ссылку на коллекцию значений.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, пффф, Вы писали:
П>НА цппреференсе написано, что это адаптер, который поверх вектора или другого плоского контейнера предоставляет функциональность ассоциативного контейнера. Что не так?
Не так то, что flat map это устоявшийся термин и обозначает другое. Я же привёл шуточный пример с другими названиями, но если шутка непонятна, то распишу, так уж и быть. vector — это на самом деле array, array на самом деле static array, std::remove/std::remove_if на самом деле не удаляет, а меняет порядок. Такая же проблема и с flat_map.
Здравствуйте, so5team, Вы писали:
S>Жрать дерьмо под названием C++ и жаловаться на весь мир "ну какое же дерьмо мы жрем, ох, какое же это дерьмо, а мы все жрем и жрем; а ведь дерьмо же дерьмом" продолжая, что характерно, оставаться в C++, почему-то не уходя в этот прекрасный "весь остальной мир".
Какой-то истеричный взгляд. Я лишь отметил проблемы с именованием. Кстати, не я её первый заметил =) Недоумения по поводу vector и std::remove были ещё до того, как я начал профессионально использовать С++. Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript", чтобы понять, что термин устоявшийся и обознает не то, что реализовано в std::flat_map.
S>Может объясните в чем смысл? Или здесь будет так же, как с теми самыми вашими "настоящими инженерами"?
Та просто по приколу. С++ как язык не очень, это настолько очевидно, что официальные структуры США просят его чем-то заменить. Но альтернатив нет, это грустная правда. Если использовать С++ аккуратно, то можно как-то жить. Но плюсовики начинают почему-то сильно возбуждать и рвать пуканы, когда говоришь им очевидные вещи. Что касается "настоящих инженеров", то там оппоненты слились, поэтому смысла дальше продолжать не было.
Здравствуйте, andyp, Вы писали:
A>Критиковать каждый может, а вот придумать название, которое хорошо смотрится маленькими буквами с подчеркиваниями — не каждый.
Это не значит, что критиковать не надо. Задал вопрос ChatGPT, в ответ было предложено indexed_map, что вполне отражает суть, на мой взгляд. От себя могу предложить indirect_map.
Здравствуйте, cppguard, Вы писали:
C>я начал профессионально использовать С++.
Об этом знает ещё кто-нибудь, кроме тебя?
C>Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript", чтобы понять, что термин устоявшийся и обознает не то, что реализовано в std::flat_map.
Ну а сюда-то ты как забрёл? От стада отбился?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, cppguard, Вы писали:
S>>Жрать дерьмо под названием C++ и жаловаться на весь мир "ну какое же дерьмо мы жрем, ох, какое же это дерьмо, а мы все жрем и жрем; а ведь дерьмо же дерьмом" продолжая, что характерно, оставаться в C++, почему-то не уходя в этот прекрасный "весь остальной мир".
C>Какой-то истеричный взгляд.
Я вот давно замечаю, что у людей, пытающихся охаивать C++, проявляются те или иные странности с умственным развитием. Например, попытки ставить диагнозы по Интернету. Совпадение?
C>Я лишь отметил проблемы с именованием.
Какие именно проблемы, почему это проблемы и как вы предлагаете их решать?
C>Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript", чтобы понять, что термин устоявшийся и обознает не то, что реализовано в std::flat_map.
И если вы не вкуриваете, то ключевое в названии даже не map, а именно что flat, т.к. здесь явно намекается на способ представления информации. И это, кстати говоря, гораздо лучше, чем даже std::map или std::unordered_map.
S>>Может объясните в чем смысл? Или здесь будет так же, как с теми самыми вашими "настоящими инженерами"?
C>Та просто по приколу.
Тогда почему бы вам не писать такие приколы в какой-нибудь из соцсетей? Кому интересно ваше мнение, те пойдут и почитают. А вот зачем мне на профильном форуме видеть что-то вроде "в C++ опять выбрали неудачное название, не знают люди, что значит flat map в Python-е" от вас или "тупые комитетчики не сумели обойтись без ключевого слова constexpr" от Музыченко?
Вы излили эмоции, вам, может быть, даже полегчало. Но мне и другим C++никам, которые сюда приходят ради обмена опытом, это вот все зачем?
C>Но плюсовики начинают почему-то сильно возбуждать и рвать пуканы, когда говоришь им очевидные вещи.
А вы попробуйте пойти дальше и предложить решение якобы увиденных вами якобы проблем.
C>Что касается "настоящих инженеров", то там оппоненты слились, поэтому смысла дальше продолжать не было.
Так любой желающий может прочитать ветку диалога и попробовать найти там кто же эти самые настоящие инженеры. Заодно и сделать свои выводы о том, кто и как слился: https://rsdn.org/forum/cpp/8828809
Здравствуйте, rg45, Вы писали:
R>Типа, серия обращений к contains, без заныривания во второй контейнер?
С гораздо более редкими заныриваниями.
R>Ну, тоже странноватый сценарий, по-моему.
Ничего странного. Представьте, что вам нужно выбрать информацию из лог-файла на 100500 строк. В каждой строке есть ID транзакции. Этих ID немного, но на каждый ID может быть не одна тысяча строк. Вы бежите по строкам, выделяете оттуда ID транзакции и проверяете наличие ID-шника в словаре. Если нет, то сохраняете информацию о том, где и когда этот ID-шник первый раз появился.
По итогу у вас будет 100500 обращений к contains, но сама информация о каждой из транзакций будет нужна всего пару-тройку раз.
И касательно вашего второго сообщения: мне как-то больше попадались случаи, когда из map-а нужно было брать не значения отдельно от ключей, а именно что ключи отдельно от значений. Т.е. либо нужно и то, и другое, либо только ключ. А вот чтобы только значение в отрыве от ключа -- вот это гораздо реже. Но у кого-то, наверняка, бывает наоборот.
R>Типа, серия обращений к contains, без заныривания во второй контейнер? Ну, тоже странноватый сценарий, по-моему.
Один contains это серия обращений к первому контейнеру, там ведь как я понимаю бинарный поиск по массиву. Будет гораздо быстрее если контейнер с ключами целиком влезет в кэш.
Как много веселых ребят, и все делают велосипед...
ВР>как правило обычно gcc был лидером по новым плюшками ВР>как в друг clang вырвался в перед ВР>контейнер flat_map запушили
Ага, значит мне не показалось и аналогичный велосипедик, запиленный мной 7 лет назад в самом деле полезен в определенных случаях
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Один contains это серия обращений к первому контейнеру, там ведь как я понимаю бинарный поиск по массиву. Будет гораздо быстрее если контейнер с ключами целиком влезет в кэш.
Ну да. В типовом варианте это дихотомия по отсортированному контейнеру с прямым доступом (вектору).
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, cppguard, Вы писали:
C>Какой-то истеричный взгляд. Я лишь отметил проблемы с именованием. Кстати, не я её первый заметил =) Недоумения по поводу vector и std::remove были ещё до того, как я начал профессионально использовать С++. Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript", чтобы понять, что термин устоявшийся и обознает не то, что реализовано в std::flat_map.
Ради интереса погуглил. Перечисленные ключевики выводят на какие-то функции методы, которые делают разную хрень, местами отдалённо схожую. Ты бы сам лучше рассказал, что это такое, а то в зоопарке твоих флэт мэпов сам черт ногу сломит. А тут flat_map — это тип.
C>Та просто по приколу. С++ как язык не очень, это настолько очевидно, что официальные структуры США просят его чем-то заменить.
Очередные неосиляторы
C>Если использовать С++ аккуратно, то можно как-то жить.
Любой язык можно использовать неаккуратно
C>Но плюсовики начинают почему-то сильно возбуждать и рвать пуканы, когда говоришь им очевидные вещи.
Здравствуйте, cppguard, Вы писали:
A>>Критиковать каждый может, а вот придумать название, которое хорошо смотрится маленькими буквами с подчеркиваниями — не каждый.
C>Это не значит, что критиковать не надо. Задал вопрос ChatGPT, в ответ было предложено indexed_map, что вполне отражает суть, на мой взгляд.
Здравствуйте, ononim, Вы писали:
O>Ага, значит мне не показалось и аналогичный велосипедик, запиленный мной 7 лет назад в самом деле полезен в определенных случаях
Я лет 20 назад пилил себе аналогичный велосипед на векторе, правда, ключи с индексами не разделял, хранил в сортированном векторе.
Полезность, на мой взгляд, в том, что все хозяйство хранится в одном флаконе, и память лишь иногда перераспределяется, а не под каждый узел. Ну и поиск теоретически должен побыстрее работать, так как не бегаем по произвольным участкам памяти, больше попаданий в кеш должно быть
Здравствуйте, rg45, Вы писали:
П>>Разве странный? Любой поиск перебирает кучу ключей, а в данные заныривает только для найденного ключа, разве не так?
R>Ну, так, да.
R>Но только не такую уж и кучу Это же поиск логарифмической алгоритмической сложностью.
Чего это не кучу? На 1000 ключей у тебя будет десяток проверок, вполне себе кучка. Грузить в кеш 10 раз данные, которые не нужны — ну, такое себе
Здравствуйте, cppguard, Вы писали:
C>Это не значит, что критиковать не надо. Задал вопрос ChatGPT, в ответ было предложено indexed_map, что вполне отражает суть, на мой взгляд. От себя могу предложить indirect_map.
Имхо не очень. То, что эта колбаса в плоской памяти лежит — важнее имхо. Букв в слове flat всего 4, что тоже делает конкуренцию с придумывателями текущего названия сложной. seq_map тоже хуже будет — сокращение, да и для человека с чувством языка похуже чем flat.
Ладно, чота по языкознанию мне больше написать нечего
