Re[24]: flat_map done, clang вырывается вперед - C/C++

Здравствуйте, so5team, Вы писали:

S>Жрать дерьмо под названием C++ и жаловаться на весь мир "ну какое же дерьмо мы жрем, ох, какое же это дерьмо, а мы все жрем и жрем; а ведь дерьмо же дерьмом" продолжая, что характерно, оставаться в C++, почему-то не уходя в этот прекрасный "весь остальной мир".

Какой-то истеричный взгляд. Я лишь отметил проблемы с именованием. Кстати, не я её первый заметил =) Недоумения по поводу vector и std::remove были ещё до того, как я начал профессионально использовать С++. Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript", чтобы понять, что термин устоявшийся и обознает не то, что реализовано в std::flat_map.

S>Может объясните в чем смысл? Или здесь будет так же, как с теми самыми вашими "настоящими инженерами"?

Та просто по приколу. С++ как язык не очень, это настолько очевидно, что официальные структуры США просят его чем-то заменить. Но альтернатив нет, это грустная правда. Если использовать С++ аккуратно, то можно как-то жить. Но плюсовики начинают почему-то сильно возбуждать и рвать пуканы, когда говоришь им очевидные вещи. Что касается "настоящих инженеров", то там оппоненты слились, поэтому смысла дальше продолжать не было.

Здравствуйте, cppguard, Вы писали:

C>Поражаюсь умению плюсовиков держаться традиций даже 30 лет спустя!

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

Здравствуйте, 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.

В мире C++ flat_map-у и flat_set-у уже сто лет в обед, они в Boost-е доступны уже лет 10, как минимум: https://www.boost.org/doc/libs/1_87_0/doc/html/container/non_standard_containers.html#container.non_standard_containers.flat_xxx

И если вы не вкуриваете, то ключевое в названии даже не 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 это серия обращений к первому контейнеру, там ведь как я понимаю бинарный поиск по массиву. Будет гораздо быстрее если контейнер с ключами целиком влезет в кэш.

Ну да. В типовом варианте это дихотомия по отсортированному контейнеру с прямым доступом (вектору).

Здравствуйте, rg45, Вы писали:

R>Типа, серия обращений к 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, что вполне отражает суть, на мой взгляд.

Почему ты считаешь, что это отражает суть?

C>От себя могу предложить indirect_map.

При чем тут косвенность?

Здравствуйте, ononim, Вы писали:

O>Ага, значит мне не показалось и аналогичный велосипедик, запиленный мной 7 лет назад в самом деле полезен в определенных случаях

Я лет 20 назад пилил себе аналогичный велосипед на векторе, правда, ключи с индексами не разделял, хранил в сортированном векторе.

Полезность, на мой взгляд, в том, что все хозяйство хранится в одном флаконе, и память лишь иногда перераспределяется, а не под каждый узел. Ну и поиск теоретически должен побыстрее работать, так как не бегаем по произвольным участкам памяти, больше попаданий в кеш должно быть

Здравствуйте, rg45, Вы писали:

П>>Разве странный? Любой поиск перебирает кучу ключей, а в данные заныривает только для найденного ключа, разве не так?

R>Ну, так, да.

R>Но только не такую уж и кучу

Это же поиск логарифмической алгоритмической сложностью.

Чего это не кучу? На 1000 ключей у тебя будет десяток проверок, вполне себе кучка. Грузить в кеш 10 раз данные, которые не нужны — ну, такое себе

Здравствуйте, cppguard, Вы писали:

C>Это не значит, что критиковать не надо. Задал вопрос ChatGPT, в ответ было предложено indexed_map, что вполне отражает суть, на мой взгляд. От себя могу предложить indirect_map.

Имхо не очень. То, что эта колбаса в плоской памяти лежит — важнее имхо. Букв в слове flat всего 4, что тоже делает конкуренцию с придумывателями текущего названия сложной. seq_map тоже хуже будет — сокращение, да и для человека с чувством языка похуже чем flat.

Ладно, чота по языкознанию мне больше написать нечего

Здравствуйте, пффф, Вы писали:

П>Здравствуйте, cppguard, Вы писали:

C>>Какой-то истеричный взгляд. Я лишь отметил проблемы с именованием. Кстати, не я её первый заметил =) Недоумения по поводу vector и std::remove были ещё до того, как я начал профессионально использовать С++. Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript", чтобы понять, что термин устоявшийся и обознает не то, что реализовано в std::flat_map.

П>Ради интереса погуглил. Перечисленные ключевики выводят на какие-то функции методы, которые делают разную хрень, местами отдалённо схожую. Ты бы сам лучше рассказал, что это такое, а то в зоопарке твоих флэт мэпов сам черт ногу сломит. А тут flat_map — это тип.

Так, для информации. В Scala название flatMap обозначает монадическую связку (она же известна в других языках как bind, and_then, then и даже как ">>=") — соединяет одно вычисление с другим, создавая новое комбинированное. Теперь путаницы станет еще больше

Здравствуйте, so5team, Вы писали:

S>В мире C++ flat_map-у и flat_set-у уже сто лет в обед, они в Boost-е доступны уже лет 10, как минимум: https://www.boost.org/doc/libs/1_87_0/doc/html/container/non_standard_containers.html#container.non_standard_containers.flat_xxx
S>И если вы не вкуриваете, то ключевое в названии даже не map, а именно что flat, т.к. здесь явно намекается на способ представления информации. И это, кстати говоря, гораздо лучше, чем даже std::map или std::unordered_map.

Единственный пункт, с которым я могу согласиться, так уже давно замечено, что если раньше комитет пытался думать сам, то сейчас просто тащит штуки из буста. То есть, если это уже давно было названо так, то лучше так и оставить. Но запутанности это не отменяет. unordered_map тоже flat, если уж на то пошло. В целом, ещё со времён unordered_map абстракции начали сильно протекать. Раз вы такой мега-эксперт, можете подсказать реализации ассоциативных массивов НЕ через деревья поиска, и НЕ через хэш-функции? Наивные реализации типа массив пар ключ-значение рассматривать не будем.

S>Тогда почему бы вам не писать такие приколы в какой-нибудь из соцсетей? Кому интересно ваше мнение, те пойдут и почитают. А вот зачем мне на профильном форуме видеть что-то вроде "в C++ опять выбрали неудачное название, не знают люди, что значит flat map в Python-е" от вас или "тупые комитетчики не сумели обойтись без ключевого слова constexpr" от Музыченко?
S>Вы излили эмоции, вам, может быть, даже полегчало. Но мне и другим C++никам, которые сюда приходят ради обмена опытом, это вот все зачем?

Может потому что это не ваш личный форум? Не хотите видеть — не читайте. Посмотрите функционал, может тут как-то можно скрыть сообщения от определённых пользователей. Или напишите расширение для браузера — вы же не хрен с горы, а эксперт по С++, такие могут и тетрис написать чисто на constexpr. Кстати, эмоции я изливаю в оффлайне. В интернете больше для лулзов что-то могу написать. К С++ я отношусь нейтрально, но к плюсовикам с иронией, потому что они реально пытаются решить сложные задачи добавлением энтропии, как в язык, так и в свои программы. Где-то за это платят большие деньги, это здорово! Но мне больше по душе технологии, которые позволяют сократить издержки, а не увеличить их.

S>А вы попробуйте пойти дальше и предложить решение якобы увиденных вами якобы проблем.
S>Так любой желающий может прочитать ветку диалога и попробовать найти там кто же эти самые настоящие инженеры. Заодно и сделать свои выводы о том, кто и как слился: https://rsdn.org/forum/cpp/8828809

Да изначально же было понятно, что вы не собираетесь рассматривать мои ответы нейтрально =) Смысл чего-то выяснять? Программисты С++ круты в разговорах, когда они работают в найме. Вот когда вы станете основателем компании и будете смотреть, как из-за слишком долгого времени компиляции, из-за чрезмерно сложного кода, из-за постоянно падающих сервисов ваша компания как-то не очень зарабатывает, тогда можно будет поговорить серьёзно. Я с удовольствием выслушаю, как С++ помогает вам решить хотя бы одну из фундаментальных проблем промышленной разработки.

Здравствуйте, пффф, Вы писали:

П>Почему ты считаешь, что это отражает суть?
П>При чем тут косвенность?

key -> index in container -> value

Как-то ещё нужно пояснять?

Здравствуйте, пффф, Вы писали:

П>Очередные неосиляторы

П>Любой язык можно использовать неаккуратно
П>Да нам наплевать

Вот это очень ёмкое и блестащее представление положения дель в отрасли. Пока ты в найме, то тебе действительно плевать да и в целом пофиг на то, как вообще строчки кода превращаются в деньги.

Здравствуйте, andyp, Вы писали:

A>Ладно, чота по языкознанию мне больше написать нечего

Я чувствую, что мне тоже. На cppreference примеров пока нет, а я так и не пойму, кто является целевой аудиторией flat_map? Как я понимаю, только поиск будет шустрым, а со вставкой и удалением всё плохо. И чем эта структура лучше обычной std::map со своим пулом или аллокатором, который тоже держит значения близко друг к другу, хоть и не последовательно?

Здравствуйте, cppguard, Вы писали:

C>Единственный пункт, с которым я могу согласиться

Как же нам всем повезло!

C>если раньше комитет пытался думать сам, то сейчас просто тащит штуки из буста.

Возможно, вы из-за молодости не помните одну из целей, которые ставили перед собой бустоводы в самом начале.
И, возможно, вы пришли в C++ уже после C++11, поэтому не в курсе откуда в С++ взялись shared_ptr и, скажем, std::regex.

C>unordered_map тоже flat, если уж на то пошло.

С этого места поподробнее, пожалуйста. Очень интересно.

C>можете подсказать реализации ассоциативных массивов НЕ через деревья поиска

Во-первых, деревья поиска бывают ну очень разные.

C>Наивные реализации типа массив пар ключ-значение рассматривать не будем.

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

C>Может потому что это не ваш личный форум? Не хотите видеть — не читайте.

Прям логика персонажа, который на общественной остановке написал "как же меня за***ли пидо**сы во власти!", а потом удивляется "а что я не так написал?" и заявляет "не нравится -- не читайте".

S>>Так любой желающий может прочитать ветку диалога и попробовать найти там кто же эти самые настоящие инженеры. Заодно и сделать свои выводы о том, кто и как слился: https://rsdn.org/forum/cpp/8828809

C>Да изначально же было понятно, что вы не собираетесь рассматривать мои ответы нейтрально =)

О, опять начались диагнозы по Интернету.

C>Смысл чего-то выяснять?

Как я и говорил в той теме -- нужно выяснить коэффициент доверия к вашим словам.

И да, мне таки интересно, кто же такие эти самые "нормальные инженеры". Возможно, интересно это не мне одному.

C>Вот когда вы станете основателем компании и будете смотреть, как из-за слишком долгого времени компиляции, из-за чрезмерно сложного кода, из-за постоянно падающих сервисов ваша компания как-то не очень зарабатывает, тогда можно будет поговорить серьёзно.

А вы уже основали свою?

C>Я с удовольствием выслушаю, как С++ помогает вам решить хотя бы одну из фундаментальных проблем промышленной разработки.

Ну вы бы хоть краткий список таковых предоставили, а то к тем, что вспоминается мне, C++ вообще не имеет отношения.

Здравствуйте, cppguard, Вы писали:

C>а я так и не пойму, кто является целевой аудиторией flat_map?

А не тот ли это случай, когда проблемы умственного развития множатся на недостаток опыта и получается гремучая смесь воинствующего невежества?

Здравствуйте, cppguard, Вы писали:

C>Я чувствую, что мне тоже. На cppreference примеров пока нет, а я так и не пойму, кто является целевой аудиторией flat_map? Как я понимаю, только поиск будет шустрым, а со вставкой и удалением всё плохо.

Линейная сложность.

C>И чем эта структура лучше обычной std::map со своим пулом или аллокатором, который тоже держит значения близко друг к другу, хоть и не последовательно?

а) Есть надежда на constexpr словари, если контейнер подходящий
б) Более лучший cache-friendliness при поиске ключей

Здравствуйте, cppguard, Вы писали:

П>>Почему ты считаешь, что это отражает суть?
П>>При чем тут косвенность?

C>key -> index in container -> value

C>Как-то ещё нужно пояснять?

Да, нужно. Твоё название подходит для реализации flat_map, когда ключи и данные разнесены. А если flat_map реализован как сортированный вектор пар ключ-значение? Как тогда будем его называть?

Здравствуйте, andyp, Вы писали:

C>>Это не значит, что критиковать не надо. Задал вопрос ChatGPT, в ответ было предложено indexed_map, что вполне отражает суть, на мой взгляд. От себя могу предложить indirect_map.
A>Имхо не очень. То, что эта колбаса в плоской памяти лежит — важнее имхо. Букв в слове flat всего 4
Этот аргумент имел бы смысл, если бы такая структура данных использовалась везде и постоянно и в каждой строчке кода экономилось по паре символов...

A>, что тоже делает конкуренцию с придумывателями текущего названия сложной. seq_map тоже хуже будет — сокращение,
В языке, где повсюду std, cin, cout, ios, memcpy, cvt, fs, conv и т.п. — странный аргумент.

A>да и для человека с чувством языка похуже чем flat.
Да в английском порядка миллиона слов! Ну например
plain_map
plane_map
span_map
vector_map
array_map
thin_map
flatten_map
compact_map
slim_map
consecutive_map
continuous_map
serial_map
ordered_map

пусть хоть что-нибудь, любое лучше, чем с общепринятым термином запутываться.

Здравствуйте, ·, Вы писали:

·>Ну например
·>plain_map
·>plane_map
·>span_map
·>vector_map
·>array_map
·>thin_map
·>flatten_map
·>compact_map
·>slim_map
·>consecutive_map
·>continuous_map
·>serial_map
·>ordered_map

Тут cppguard заикался о фундаментальных проблемах разработки софта. Так вот одна из них -- это выбор удачных идентификаторов. Настолько субъективная штука, что просто караул. По поводу приведенного выше списка можно сходу приводить контр-аргументы по каждому из них.

Особенно бы хорошо зашли бы названия vector_map, array_map и ordered_map тем, кто уже сейчас страдает от vector, array и unordered_map. Двойное бинго бы случилось для них.

·>пусть хоть что-нибудь, любое лучше, чем с общепринятым термином запутываться.

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

Или как много людей переживают из-за того, что компания Apple продает не яблоки?

А уж как страдают программисты с музыкальным образованием от наименования C#!

PS. Как тут не вспомнить Паркинсона с его эссе про длительность дебатов по поводу строительства АЭС и выбора меню для обеда.

Здравствуйте, so5team, Вы писали:

S>Тут cppguard заикался о фундаментальных проблемах разработки софта. Так вот одна из них -- это выбор удачных идентификаторов. Настолько субъективная штука, что просто караул. По поводу приведенного выше списка можно сходу приводить контр-аргументы по каждому из них.
Коллизия с flatmap вполне объективна, вызывает путаницу.

S>Особенно бы хорошо зашли бы названия vector_map, array_map и ordered_map тем, кто уже сейчас страдает от vector, array и unordered_map. Двойное бинго бы случилось для них.
Почему это кого-то должно беспокоить? Эти твои страдания — субъективны.

S>·>пусть хоть что-нибудь, любое лучше, чем с общепринятым термином запутываться.
S>Интересно, как много людей в мире Java страдают от оксюморона ArrayList?
Нет никакого оксюморона... всё очень чётко и однозначно.

list (список) — что хранится, пронумерованная коллекция элементов (в отличие от Set), а array (массив) — как хранится, расположение элементов одним блоком.
List — это интерфейс, у него две реализации ArrayList (храним в непрерывном массиве) и LinkedList (храним в виде связного списка).
Ещё, к примеру есть интерфейс Deque, и у него реализация ArrayDeque и например LinkedBlockingDeque.

S>Или как много людей переживают из-за того, что компания Apple продает не яблоки?
S>А уж как страдают программисты с музыкальным образованием от наименования C#!
Это уже маркетинг, а мы про инженерию и cs.

Здравствуйте, ·, Вы писали:

S>>Тут cppguard заикался о фундаментальных проблемах разработки софта. Так вот одна из них -- это выбор удачных идентификаторов. Настолько субъективная штука, что просто караул. По поводу приведенного выше списка можно сходу приводить контр-аргументы по каждому из них.
·>Коллизия с flatmap вполне объективна

Где в C++ до сих пор был flatmap?

·>, вызывает путаницу.

Привычки из других языков лучше оставлять в других языках.

S>>Особенно бы хорошо зашли бы названия vector_map, array_map и ordered_map тем, кто уже сейчас страдает от vector, array и unordered_map. Двойное бинго бы случилось для них.
·>Почему это кого-то должно беспокоить?

Вот cppguard почему-то беспокоят:

vector — это на самом деле array, array на самом деле static array

·>Эти твои страдания — субъективны.

Сперва поищите здесь мои страдания.

·>Нет никакого оксюморона... всё очень чётко и однозначно.

list (список) — что хранится, пронумерованная коллекция элементов

От оно чё. List -- это пронумерованная, оказывается. Ну OK.

Здравствуйте, ·, Вы писали:

·>Почему это кого-то должно беспокоить? Эти твои страдания — субъективны.

Точно так же, как и ваши страдания по поводу flat_map.

Здравствуйте, so5team, Вы писали:

S>·>Коллизия с flatmap вполне объективна
S>Где в C++ до сих пор был flatmap?
S>Привычки из других языков лучше оставлять в других языках.

Так это не из конретного ЯП, а из теории, там где монады и прочий ФП.
Вот тут пишут, что 1985 год, в лиспе, когда плюсов ещё не существовало!
https://stackoverflow.com/questions/49843262/where-does-the-word-flatmap-originate-from

S>>>Особенно бы хорошо зашли бы названия vector_map, array_map и ordered_map тем, кто уже сейчас страдает от vector, array и unordered_map. Двойное бинго бы случилось для них.
S>·>Почему это кого-то должно беспокоить?
S>

Вот cppguard почему-то беспокоят:
S>

vector — это на самом деле array, array на самом деле static array

Не, я спрашиваю почему чьи-то страдания должны кого-то беспокоить?

S>·>Эти твои страдания — субъективны.
S>Сперва поищите здесь мои страдания.
Страдаешь, что критикуют Особый Путь С++.

S>·>Нет никакого оксюморона... всё очень чётко и однозначно.

list (список) — что хранится, пронумерованная коллекция элементов
S>От оно чё. List -- это пронумерованная, оказывается. Ну OK.
Ну не совсем точно. Вот точнее: An ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted.
И опять же, это не "конкретный ЯП", как ты привык, а общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type)

Здравствуйте, ·, Вы писали:

·>пусть хоть что-нибудь, любое лучше, чем с общепринятым термином запутываться.

Ну вот в питоне список — нечто в квадратных скобочках. А в математике квадратные скобочки — признак неупорядоченного множества. Живем же как-то.

Здравствуйте, andyp, Вы писали:

A>·>пусть хоть что-нибудь, любое лучше, чем с общепринятым термином запутываться.
A>Ну вот в питоне список — нечто в квадратных скобочках. А в математике квадратные скобочки — признак неупорядоченного множества. Живем же как-то.

Это ты где такое видел?! Множества в математике обозначаются через {}. А [] обозначает обычно вектор-строку.

Здравствуйте, rg45, Вы писали:

R>·>Почему это кого-то должно беспокоить? Эти твои страдания — субъективны.
R>Точно так же, как и ваши страдания по поводу flat_map.
Какие? Я просто указал на фактические ошибки и провёл небольшой ликбез. Если у меня и есть страдания, так лишь по поводу безграмотности.

Здравствуйте, ·, Вы писали:

S>>Привычки из других языков лучше оставлять в других языках.
·>

Так это не из конретного ЯП, а из теории, там где монады и прочий ФП.

В теории еще и знак равенства ("=") не означает присваивания. И?

·>Вот тут пишут, что 1985 год, в лиспе, когда плюсов ещё не существовало!

Выше уже посказали, что в Scala насрали на это с большой колокольни.
В Ruby есть flatten для тех же целей. И ничего, живут же как-то.

·>Не, я спрашиваю почему чьи-то страдания должны кого-то беспокоить?

Потому, что их не могут сдержать в себе.

S>>·>Эти твои страдания — субъективны.
S>>Сперва поищите здесь мои страдания.
·>Страдаешь, что критикуют Особый Путь С++.

Не-не-не. Мне приходится через эти стоны пробираться чтобы в итоге увидеть, что ничего конструктивного в них нет. Отсюда и желание попросить людей не превращать профильный форум в забор, на котором можно написать всякое, о чем душа болит.

В общем, я за гигиену. Если cppguard тошнит от происходящего в C++, то необязательно рыгать на публике.

S>>·>Нет никакого оксюморона... всё очень чётко и однозначно.

list (список) — что хранится, пронумерованная коллекция элементов
S>>От оно чё. List -- это пронумерованная, оказывается. Ну OK.
·>Ну не совсем точно. Вот точнее: An ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted.
·>И опять же, это не "конкретный ЯП", как ты привык, а общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type)

Во-первых, давайте не будем о "как ты привык", потому что вы про меня вряд ли что-то знаете.

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

Здравствуйте, so5team, Вы писали:

S>>>Привычки из других языков лучше оставлять в других языках.
S>·>

Так это не из конретного ЯП, а из теории, там где монады и прочий ФП.
S>В теории еще и знак равенства ("=") не означает присваивания. И?
Ну в теории == тоже нет. Это уже технические ограничения клавиатур и количество пальцев на руках. Какие иероглифы используются для обозначений assignment/equal — уже мелочи жизни.

S>·>Вот тут пишут, что 1985 год, в лиспе, когда плюсов ещё не существовало!
S>Выше уже посказали, что в Scala насрали на это с большой колокольни.
S>В Ruby есть flatten для тех же целей. И ничего, живут же как-то.
Очередное безграмотное заявление. Разберись что в ruby делает flatten. Я тебе даже ссылочки дал напочитать, но ты не потрудился.

S>·>Не, я спрашиваю почему чьи-то страдания должны кого-то беспокоить?
S>Потому, что их не могут сдержать в себе.
Это их проблемы.

S>·>Страдаешь, что критикуют Особый Путь С++.
S>Не-не-не. Мне приходится через эти стоны пробираться чтобы в итоге увидеть, что ничего конструктивного в них нет. Отсюда и желание попросить людей не превращать профильный форум в забор, на котором можно написать всякое, о чем душа болит.
S>В общем, я за гигиену. Если cppguard тошнит от происходящего в C++, то необязательно рыгать на публике.
А мне пофиг кого от чего тошнит. Не пофиг когда безграмотные заявления делают.

S>·>Ну не совсем точно. Вот точнее: An ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted.
S>·>И опять же, это не "конкретный ЯП", как ты привык, а общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type)
S>Во-первых, давайте не будем о "как ты привык", потому что вы про меня вряд ли что-то знаете.
Аргументация "конкретный ЯП" — это твои слова.

S>Во-вторых, не мешало бы вам сперва сравнить свою первую формулировку про "пронумерованную коллекции" с последующей цитатой.
Ну вот опять демонстируешь полный ноль в теории. То, что в списке можно каждому элементу однозначно сопоставить номер — это следствие. Иными словами: "третий элемент списка" — имеет смысл; "третий элемент множества" — ерунда какая-то.

S> И если вам кажется, что одно эквивалентно другому, то кто-то из нас явно чего-то не понимает.
Это вам кажется, что мне что-то кажется.

Здравствуйте, ·, Вы писали:

S>>>>Привычки из других языков лучше оставлять в других языках.
S>>·>

Так это не из конретного ЯП, а из теории, там где монады и прочий ФП.
S>>В теории еще и знак равенства ("=") не означает присваивания. И?
·>Ну в теории == тоже нет.

Что значит "тоже нет"? В теории "=" -- это равенство, во многих (но не всех) языках программирования равенство -- это "==". И люди используют "==" которого в теории нет и никто не умер.

·>Это уже технические ограничения

В Паскале сочли это настолько важным, что сохранили за "=" смысл равенства.

И тем, кто программировал и на Паскале, и на Си, было по барабану -- здесь одно, здесь другое. Дело привычки, ломать из-за этого копья, как когда-то делал дедушка Вирт, не было смысла.

S>>·>Вот тут пишут, что 1985 год, в лиспе, когда плюсов ещё не существовало!
S>>Выше уже посказали, что в Scala насрали на это с большой колокольни.
S>>В Ruby есть flatten для тех же целей. И ничего, живут же как-то.
·>Очередное безграмотное заявление. Разберись что в ruby делает flatten. Я тебе даже ссылочки дал напочитать, но ты не потрудился.

Давайте обратимся к первоисточнику:

Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript"

Я поискал про flat map python, нашел, например, вот это: https://discuss.python.org/t/add-built-in-flatmap-function-to-functools/21137
И как-то не нашел принципиальных отличий от того, что делает рубиновый flatten.

Т.е. то, что cppguard считает устоявшимся термином имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten.

Если это все безграмотные заявления, то OK, пусть так и будет.

S>>·>Не, я спрашиваю почему чьи-то страдания должны кого-то беспокоить?
S>>Потому, что их не могут сдержать в себе.
·>Это их проблемы.

А вот следы их страданий на профильном форуме -- уже не только их.

S>>В общем, я за гигиену. Если cppguard тошнит от происходящего в C++, то необязательно рыгать на публике.
·>А мне пофиг кого от чего тошнит.

Мне пофиг кого от чего тошнит, не пофиг, когда это на публику выносят. Может до вас дойдет понимание разницы.

·>Не пофиг когда безграмотные заявления делают.

"А мне пофиг кого от чего тошнит." (с) Упс.

·>Аргументация "конкретный ЯП" — это твои слова.

Нет, не нужно художественной резьбы по цитатам. Здесь же все ходы записаны.

S>>Во-вторых, не мешало бы вам сперва сравнить свою первую формулировку про "пронумерованную коллекции" с последующей цитатой.
·>Ну вот опять демонстируешь полный ноль в теории. То, что в списке можно каждому элементу однозначно сопоставить номер — это следствие.

Именно что следствие. Только у вас это не следствие, это прям первым словом в вашем определении.
Только вот в списке у элементов номеров нет. Их (номера) можно вычислить при обходе списка, но самих номеров нет.

·>Иными словами: "третий элемент списка" — имеет смысл

Прикиньте: может иметь смысл, а может и нет. В списке у нас может быть всего два элемента, тогда "третий элемент списка" для такого списка смысла не имеет.

S>> И если вам кажется, что одно эквивалентно другому, то кто-то из нас явно чего-то не понимает.
·>Это вам кажется, что мне что-то кажется.

Значит мне не кажется, а вы просто ошиблись, не подумав влепили странную формулировку, а теперь пытаетесь выпелять.

Здравствуйте, ·, Вы писали:

·>

Это ты где такое видел?! Множества в математике обозначаются через {}. А [] обозначает обычно вектор-строку.

Фигурными скобочками обозначают множества, в них нет повторяющихся элементов, так что в них повторы бессмысленны, их все равно что нет. А на счет того, что квадратные скобочки обозначают список сущностей, порядок которых не важен — встречал в некоторых источниках по алгебре. У Вавилова того же в лекциях есть.

Но я это к тому, что с обозначениями можно сжиться, просто принимаем к сведенью и едем дальше.

Здравствуйте, ·, Вы писали:

·>Какие? Я просто указал на фактические ошибки и провёл небольшой ликбез. Если у меня и есть страдания, так лишь по поводу безграмотности.

Что-что ты провел?? Ты вернись лучше на свои курсы программистов, пока не поздно, потребуй, чтоб тебе деньги вернули.

Здравствуйте, andyp, Вы писали:

A>Но я это к тому, что с обозначениями можно сжиться, просто принимаем к сведенью и едем дальше.

Золотые слова!

Здравствуйте, andyp, Вы писали:

A>Фигурными скобочками обозначают множества, в них нет повторяющихся элементов, так что в них повторы бессмысленны, их все равно что нет.
Именно. Всё как и в упомянутом тобой питоне.

A>А на счет того, что квадратные скобочки обозначают список сущностей, порядок которых не важен — встречал в некоторых источниках по алгебре. У Вавилова того же в лекциях есть.
Мультимножества что-ли?.. Редкость, да и не припомню в каких ЯП они есть, тем более на уровне синтаксиса. С flatmap история другая.

A>Но я это к тому, что с обозначениями можно сжиться, просто принимаем к сведенью и едем дальше.
Сжиться не то что можно, а придётся, выбора нет. Плохо что туда в принципе заехали, особенно обидно, что из-за простой безграмотности.

Здравствуйте, rg45, Вы писали:

R>·>Какие? Я просто указал на фактические ошибки и провёл небольшой ликбез. Если у меня и есть страдания, так лишь по поводу безграмотности.
R>Что-что ты провел??
Ликбез: ликбез — это ликвидация безграмотности.

R>Ты вернись лучше на свои курсы программистов, пока не поздно, потребуй, чтоб тебе деньги вернули.
Опять на личности переходишь.

Здравствуйте, ·, Вы писали:

·>Ликбез: ликбез — это ликвидация безграмотности.

Да-да, и скажи им, что ты собеседование не прошёл.

·>Опять на личности переходишь.

Ну ты же позволяешь себе высказываться о грамотности собеседников. Ну так а почему про тебя нельзя?

Здравствуйте, so5team, Вы писали:

S>·>Ну в теории == тоже нет.
S>Что значит "тоже нет"? В теории "=" -- это равенство, во многих (но не всех) языках программирования равенство -- это "==". И люди используют "==" которого в теории нет и никто не умер.
S>·>Это уже технические ограничения
S>В Паскале сочли это настолько важным, что сохранили за "=" смысл равенства.
S>И тем, кто программировал и на Паскале, и на Си, было по барабану -- здесь одно, здесь другое. Дело привычки, ломать из-за этого копья, как когда-то делал дедушка Вирт, не было смысла.
Это значки, и в спеке яп = называется словом assignment. А вот flatmap это уже слово и понятие.

S>>>В Ruby есть flatten для тех же целей. И ничего, живут же как-то.
S>·>Очередное безграмотное заявление. Разберись что в ruby делает flatten. Я тебе даже ссылочки дал напочитать, но ты не потрудился.
S>Давайте обратимся к первоисточнику:
S>

Ради интереса хотя бы поискали "flat map python", "flat map java", "flat map javascript"

S>Я поискал про flat map python, нашел, например, вот это: https://discuss.python.org/t/add-built-in-flatmap-function-to-functools/21137
S>И как-то не нашел принципиальных отличий от того, что делает рубиновый flatten.
Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.

S>Т.е. то, что cppguard считает устоявшимся термином имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten.
Это не правда. В ruby flatten делает то же, что и в scala. ЕЩЁ раз: flatmap = flatten + map уже пол века, везде, повсюду, кроме С++.

S>Если это все безграмотные заявления, то OK, пусть так и будет.
Да, почитай доки что-ли.

S>·>Это их проблемы.
S>А вот следы их страданий на профильном форуме -- уже не только их.
Но и тех кто от этих следов страдает? Ну и пофиг.

S>·>Не пофиг когда безграмотные заявления делают.
S>"А мне пофиг кого от чего тошнит." (с) Упс.
Безграмотные заявления — это про не тошнит.

S>·>Аргументация "конкретный ЯП" — это твои слова.
S>Нет, не нужно художественной резьбы по цитатам. Здесь же все ходы записаны.
Что не так с моими цитатами?

S>·>Ну вот опять демонстируешь полный ноль в теории. То, что в списке можно каждому элементу однозначно сопоставить номер — это следствие.
S>Именно что следствие. Только у вас это не следствие, это прям первым словом в вашем определении.
Фантазируешь. Где было "моё" определение?! Там было моё объяснение на пальцах чем array от list отличается и в чём смысл ArrayList.

S>Только вот в списке у элементов номеров нет. Их (номера) можно вычислить при обходе списка, но самих номеров нет.
Что значит "нет"? В данном контексте — вычислить можно — значит есть. Вот при обходе множества — номера вычислить не получится, нет однозначного соответсвия.

S>·>Иными словами: "третий элемент списка" — имеет смысл
S>Прикиньте: может иметь смысл, а может и нет. В списке у нас может быть всего два элемента, тогда "третий элемент списка" для такого списка смысла не имеет.
Вот прикопался! А по сути есть чего сказать?

S>>> И если вам кажется, что одно эквивалентно другому, то кто-то из нас явно чего-то не понимает.
S>·>Это вам кажется, что мне что-то кажется.
S>Значит мне не кажется, а вы просто ошиблись, не подумав влепили странную формулировку, а теперь пытаетесь выпелять.
Тебе кажется, что я влеплял формулировки. Я объяснял разницу между list, array, set и т.п.

Здравствуйте, rg45, Вы писали:

R>·>Опять на личности переходишь.
R>Ну ты же позволяешь себе высказываться о грамотности собеседников.
Я высказываюсь о грамотности высказываний и указываю каким фактам они противоречат.

R> Ну так а почему про тебя нельзя?
Потому что оффтоп. Попроси модеров создать форум про меня, и там будет можно.

Здравствуйте, ·, Вы писали:

·>Я высказываюсь о грамотности высказываний и указываю каким фактам они противоречат.

Автоматом твои высказывания являются и высказываниями о личностях, делающих эти высказывания.

·>Потому что оффтоп. Попроси модеров создать форум про меня, и там будет можно.

Уж кто-бы про оффтопы хрюкал. Развели здесь опять свои пубертатные сопли, как они обижены на С++.

Здравствуйте, rg45, Вы писали:

R>·>Я высказываюсь о грамотности высказываний и указываю каким фактам они противоречат.
R>Автоматом твои высказывания являются и высказываниями о личностях, делающих эти высказывания.
Нет, ну если только у тебя в голове.

R>·>Потому что оффтоп. Попроси модеров создать форум про меня, и там будет можно.
R>Уж кто-бы про оффтопы хрюкал. Развели здесь опять свои пубертатные сопли, как они обижены на С++.
А где ты предлагаешь обсуждать имена типов в стандарте c++?

Здравствуйте, ·, Вы писали:

·>Нет, ну если только у тебя в голове.

А в твоей голове возможно, что безграмотное высказывание делает грамотный человек? Ну я давно подозревал, что с головой у тебя не все в порядке.

·>А где ты предлагаешь обсуждать имена типов в стандарте c++?

Всё это обсуждение прямо со старта вышло за рамки только лишь "обсуждения имен типов". Ты прочитай самое начало этого холивара и попробуй подключить мозги (если таковые имеются), где место этому холивару. Можно даже чуть раньше начать смотреть: https://rsdn.org/forum/cpp/8872951.1

Здравствуйте, rg45, Вы писали:

R>·>Нет, ну если только у тебя в голове.
R>А в твоей голове возможно, что безграмотное высказывание делает грамотный человек? Ну я давно подозревал, что с головой у тебя не все в порядке.
Возможно, конечно. В данном случае, человек грамотный в С++ делал неграмотные высказывания про руби, яву, питон и т.п., ну попутал flatten и flatmap, бывает, лишь бы прошло.

R>·>А где ты предлагаешь обсуждать имена типов в стандарте c++?
R>Всё это обсуждение прямо со старта вышло за рамки только лишь "обсуждения имен типов". Ты прочитай самое начало этого холивара и попробуй подключить мозги (если таковые имеются), где место этому холивару. Можно даже чуть раньше начать смотреть: https://rsdn.org/forum/cpp/8872951.1
Мне совершенно пофиг, что высказывания некоего cppguard вывело тебя за рамки, мне это неинтереснор. Лично я обсуждал тут имена типов. Так что не предъявляй мне претензии по поводу чьих-то высказываний. Если тебя чем-то не устраивают мои высказывания, я выслушаю с интересом и постараюсь ответить.

Здравствуйте, ·, Вы писали:

·>Это значки, и в спеке яп = называется словом assignment. А вот flatmap это уже слово и понятие.

О да, это же совсем другое, понимать надо! А я и не понял.

·>Я что-то не понял чего ты с чем сравниваешь и зачем.

Ну не поняли, и не поняли. Спишите на мою безграмотность.

·>Это не правда. В ruby flatten делает то же, что и в scala.

А я и не говорил, что в ruby flatten делает что-то другое.

·>ЕЩЁ раз: flatmap = flatten + map уже пол века, везде, повсюду, кроме С++.

Кстати, ссылку на Python вы дали на NumPy, а не на стандартную библиотеку Python-а. Если найдется какая-то C++ная библиотека, где будет привычный вам flatMap в виде функции, это зачтется?

S>>Если это все безграмотные заявления, то OK, пусть так и будет.
·>Да, почитай доки что-ли.

Покажите мне flat_map в стандартной библиотеке Python-а, почитаю.

S>>·>Аргументация "конкретный ЯП" — это твои слова.
S>>Нет, не нужно художественной резьбы по цитатам. Здесь же все ходы записаны.
·>Что не так с моими цитатами?

Теряете контекст и пытаетесь пришить их не в туда.

·>Фантазируешь. Где было "моё" определение?!

Здесь: https://rsdn.org/forum/cpp/8874148.1

Дословно: "list (список) — что хранится, пронумерованная коллекция элементов"

·>Там было моё объяснение на пальцах

Ах, так это опять совсем другое, надо ж было понять.

Каюсь, не понял.

Пусть будет объяснение.

Объяснение, в котором структура данных "список" является "пронумерованной коллекцией элементов" ничем не лучше определения с такой же формулировкой. Так что если вы настаиваете на словосочетании "объяснение на пальцах", пусть будет "объяснением на пальцах", херовым оно от этого быть не перестанет.

Не верите? Ну так вот вам:

An ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted.

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

·>Что значит "нет"?

То и значит. У элемента вектора номер есть.
А у элемента списка номер нужно вычислять.

·>Вот при обходе множества — номера вычислить не получится, нет однозначного соответсвия.

А здесь вы определитесь говорите ли вы про математическое понятие "множества" или про тип данных. Если про тип данных и у вас есть детерминированный способ итерироваться по его содержимому, то, сюрпрайз-сюрпрайз, вы сможете вычислить номера элементов при итерации. Как, собственно, и при итерации по списку.

·>Я объяснял разницу между list, array, set и т.п.

У вас не получилось.

Здравствуйте, ·, Вы писали:

·>Возможно, конечно. В данном случае, человек грамотный в С++ делал неграмотные высказывания про руби, яву, питон и т.п., ну попутал flatten и flatmap, бывает, лишь бы прошло.

Как ты незаметно подменил "безграмотные" на "неграмотные", типа синонимы. А как же "ликбез"?

Ну ОК. То есть, я могу назвать твои высказывания лоховскими, и это не будет переходом на личности? Правильно я понял твою мысль? Типа: "человек, грамотный (как ему кажется), в руби, яве и питоне регулярно делает лоховские высказывания о C++". Ну то есть, я не говорю, что ты лох, просто высказывания у тебя лоховские. Нормально, нет возражений?

И какого хера ты трёшь про руби, яву и питон в профильном форуме C/C++? Только не говори "не виноватая я, он сам пришёл".

·>Мне совершенно пофиг, что высказывания некоего cppguard вывело тебя за рамки, мне это неинтереснор. Лично я обсуждал тут имена типов. Так что не предъявляй мне претензии по поводу чьих-то высказываний. Если тебя чем-то не устраивают мои высказывания, я выслушаю с интересом и постараюсь ответить.

Да ты прямо сходу начал наяривать про "общепринятый" термин: http://rsdn.org/forum/cpp/8874116.1. По факту, развивая и обосновывая ту же мысль, что и cppguard. Ты не извивайся так сильно, а то пузо протрёшь.

Здравствуйте, so5team, Вы писали:

S>·>Это значки, и в спеке яп = называется словом assignment. А вот flatmap это уже слово и понятие.
S>О да, это же совсем другое, понимать надо! А я и не понял.
Да.

S>·>Это не правда. В ruby flatten делает то же, что и в scala.
S>А я и не говорил, что в ruby flatten делает что-то другое.
Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten". Нет, не даёт. В Ruby эффект flatmap-а даёт функция под совершенно неожиданным названием flat_map!!111
В scala тоже есть и flatten и flatMap c соответсвующими эффектами.

S>·>ЕЩЁ раз: flatmap = flatten + map уже пол века, везде, повсюду, кроме С++.
S>Кстати, ссылку на Python вы дали на NumPy, а не на стандартную библиотеку Python-а.
И что?

Ещё раз, для тормозов: flatmap придумали ни в питоне, ни в скале, ни в руби, ни в яве, а пол века назад в какой-то книге по CS, а популярные языки и библиотеки одинаково используют это название и понятие. Все мне известные, за одним лишь исключением — стандартная библиотека С++.

S>Если найдется какая-то C++ная библиотека, где будет привычный вам flatMap в виде функции, это зачтется?
Давай, найди, любопытно будет взглянуть.

S>>>Если это все безграмотные заявления, то OK, пусть так и будет.
S>·>Да, почитай доки что-ли.
S>Покажите мне flat_map в стандартной библиотеке Python-а, почитаю.
Что это изменит? NumPy одна из самых популярных библиотек. В почему её не хотят тащить в built-in функции — ты обсуждение сам нашёл. И нет, причина вовсе не в названии.

S>>>Нет, не нужно художественной резьбы по цитатам. Здесь же все ходы записаны.
S>·>Что не так с моими цитатами?
S>Теряете контекст и пытаетесь пришить их не в туда.
Пустое заявление.

S>·>Фантазируешь. Где было "моё" определение?!
S>Здесь: https://rsdn.org/forum/cpp/8874148.1
S>Дословно: "list (список) — что хранится, пронумерованная коллекция элементов"
Что это не определение имхо сразу очевидно. Ну ладно, каюсь, может недостаточно формально и математически точно выразился.

S>·>Там было моё объяснение на пальцах
S>Ах, так это опять совсем другое, надо ж было понять.
Ты не понял, я уточнил, и процитировал формальные определения.

S>Объяснение, в котором структура данных "список" является "пронумерованной коллекцией элементов" ничем не лучше определения с такой же формулировкой. Так что если вы настаиваете на словосочетании "объяснение на пальцах", пусть будет "объяснением на пальцах", херовым оно от этого быть не перестанет.
Пусть херовое, но хотя бы фактам не противоречит.

S>Не верите? Ну так вот вам:
S>

An ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted.

S>Найдите здесь что-либо про нумерацию. Про последовательность есть, про порядок есть, про контроль расположения есть. Только вот этот самый контроль не на нумерации построен.
Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list."
Я, похоже, неточно перевёл index/position как нумерация. Но имхо это мелкая придирка.
А ещё по другой моей ссылке https://en.wikipedia.org/wiki/List_(abstract_data_type) : "access an item by index".

S>·>Что значит "нет"?
S>То и значит. У элемента вектора номер есть.
S>А у элемента списка номер нужно вычислять.
И что?

S>·>Вот при обходе множества — номера вычислить не получится, нет однозначного соответсвия.
S>А здесь вы определитесь говорите ли вы про математическое понятие "множества" или про тип данных.
я надеялся abstract_data_type будет очевидной инфой.

S>Если про тип данных и у вас есть детерминированный способ
Если бы кабы... А кто его вам даст и с каого бодуна?

S>итерироваться по его содержимому, то, сюрпрайз-сюрпрайз, вы сможете вычислить номера элементов при итерации. Как, собственно, и при итерации по списку.
Это очередная безграмотность. У тебя может быть два эквивалентных множества, но например, созданных по-разному, которые будут выдавать разные номера для тех же элементов в зависимости от фазы луны.

S>·>Я объяснял разницу между list, array, set и т.п.
S>У вас не получилось.
Ок, как мог забесплатно. Если хочешь разобраться, найми репетитора.

Здравствуйте, rg45, Вы писали:

R>·>Возможно, конечно. В данном случае, человек грамотный в С++ делал неграмотные высказывания про руби, яву, питон и т.п., ну попутал flatten и flatmap, бывает, лишь бы прошло.
R>Как ты незаметно подменил "безграмотные" на "неграмотные", типа синонимы. А как же "ликбез"?

Ок. Перепишу: "Возможно, конечно. В данном случае, человек грамотный в С++ делал безграмотные высказывания про руби, яву, питон и т.п., ну попутал flatten и flatmap, бывает, лишь бы прошло." Полегчало?

R>Ну ОК. То есть, я могу назвать твои высказывания лоховскими, и это не будет переходом на личности? Правильно я понял твою мысль? Типа: "человек, грамотный (как ему кажется), в руби, яве и питоне регулярно делает лоховские высказывания о C++". Ну то есть, я не говорю, что ты лох, просто высказывания у тебя лоховские. Нормально, нет возражений?
А доказать? Что его высказывания были безграмотными — я привёл ссылки с фактами, которым эти высказывания прямо противоречат.

R>И какого хера ты трёшь про руби, яву и питон в профильном форуме C/C++? Только не говори "не виноватая я, он сам пришёл".
Если тебя что-то не устраивает, не читай, тебя никто не заставляет. Тут и кнопочка "Сообщить Модератору" есть.

R>·>Мне совершенно пофиг, что высказывания некоего cppguard вывело тебя за рамки, мне это неинтереснор. Лично я обсуждал тут имена типов. Так что не предъявляй мне претензии по поводу чьих-то высказываний. Если тебя чем-то не устраивают мои высказывания, я выслушаю с интересом и постараюсь ответить.
R>Да ты прямо сходу начал наяривать про "общепринятый" термин: http://rsdn.org/forum/cpp/8874116.1.
Факт, о том что он общепринятый, я подкрепил ссылкой: https://stackoverflow.com/questions/49843262/where-does-the-word-flatmap-originate-from . Что тебя ещё не устраивает в моих высказываниях?

R>По факту, развивая и обосновывая ту же мысль, что и cppguard.
А ешё я, как и сам Гитлер, огурцы кушал!

Здравствуйте, ·, Вы писали:

R>>·>Возможно, конечно. В данном случае, человек грамотный в С++ делал неграмотные высказывания про руби, яву, питон и т.п., ну попутал flatten и flatmap, бывает, лишь бы прошло.
R>>Как ты незаметно подменил "безграмотные" на "неграмотные", типа синонимы. А как же "ликбез"?

·>Ок. Перепишу: "Возможно, конечно. В данном случае, человек грамотный в С++ делал безграмотные высказывания про руби, яву, питон и т.п., ну попутал flatten и flatmap, бывает, лишь бы прошло." Полегчало?

R>>Ну ОК. То есть, я могу назвать твои высказывания лоховскими, и это не будет переходом на личности? Правильно я понял твою мысль? Типа: "человек, грамотный (как ему кажется), в руби, яве и питоне регулярно делает лоховские высказывания о C++". Ну то есть, я не говорю, что ты лох, просто высказывания у тебя лоховские. Нормально, нет возражений?
·>А доказать? Что его высказывания были безграмотными — я привёл ссылки с фактами, которым эти высказывания прямо противоречат.

R>>И какого хера ты трёшь про руби, яву и питон в профильном форуме C/C++? Только не говори "не виноватая я, он сам пришёл".
·>Если тебя что-то не устраивает, не читай, тебя никто не заставляет. Тут и кнопочка "Сообщить Модератору" есть.

R>>·>Мне совершенно пофиг, что высказывания некоего cppguard вывело тебя за рамки, мне это неинтереснор. Лично я обсуждал тут имена типов. Так что не предъявляй мне претензии по поводу чьих-то высказываний. Если тебя чем-то не устраивают мои высказывания, я выслушаю с интересом и постараюсь ответить.
R>>Да ты прямо сходу начал наяривать про "общепринятый" термин: http://rsdn.org/forum/cpp/8874116.1.
·>Факт, о том что он общепринятый, я подкрепил ссылкой: https://stackoverflow.com/questions/49843262/where-does-the-word-flatmap-originate-from . Что тебя ещё не устраивает в моих высказываниях?

R>>По факту, развивая и обосновывая ту же мысль, что и cppguard.
·>А ешё я, как и сам Гитлер, огурцы кушал!

Ты надеешься, что я буду парсить этот поток сознания?? Ну ты правда ударенный.

Здравствуйте, пффф, Вы писали:

П>Да, нужно. Твоё название подходит для реализации flat_map, когда ключи и данные разнесены. А если flat_map реализован как сортированный вектор пар ключ-значение? Как тогда будем его называть?

The class template flat_map acts as a wrapper to the two underlying containers, passed as objects of type KeyContainer and MappedContainer respectively. The first container is sorted, and for each key its corresponding value is in the second container at the same index (offset). The number of elements in both containers is the same.

Я, может, что-то не так понял, но std::flat_map явно говорит про разнесение ключей и данных по двум разным контейнерам.

Здравствуйте, so5team, Вы писали:

S>С этого места поподробнее, пожалуйста. Очень интересно.
Почитал, косяк. Я думал, что там внутри открытая адресация — плюсовики же скорость любят.

S>Как я и говорил в той теме -- нужно выяснить коэффициент доверия к вашим словам.
Кому нужно?

S>И да, мне таки интересно, кто же такие эти самые "нормальные инженеры". Возможно, интересно это не мне одному.
Которые пишут код для критически важных систем. Такое определение сойдёт?

S>А вы уже основали свою?
Спорить с претензией на элитарность и использовать аргумент "сперва добейся"? Ясно-понятно. Но таки да, основал.

S>Ну вы бы хоть краткий список таковых предоставили, а то к тем, что вспоминается мне, C++ вообще не имеет отношения.
Безопасный код? Сложность кода?

Здравствуйте, ·, Вы писали:

S>>·>Это значки, и в спеке яп = называется словом assignment. А вот flatmap это уже слово и понятие.
S>>О да, это же совсем другое, понимать надо! А я и не понял.
·>Да.

Ожидаемо. Только вот у меня нет столько "Этодругина Форте" чтобы воспринимать ваши виляния всерьез: тут есть в теории, значит минус в карму ЯП, а вот тут нет, ну и пофиг. Тут вот мы требуем flatMap в стандартной библиотеке, а вот тут ее нет ну и пофиг. Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.

S>>·>Это не правда. В ruby flatten делает то же, что и в scala.
S>>А я и не говорил, что в ruby flatten делает что-то другое.
·>Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".

А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.

Цепочка моих рассуждений, если что, была такой:

cppguard заявляет, буквально: "Во всём остальном мире flat-map это превращение древовидной структуры в плоскую".
Здесь нет flatMap = map + flatten, здесь только про превращение древовидной структуры в плоскую, это как раз то, что делает flatten.

Потом появляется комментарий от dsorokin: "В Scala название flatMap обозначает монадическую связку (она же известна в других языках как bind, and_then, then и даже как ">>=") — соединяет одно вычисление с другим, создавая новое комбинированное", на которого я и ссылаюсь.

Что и позволило мне сказать, что заявляемый cppguard-ом общеизвестный flat-map в случае Ruby делается flatten-ом, а в случае Scala flatMap означает вообще другое.

S>>·>ЕЩЁ раз: flatmap = flatten + map уже пол века, везде, повсюду, кроме С++.
S>>Кстати, ссылку на Python вы дали на NumPy, а не на стандартную библиотеку Python-а.
·>И что?

И все.

·>Ещё раз, для тормозов

Претензии здесь высказываются к стандартной библиотеке C++, в качестве примера приводится Python, в котором flat_map нет вообще. Вот это поворот!

Ах да, это же другое.

·>Пустое заявление.

И это тоже другое.

·>Ты не понял, я уточнил, и процитировал формальные определения.

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

·>Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list.

Так вот про это и был комментарий: "От оно чё. List -- это пронумерованная, оказывается. Ну OK."

Для вас список, в котором есть доступ по индексу, возможно, нормален. А вот как быть тем, кто считает это маразмом? Им жаловаться на прохой нейминг в Java? Бегать по форумам и писать "и только в Java такая херня"? Или просто пожать плечами, сказать "ну здесь так" и спокойно себе кодить на Java?

S>>А у элемента списка номер нужно вычислять.
·>И что?

И все. Хотя нет, у вас это опять пойдет по категории "это другое".

S>>·>Вот при обходе множества — номера вычислить не получится, нет однозначного соответсвия.
S>>А здесь вы определитесь говорите ли вы про математическое понятие "множества" или про тип данных.
·>я надеялся abstract_data_type будет очевидной инфой.

Зря. Потому что я не понимаю, у вас abstract data type -- это уже про программирование и про реалиазации этих самых абстрактных типов данных в ЯП, или это все еще теория.

S>>Если про тип данных и у вас есть детерминированный способ
·>Если бы кабы... А кто его вам даст и с каого бодуна?

Да как бы общепринятая вещь для реализаций такого понятия, как "множество". Например, в Java интерфейс Set наследуется от Iterable. Про C++ вообще очевидно. В Python-е используется for x in set.

·>Это очередная безграмотность. У тебя может быть два эквивалентных множества, но например, созданных по-разному, которые будут выдавать разные номера для тех же элементов в зависимости от фазы луны.

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

Здравствуйте, cppguard, Вы писали:

S>>Как я и говорил в той теме -- нужно выяснить коэффициент доверия к вашим словам.
C>Кому нужно?

Как минимум мне.

S>>И да, мне таки интересно, кто же такие эти самые "нормальные инженеры". Возможно, интересно это не мне одному.
C>Которые пишут код для критически важных систем. Такое определение сойдёт?

Нет.

S>>А вы уже основали свою?
C>Спорить с претензией на элитарность и использовать аргумент "сперва добейся"? Ясно-понятно.

И вот все у вас так: это же вы первым завели шарманку из категории "сперва добейся", вот, цитирую:

Вот когда вы станете основателем компании и будете смотреть

Типа "когда достигнешь, тогда поймешь".

C>Но таки да, основал.

Хорошо, значит в этом смысле мы можем поговорить на равных.

S>>Ну вы бы хоть краткий список таковых предоставили, а то к тем, что вспоминается мне, C++ вообще не имеет отношения.
C>Безопасный код? Сложность кода?

Тю. И это, по вашему, фундаментальные проблемы?

По секрету: безопасность кода слабо коррелирует с ЯП.
А уж сложность кода вообще штука безотносительная языка программирования.

Здравствуйте, so5team, Вы писали:

S>cppguard заявляет, буквально: "Во всём остальном мире flat-map это превращение древовидной структуры в плоскую".
S>Здесь нет flatMap = map + flatten, здесь только про превращение древовидной структуры в плоскую, это как раз то, что делает flatten.

S>Потом появляется комментарий от dsorokin: "В Scala название flatMap обозначает монадическую связку (она же известна в других языках как bind, and_then, then и даже как ">>=") — соединяет одно вычисление с другим, создавая новое комбинированное", на которого я и ссылаюсь.

S>Что и позволило мне сказать, что заявляемый cppguard-ом общеизвестный flat-map в случае Ruby делается flatten-ом, а в случае Scala flatMap означает вообще другое.

Не очень понимаю, что вы тут докапываетесь друг к другу по мелочам. Ну, да ладно!

Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой, как и SelectMany в C#, а вот в контексте контейнера будет вот тем самым map плюс flatten, опять же как в том же самом C#. Ну, и чтобы совсем было хорошо, один и тот же список можно рассматривать и как контейнер, и как недетерменированное вычисление, у которого может быть множество значений на выходе.

Слушайте, вам что, перед Новым годом заняться больше нечем?

Здравствуйте, so5team, Вы писали:

s> S>>О да, это же совсем другое, понимать надо! А я и не понял.
s> ·>Да.
s> Ожидаемо. Только вот у меня нет столько "Этодругина Форте" чтобы воспринимать ваши виляния всерьез: тут есть в теории, значит минус в карму ЯП, а вот тут нет, ну и пофиг. Тут вот мы требуем flatMap в стандартной библиотеке, а вот тут ее нет ну и пофиг.
Мы не требуем конкретно в стандартной библиотеке. Пусть в нестандартной, пофиг. Суть в том, что есть общепринятое и хорошо известное понятие флатмаппинга. И везде, во всех учебниках, во всех ЯП, оно означает одно и то же. Кроме плюсов; там это же понятие означает совершенно другое, ничего общего с общепринятым.

s>Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.
Потому что это значки, а не понятия. Попробуй поискать "how assign value in <ЯП>" и потом "how flatmap in <ЯП>".

s> ·>Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
s> А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.
Ты сказал, что "совсем другой смысл". Может я не так распарсил твоё высказывание, но это неважно. Суть в том, что смысл никакой не другой, а ровно такой же. Во всех ЯП эти термины означают одно и то же.

s> Цепочка моих рассуждений, если что, была такой:
s> cppguard заявляет, буквально: "Во всём остальном мире flat-map это превращение древовидной структуры в плоскую".
s> Здесь нет flatMap = map + flatten, здесь только про превращение древовидной структуры в плоскую, это как раз то, что делает flatten.
Тоже неважно, он неточно выразился, dsorokin правильно исправил.

s> Что и позволило мне сказать, что заявляемый cppguard-ом общеизвестный flat-map в случае Ruby делается flatten-ом, а в случае Scala flatMap означает вообще другое.
Ну ошибся, а доки поленился прочитать. Впрочем, эта ошибка не имеет значения. Это неважно, т.к. везде flatmap — функция преобразования контейнеров или подобного. И только в с++ — пошли своим путём.

s> ·>И что?
s> И все.
Вот именно.

s> Претензии здесь высказываются к стандартной библиотеке C++, в качестве примера приводится Python, в котором flat_map нет вообще. Вот это поворот!
Не к стандартной библиотеке претензии, а к понятию flat_map и что оно означает в контекстах разных ЯП.

s> Ах да, это же другое.
Да, верно.

s> ·>Пустое заявление.
s> И это тоже другое.
Конечно.

s> ·>Ты не понял, я уточнил, и процитировал формальные определения.
s> Я-то все понял, это вы с какого-то бодуна полезли доказывать, что List с нумерованными элементами -- это нормально.
Это твои фантазии.

s> ·>Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list.
s> Так вот про это и был комментарий: "От оно чё. List -- это пронумерованная, оказывается. Ну OK."
Я неточно перевёл термин indexed/position как пронумерованный, каюсь.

s> Для вас список, в котором есть доступ по индексу, возможно, нормален.
Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент. Это один из признаков, отличающих списки от множеств. Поэтому я об этом и упомянул изначально, объясняя почему в ArrayList используется слово List.
Что в LinkedList, что в ArrayList можно однозначно адресовать элемент по числовому индексу. Отличие будет лишь в вычислительной сложности операции. А для Set такой операции просто нет, вообще нет.

s> А вот как быть тем, кто считает это маразмом?
Заняться самообразованием.

Теорию CS подтянуть, про абстрактные типы данных почитать.

s> Им жаловаться на прохой нейминг в Java? Бегать по форумам и писать "и только в Java такая херня"? Или просто пожать плечами, сказать "ну здесь так" и спокойно себе кодить на Java?
Ну никто не запрещает. Можно сразу в спортлото жаловаться.

s> S>>А у элемента списка номер нужно вычислять.
s> ·>И что?
s> И все. Хотя нет, у вас это опять пойдет по категории "это другое".
Что другое?

s> ·>я надеялся abstract_data_type будет очевидной инфой.
s> Зря. Потому что я не понимаю, у вас abstract data type -- это уже про программирование и про реалиазации этих самых абстрактных типов данных в ЯП, или это все еще теория.
Так разберись.

Задавай вопросы, что неясно.

s> S>>Если про тип данных и у вас есть детерминированный способ
s> ·>Если бы кабы... А кто его вам даст и с каого бодуна?
s> Да как бы общепринятая вещь для реализаций такого понятия, как "множество". Например, в Java интерфейс Set наследуется от Iterable. Про C++ вообще очевидно. В Python-е используется for x in set.
А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."

s> Могут быть. Поэтому я и сказал "Если ... есть детерминированный способ". Очевидно, что если у вас такая реализация Set, которая при каждой итерации выдает элементы в другом порядке, то пронумеровать их не получится.
Угу. Поэтому для Set ты не можешь определить позицию каждого элемента.

avalon/3.0.0

Здравствуйте, dsorokin, Вы писали:

d> Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой,...будет вот тем самым map ...
Так вопрос на засыпку: в каком контексте FlatMap будет ассоциативным контейнером?

avalon/3.0.0

Здравствуйте, so5team, Вы писали:

S>Хорошо, значит в этом смысле мы можем поговорить на равных.
Так вот он что, Мыхалыч. Вы, оказывается, занимаетесь консалтинго-аутсорсом в С++, если я правильно понял. https://stiffstream.com/ru/services.html <- оно же? Мы могли бы сохранить несколько ватт мировой энергии, не начиная вообще этот спор. Рассказывать какие-то нелицеприятные вещи про инструмент человеку, который этим на хлеб зарабатывает, это та ещё специальная олимпиада

У меня только два вопроса: если вы работаете по time-and-material, число часов сверху ограничиваете? И как долго после сдачи проекта исправляете ошибки (если вообще занимаетесь бесплатным исправлением ошибок)? Если нет, то объясните мне, как потенциальному заказчику, как я должен спланировать бюджет проекта, если расходы потенциально могут уйти в бесконечность? Другими словами, если вы заявляете, что С++ весь такой удобный и эффективный, то какие гарантии вы даёте заказчику, чтобы он был уверен, что С++ действительно хороший выбор для его задачи, а не что просто вам нравится с ним работать, и за счёт денег заказчика вы готовы писать всякие сложные штуки, которые заказчику реально не нужны. Или к вам приходят сразу с запросом на С++?

Расскажу, как это делаю я. Обращается заказчик с задачей. В ходе R&D выясняем экономический эффект от предполагаемой работы, смотрим срок окупаемости. Работаем по часам, но ставим ограничение по общему количеству сверху, чтобы заказчик был уверен, что бюджет не выйдет за рамки. Любые ошибки исправляем за свой счёт без ограничения по сроку.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, dsorokin, Вы писали:

d>> Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой,...будет вот тем самым map ...
·>Так вопрос на засыпку: в каком контексте FlatMap будет ассоциативным контейнером?

Не знаю. А в каком?

Вот здесь https://hackage.haskell.org/package/containers-0.7/docs/Data-Map-Lazy.html слово Monad встречается только в контексте Data, а я даже не знаю, что это за зверь.

Здравствуйте, ·, Вы писали:

·>Суть в том, что есть общепринятое и хорошо известное понятие флатмаппинга. И везде, во всех учебниках, во всех ЯП, оно означает одно и то же. Кроме плюсов; там это же понятие означает совершенно другое, ничего общего с общепринятым.

Вы со своими претензиями опоздали лет на 30-35: во всем мире есть понятие map -- отображение m(x)->y, тогда как в C++ это не map, а transform. И как-то всем пофиг уже не первое десятилетие. И здесь такие пуритане "а вот как же с flat_map-ом!", и это после того как в Boost-е (т.е. во второй по значимости библиотеке в C++ после stdlib) этот самый flat_map уже лет десять, как минимум.

s>>Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.
·>Потому что это значки, а не понятия.

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

s>> ·>Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
s>> А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.
·>Ты сказал, что "совсем другой смысл".

Ну так научитесь читать, репетитора возьмите, что ли. Я не говорил, что в ruby flatten делает что-то отличное от flatten в Scala.

·>Может я не так распарсил твоё высказывание, но это неважно.

Это важно. Мы здесь можем исходить только из того, что именно люди говорят, т.к. заглянуть в голову пишущему и выяснить в каком контексте он находится невозможно. Поэтому если сказанное было ошибочным (как в моем случае, когда я посчитал, что в словах cppguard ключевым требованием к flatMap является только преобразование из древовидной структуры в плоскую), то обсуждать и исправлять можно именно то, что было сказано ошибочно.

Вы же вообще не можете понять, что я вам пишу, а потом еще и говорите, что это неважно.

·>Суть в том, что смысл никакой не другой, а ровно такой же.

Ну да, ну да. В Python flatMap-а нет вообще, в Ruby flat_map возвращает новый контейнер, тогда как в Scala flatMap возвращает один объект (который в моем мире, далеком от ФП и монад, назвали бы ленивым итератором или отображением (view) для диапазона (range)). Возврат объекта-view вместо готового контейнера -- это же ровно тоже самое, да.

s>> ·>Ты не понял, я уточнил, и процитировал формальные определения.
s>> Я-то все понял, это вы с какого-то бодуна полезли доказывать, что List с нумерованными элементами -- это нормально.
·>Это твои фантазии.

Блин, ну почему хаятели C++ в итоге демонстрируют альтернативную одаренность и пытаются спорить с собственноручно написаным же:

Нет никакого оксюморона... всё очень чётко и однозначно. list (список) — что хранится, пронумерованная коллекция элементов (в отличие от Set), а array (массив) — как хранится, расположение элементов одним блоком.

s>> Для вас список, в котором есть доступ по индексу, возможно, нормален.
·>Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент.

Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).

s>> Им жаловаться на прохой нейминг в Java? Бегать по форумам и писать "и только в Java такая херня"? Или просто пожать плечами, сказать "ну здесь так" и спокойно себе кодить на Java?
·>Ну никто не запрещает. Можно сразу в спортлото жаловаться.

Какой замечательный совет. Вам альтернативная одаренность мешает применить его к себе же по поводу C++ного flat_map-а?

·>Так разберись.

Задавай вопросы, что неясно.

Задавать вам вопросы бесполезно, вы читать не умеете и считаете, что это неважно.

·>А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."

Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения.

·>Угу. Поэтому для Set ты не можешь определить позицию каждого элемента.

А я и не говорил, что мне нужно определить позицию каждого элемента. Я говорил, что их можно нумеровать при итерации так же, как это делается при итерации по списку. Ведь если у нас список (список, а не вектор!), то мы вынуждены делать что-то вроде:

int index = 0;
for(const auto & item : container) {
  handle(item, index); // Имеем и элемент, и его порядковый номер в списке.
  ++index;
}

и тоже самое мы будем делать и с set:

int index = 0;
for(const auto & item : container) {
  handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
  ++index;
}

И если нам нужен N-й элемент, то мы будем последовательно пропускать (N-1) (скажем, через take из ranges) что для списка, что для множества.

Так что если Set дает один и тот же порядок обхода своего содержимого, то номера элементов вполне себе вычисляются. Ровно так же, как и в случае с List-ом.

Здравствуйте, cppguard, Вы писали:

C>Рассказывать какие-то нелицеприятные вещи про инструмент человеку, который этим на хлеб зарабатывает, это та ещё специальная олимпиада

Рациональный вы мой, вы, мягко говоря, задолбали своей манерой общения: на вопросы не отвечаете, ставите диагнозы по Интернету, заранее приписываете собеседнику какие-то негативные качества, и практически полный ноль в плане конкретики. Фу таким быть.

C>У меня только два вопроса: если вы работаете по time-and-material

Да. Во времена победившего agile, когда в понедельник у клиента одна задача на ближайшие две недели, а в среду появляется более приоритетное вбрасывание, в fixed price нет смысла.

C>число часов сверху ограничиваете?

Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.

C>И как долго после сдачи проекта исправляете ошибки (если вообще занимаетесь бесплатным исправлением ошибок)?

Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.

C>Если нет, то объясните мне, как потенциальному заказчику, как я должен спланировать бюджет проекта, если расходы потенциально могут уйти в бесконечность?

А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.

C>Другими словами, если вы заявляете

Мы такого не заявляли. Иногда мы помогаем разобраться в том, действительно ли C++ будет удобным и эффективным. Несколько раз мы советовали использовать вместо C++ другие языки.

C>то какие гарантии вы даёте заказчику, чтобы он был уверен, что С++ действительно хороший выбор для его задачи

Нам не нужно давать такие гарантии. Обычно к нам приходят когда кодовая база на C++ уже есть. Несколько раз были случаи, когда стартовал новый проект, но там выбирать было особо не из чего — С++ или Си или Rust. Но при выборе между C++ и Rust, кроме технических, вставали еще и различные организационные проблемы, решение которых для C++ выглядели более простыми и дешевыми.

C>а не что просто вам нравится с ним работать, и за счёт денег заказчика вы готовы писать всякие сложные штуки, которые заказчику реально не нужны.

Не знаю, поверите ли вы или нет, но проблема со всякими сложными/новыми/интересными/передовыми штуками актуальна не только для C++.

C>В ходе R&D

Я вот хз что у вас значит "R&D", потому что мы вроде как и делаем для заказчиков R&D за их счет. А уже смысл сего действа и экономический эффект -- это уже зона ответственности заказчика. Если он решает сделать аналог Excel-я или AWS S3, то это его головняк как он будет строить бизнес, организовывать продажи, и пр.

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

Здравствуйте, so5team, Вы писали:

S>Рациональный вы мой, вы, мягко говоря, задолбали своей манерой общения: на вопросы не отвечаете, ставите диагнозы по Интернету, заранее приписываете собеседнику какие-то негативные качества, и практически полный ноль в плане конкретики. Фу таким быть.

На какие вопросы? Вы тоже отвечаете обтекаемо. Про инженеров я ответил. Вам не понравилось моё определение — это уже не моя проблема. В инженерии действительно к С++ очень осторожное отношение. Даже всякие MISRA и CERT придумали. А сейчас и вообще ходят уйти от языков с неуправляемой памятью. Правда, я считаю, что нужно работать над доказуемостью программ, а отдавать всё на откуп питонам и джавам, внутри которых внезапно те же С/С++.

S>Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.
Вот именно это и интересно — как она оговаривается? В духе "ну, это займёт от 100 до 1000 человеко часов"? Или же вы в контракте прописываете точное значение или верхнюю границу? Смотрите выше про обтекаемые ответы.

S>Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.
Вы продаёте код, который через месяц может протухнуть? Или я что-то неправильно понял? Что вам мешает давать гарантию в 10 лет?

S>А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.
Нет, это одна из фундаментальных проблем некоторых компаний, которые любят за чужой счёт заниматься творчеством. Не надо только снова нападать или писать что-то про меня — только время зря потратите. Я понимаю такую позицию, особенно когда нужно кормить штат разработчиков, просто не уважаю. Когда мне говорят, что оценка бюджета это проблема, то я всегда представляю, как этот же человек приходит в строительную компанию строить дом, а ему говорят, что стройка может затянуться на годы, а сколько будет стоить — вообще непонятно, и предлагают просто платить каждый месяц N рублей. Ещё бывают перлы типа "умный дом будет экономить вам N рублей в месяц, только установите нашу новую систему за офердофига, кстати, она выполнена на noname-компонентах из Китая, которые могут стать тыквой уже завтра".

S>Не знаю, поверите ли вы или нет, но проблема со всякими сложными/новыми/интересными/передовыми штуками актуальна не только для C++.
О, я не только верю, я очень часто сталкиваюсь к этому лицом к лицу. Что ж, каждому хочется заниматься интересным и не заниматься рутиной. А попробовать что-то новое за счёт заказчика — так вообще конфетка. Я бы, возможно, принял, что это неиздежность, если бы не встречал подрядчиков, которые простые вещи делают простыми способами, быстро и дешёво. И даже совсем не сердито.

S>Я вот хз что у вас значит "R&D", потому что мы вроде как и делаем для заказчиков R&D за их счет. А уже смысл сего действа и экономический эффект -- это уже зона ответственности заказчика. Если он решает сделать аналог Excel-я или AWS S3, то это его головняк как он будет строить бизнес, организовывать продажи, и пр.
RnD у нас это выяснение проблем заказчика и первичное проектирование решений. Возможно, прототипов, с целью показать, что вообще можно сделать, и сколько это примерно будет стоить. Да, это тоже стоит денег, но эти суммы — о() от итоговой стоимости проекта. Как раз эта работа и помогает нам в дальнейшем предоставить заказчику гарантированную защиту от выхода его бюджета за uint32.

S>Образно говоря, когда кто-то строит бизнес-центр не дело сантехников выяснять насколько просто будущему владельцу будет отбить вложенное, дело сантехников так проложить канализацию, чтобы обитатели бизнес-центра в говне не утонули потом. Даже если владелец хочет максимально сэкономить на материалах.
Painters and plumbers

Всё верно насчёт сантехников, только так получается на практике, что если они не могут для конкретной задачи ответить на вопрос о стоимости, то идут лесом. А потом ещё пишут/звонят "а почему вы не выбрали нас?". А как их выбрать, если это уже моя задача предоставить заказчику среди прочего и расчёт окупаемости?

Здравствуйте, cppguard, Вы писали:

C>На какие вопросы?

Практически на все.

C>Про инженеров я ответил.

Нет. Из ваших слов даже не понятно, это разработчики программного обеспечения вообще (т.е. software engineers) или же железячники, которым нужно еще и что-то запрограммировать.

S>>Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.
C>Вот именно это и интересно — как она оговаривается?

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

S>>Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.
C>Вы продаёте код, который через месяц может протухнуть?

Мы бесплатно исправляем ошибки в своем коде, если они вылезли на поверхность в течении гарантийного срока.

C>Или я что-то неправильно понял?

Больше похоже, что не дали себе труда понять.

C>Что вам мешает давать гарантию в 10 лет?

Тот простой факт, что программ без ошибок не бывает.

И опыт.

У нас был случай, когда у заказчика вообще не было QA, ни в каком виде. То, что мы им отдавали, сразу шло в прод и проверялось на клиентах. А в силу специфики особенностей задачи у нас не было возможности собрать тестовый стенд, хотя бы отдаленно напоминающий реальную нагрузку.

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

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

S>>А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.
C>Нет, это одна из фундаментальных проблем некоторых компаний, которые любят за чужой счёт заниматься творчеством.

Да? Ну ладно, в вашей вселенной всякое может быть.

C>RnD у нас это выяснение проблем заказчика и первичное проектирование решений.

Простите, ничего не понял. Раньше на русском это называлось "обследованием объекта заказчика". К собственно к "исследованиям и реализации" это имеет крайне опосредованное отношение.

C>Painters and plumbers

Всё верно насчёт сантехников, только так получается на практике, что если они не могут для конкретной задачи ответить на вопрос о стоимости, то идут лесом.

Хватит вносить отсебятину. Вы берете предварительный набросок здания и список хотелок (например, одновременно в бизнес-центре могут находится до 1500 человек, в пике до 4500, а еще нам нужны санузлы для инвалидов-колясочников на каждом этаже (в количестве двух штук) и было бы неплохо иметь отдельные санузлы для представителей первых 15 гендеров из очередного радужного списка), прикидываете сколько и каких санузлов нужно на каждом, их пропускную способность, длину и объем коммуникаций, примерное расположение здания, возможные варианты интеграции с городскими коммуникациями и т.д., и т.п. Берете какое-то типовое оборудование (обычно то, с которым привыкли работать), стоимость каких-то типовых расходных материалов (обычно от поставщиков с которыми долго работаете), прикидываете количество людей и как-то учитываете сроки, в которые заказчик хочет уложиться, суммируете это все, домножаете на выработанный годами поправочный коэффициент и озвучиваете некоторое значение (или обозначаете вилку вокруг оного).

А дальше начинается реальная жизнь, в который выясняется, что количество и расположение санузлов изменилось, на каких-то этажах теперь размещается VIP-зона, поэтому там стоимость узлов и материалов умножается на 5, где-то в санузлы захотелось добавить еще и душевые кабины, а где-то изменилась планировка этажей и расположение труб поменялось. И т.д., и т.п.

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

C>А как их выбрать, если это уже моя задача предоставить заказчику среди прочего и расчёт окупаемости?

А я вот не знаю, какие расходы по окупаемости можно предоставить заказчику, который приходит к нам с проблемой вроде "мы импортозамещаем AWS S3, сделали обслуживание входящих запросов на X, уперлись в проблемы, их нужно разрешить". В процессе разбирательств приходим к заключению, что решается это заменой X на Y и обойдется это в ~N денег +- лапоть. При этом само обслуживание этих самых входящих запросов составляет, условно, 5% от общего объема проекта, а то и меньше.

Здравствуйте, so5team, Вы писали:

s> ·>Суть в том, что есть общепринятое и хорошо известное понятие флатмаппинга. И везде, во всех учебниках, во всех ЯП, оно означает одно и то же. Кроме плюсов; там это же понятие означает совершенно другое, ничего общего с общепринятым.
s> Вы со своими претензиями опоздали лет на 30-35: во всем мире есть понятие map -- отображение m(x)->y, тогда как в C++ это не map, а transform. И как-то всем пофиг уже не первое десятилетие. И здесь такие пуритане "а вот как же с flat_map-ом!", и это после того как в Boost-е (т.е. во второй по значимости библиотеке в C++ после stdlib) этот самый flat_map уже лет десять, как минимум.
Пофиг.

Ты опять не понял. Суть претензии не в том, как конкретный метод называется. А в том, что общепринятое понятие в контексте плюсов имеет совершенно другой смысл.
Например, в haskell тоже нет метода с названием flatmap, а конструируется из других методов. И что?

s> s>>Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.
s> ·>Потому что это значки, а не понятия.
s> Так я и говорю, что это настолько другое, что пипец.
Да, верно. Синтаксис и Семантика — две очень разные различные разницы.

s> s>> А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.
s> ·>Ты сказал, что "совсем другой смысл".
s> Ну так научитесь читать, репетитора возьмите, что ли. Я не говорил, что в ruby flatten делает что-то отличное от flatten в Scala.
И что? Ты говорил "совсем другой смысл", когда никакого другого смыла по факту нет. То что твои заблуждения основаны на словах cppguard, это твои проблемы и мне совершенно неважно, надо читать доки и учебники, а не мысли в чужих головах.

s> ·>Может я не так распарсил твоё высказывание, но это неважно.
s> Это важно. Мы здесь можем исходить только из того, что именно люди говорят, т.к. заглянуть в голову пишущему и выяснить в каком контексте он находится невозможно.
Можете, но лучше не надо. За фактами надо заглядывать не в головы, а в спеки и учебники. И тут даже уже были ссылки несколько раз.

s> Вы же вообще не можете понять, что я вам пишу, а потом еще и говорите, что это неважно.
Мне совершенно неважны источники твоих заблуждений и в чём конкретно и как заблуждаешься, мне интересны факты.

s> ·>Суть в том, что смысл никакой не другой, а ровно такой же.
s> Ну да, ну да. В Python flatMap-а нет вообще, в Ruby flat_map возвращает новый контейнер, тогда как в Scala flatMap возвращает один объект (который в моем мире, далеком от ФП и монад, назвали бы ленивым итератором или отображением (view) для диапазона (range)). Возврат объекта-view вместо готового контейнера -- это же ровно тоже самое, да.
Ну с натяжкой более менее примерно так... Вроде dsorokin всё уже расписал, довольно подробно.

s> s>> Я-то все понял, это вы с какого-то бодуна полезли доказывать, что List с нумерованными элементами -- это нормально.
s> ·>Это твои фантазии.
s> Блин, ну почему хаятели C++ в итоге демонстрируют альтернативную одаренность и пытаются спорить с собственноручно написаным же:
s> Нет никакого оксюморона... всё очень чётко и однозначно. list (список) — что хранится, пронумерованная коллекция элементов (в отличие от Set), а array (массив) — как хранится, расположение элементов одним блоком.
Это не доказательство того, что "List с нумерованными элементами -- это нормально", я такой бред никогда не заявлял, и уж тем более не пытался доказывать. А мои процитированные слова — это объяснение на пальцах почему ArrayList называется именно так.

s> ·>Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент.
s> Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).
Оно только в твоей голове. Напомню, что это общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type) , а не моё личное изобретение или мои вкусовые пристрастия.

s> ·>Ну никто не запрещает. Можно сразу в спортлото жаловаться.
s> Какой замечательный совет. Вам альтернативная одаренность мешает применить его к себе же по поводу C++ного flat_map-а?
Не волнуйся за меня, мне ничего не мешает.

s> ·>А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."
s> Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения.
Где ты увидел это? Написано же явно: no particular order.
Скажем, гипотетическая реализация коллекции при переборе может на ходу проводить какую-нибудь дефрагментацию внутреннюю и при втором переборе этой же коллекции выдать те же элементы, но в другом порядке.

s> ·>Угу. Поэтому для Set ты не можешь определить позицию каждого элемента.
s> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
Нет, не имеем. Мы имеем порядковый номер в итераторе. Iterable это такая шутка, которая умеет конструировать совсем другой тип — Iterator. И в цикле будет перебираться Iterator, а не сам контейнер.

s> И если нам нужен N-й элемент, то мы будем последовательно пропускать (N-1) (скажем, через take из ranges) что для списка, что для множества.
Угу, делать так можно, но в общем случае для множества это будет выдавать произвольный результат. Это же почти как undefined behaviour, тебе как плюсовику должно быть понятно, что закладываться на UB нельзя, даже если код вроде как бы работает.

s> Так что если Set дает один и тот же порядок обхода своего содержимого, то номера элементов вполне себе вычисляются. Ровно так же, как и в случае с List-ом.
Нет, не ровно. "no particular order" != "in proper sequence".

avalon/3.0.0

Здравствуйте, ·, Вы писали:

s>> Вы со своими претензиями опоздали лет на 30-35: во всем мире есть понятие map -- отображение m(x)->y, тогда как в C++ это не map, а transform. И как-то всем пофиг уже не первое десятилетие. И здесь такие пуритане "а вот как же с flat_map-ом!", и это после того как в Boost-е (т.е. во второй по значимости библиотеке в C++ после stdlib) этот самый flat_map уже лет десять, как минимум.
·>Пофиг.

Ты опять не понял.

Да, это настолько другое, что я в принципе не понимаю. А именно:

В теории (и в других языках) имеем общепринятое понятие map, как функцию отображения map(x)->y. А в C++ мало того, что это понятие именуется как transform, так еще и в C++ map -- это имя типа ассоциативного контейнера.

И пофиг.

·>А в том, что общепринятое понятие в контексте плюсов имеет совершенно другой смысл.

А вот тут вдруг уже не пофиг.

s>> ·>Потому что это значки, а не понятия.
s>> Так я и говорю, что это настолько другое, что пипец.
·>Да, верно. Синтаксис и Семантика — две очень разные различные разницы.

Смотрим:
— в теории есть символ "=" который имеет семантику сравнения на строгое равенство;
— в C++ есть символ "=" который имеет семантику присваивания нового значения.

Имеем: один синтаксис, разные семантики.
И это OK.

Смотрим дальше:
— в теории есть символ flat_map, который означает трансформацию элементов с сохранением результата в плоскую коллекцию;
— в C++ есть символ flat_map, который означает просто плоскую коллекцию.

Имеем: один синтаксис, разные семантики.
Но это уже не OK.

И опять здесь настолько другое, что мне этого не понять.

·>И что?

А то, что я не говорил, что flatten в Ruby делает что-то отличное от flatten в Scala. Но вы мне это в качестве претензии выдвигаете.

При этом когда я заявляю, что вы полезли доказывать, что говняный Java-вский List -- это нормально, то оказывается, что ничего такого вы не говорили.

Да, это опять совсем другое.

·>Мне совершенно неважны источники твоих заблуждений и в чём конкретно и как заблуждаешься, мне интересны факты.

Зафиксируем на время то, что вам "интересны факты".

s>> ·>Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент.
s>> Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).
·>Оно только в твоей голове. Напомню, что это общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type) , а не моё личное изобретение или мои вкусовые пристрастия.

Раз вы в очередной раз ссылаетесь на Wikipedia, то приведите оттуда цитату, в которой бы говорилось, что доступ к элементу списка по индексу -- это обязательная и неотъемлемая часть абстрактного типа List. Там ведь ни в неформальном определении:

In computer science, a list or sequence is a collection of items that are finite in number and in a particular order. An instance of a list is a computer representation of the mathematical concept of a tuple or finite sequence.

ни в формальном (см. раздел https://en.wikipedia.org/wiki/List_(abstract_data_type)#Abstract_definition) нет ничего про доступ по индексу.

Говорится только что:

Implementation of the list data structure may provide some of the following operations:
...
access an item by index

Т.е. именно что реализации абстрактного типа могут (но не обязаны) предоставлять доступ по индексу.

Это вам, как любителю фактов.

Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N) -- это говно, а не "список". Только вот в Java с этим живут десятилетия и живы.

Точно так же в C++ проживут с flat_map в виде структуры данных, а не именем алгоритма трансформации данных.

s>> ·>А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."
s>> Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения.
·>Где ты увидел это? Написано же явно: no particular order.

Перечитайте то, что я вам уже писал, там все написано.

·>Скажем, гипотетическая реализация коллекции при переборе может на ходу проводить какую-нибудь дефрагментацию внутреннюю и при втором переборе этой же коллекции выдать те же элементы, но в другом порядке.

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

s>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
·>Нет, не имеем. Мы имеем порядковый номер в итераторе.

Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).

Так что у вас здесь опять это самое "это другое, понимать надо".

Здравствуйте, so5team, Вы писали:

S>Да, это настолько другое, что я в принципе не понимаю. А именно:
S>В теории (и в других языках) имеем общепринятое понятие map, как функцию отображения map(x)->y. А в C++ мало того, что это понятие именуется как transform, так еще и в C++ map -- это имя типа ассоциативного контейнера.
Во-первых, ты разговор в сторону уводишь опять, софизм вида "раз тут плохо, так гори всё огнём!". Во-вторых, ассоциативный контейнер это таки тоже функция отображения keys->values. В-третьих, тут могу согласится, принципе это тоже не самый удачный выбор, я бы предпочёл dictionary. ИЧСХ, в шарпе, который делали как улучшенную java, исправили терминологию, молодцы.

S>·>А в том, что общепринятое понятие в контексте плюсов имеет совершенно другой смысл.
S>А вот тут вдруг уже не пофиг.
Я бы понял если бы этому было десятки лет, так ведь нет, имея уже устоявшуюся терминологию нарочно наступить на грабли...

S>- в теории есть символ "=" который имеет семантику сравнения на строгое равенство;
S>- в C++ есть символ "=" который имеет семантику присваивания нового значения.
S>Имеем: один синтаксис, разные семантики.
S>И это OK.
Довольно близкие, кстати. "Значения равны?.." vs "значения равны!!!". Это скорее уже специфика конкретных ЯП.

S>Смотрим дальше:
S>- в теории есть символ flat_map, который означает трансформацию элементов с сохранением результата в плоскую коллекцию;

Не символ, а понятие. В некоторых яп оно обозначается символом flatMap, в некоторых fmap, в некоторых bind, как ">>=", thenCompose, через list comprehension и т.п. Да и оно означает несколько другое. Соединение вычислений. В контексте списков получается новый список с другим кол-вом элементов. Флатмапить можно и другие вещи, обладающие монадическими свойствами, например, optional, future и т.п.

S>Имеем: один синтаксис, разные семантики.
S>Но это уже не OK.
S>И опять здесь настолько другое, что мне этого не понять.
Как там принято говорить: мне вас жаль.

S>·>И что?
S>А то, что я не говорил, что flatten в Ruby делает что-то отличное от flatten в Scala. Но вы мне это в качестве претензии выдвигаете.
Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten". Они не соответсвуют фактам. Каюсь, скорее всего я не так прочитал эти слова и ошибся каким конкретно фактам они не соответсвуют, но рояли не играет. Высказывание в принципе ложное.

S>При этом когда я заявляю, что вы полезли доказывать, что говняный Java-вский List -- это нормально, то оказывается, что ничего такого вы не говорили.
Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся, что врёшь. Я в данном случае вообще ничего не доказывал. Я _объяснял_, что java List соответствует общепринятому ADT List.

s>>> Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).
S>·>Оно только в твоей голове. Напомню, что это общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type) , а не моё личное изобретение или мои вкусовые пристрастия.
S>Раз вы в очередной раз ссылаетесь на Wikipedia, то приведите оттуда цитату, в которой бы говорилось, что доступ к элементу списка по индексу -- это обязательная и неотъемлемая часть абстрактного типа List. Там ведь ни в неформальном определении:
Зачем? Ты придумал бред, а мне доказывать?

S>Т.е. именно что реализации абстрактного типа могут (но не обязаны) предоставлять доступ по индексу.
Верно. А кто-то что-то говорил, что обязаны?
Ещё раз. ADT List — есть индекс/позиция у элементов и _может_ быть доступ по индексу. ADT Set — индекса нет и _не может_ быть доступа оп индексу. Про "обязаны" — это твои фантазии, ты в трёх модальностях заблудился.

S>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
Ты так говоришь, как будто это что-то плохое.

S>Точно так же в C++ проживут с flat_map в виде структуры данных, а не именем алгоритма трансформации данных.
Ты так говоришь, как будто это что-то хорошее.

S>·>Где ты увидел это? Написано же явно: no particular order.
S>Перечитайте то, что я вам уже писал, там все написано.
Мне не интересны твои фантазии. Мне интересны факты. С какого бодуна ты взял, что "Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения"? И ещё неясно с какого бодуна ты свойства типа Iterator переносишь на тип Set.

S>·>Скажем, гипотетическая реализация коллекции при переборе может на ходу проводить какую-нибудь дефрагментацию внутреннюю и при втором переборе этой же коллекции выдать те же элементы, но в другом порядке.
S>В этом гипотетическом случае у вас не будет возможности пронумеровать элементы коллекции.
ЧТД.

s>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
Физические номера в итераторе ты сам придумал, и сам обиделся.

Здравствуйте, ·, Вы писали:

S>>- в теории есть символ flat_map, который означает трансформацию элементов с сохранением результата в плоскую коллекцию;
·>

Не символ, а понятие.

Очередное это другое.

·>Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".

Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.

Именно поэтому вы вставили фразу про то, что flatten в Ruby и в Scala делает одно и тоже. Между тем, обратного я и не говорил, но вы зачем-то выделенное жирным написали.

S>>При этом когда я заявляю, что вы полезли доказывать, что говняный Java-вский List -- это нормально, то оказывается, что ничего такого вы не говорили.
·>Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся

Мои слова (в прямом негативном контексте):

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

На что вы пишете:

Нет никакого оксюморона... всё очень чётко и однозначно.

Если ArrayList не оксюморон, а все очень четко и однозначно, то трактовать сказанное вами как-то отлично от "нормально", у меня не получается.

·>Я _объяснял_, что java List соответствует общепринятому ADT List.

Только вот он не соответствует.

S>>Т.е. именно что реализации абстрактного типа могут (но не обязаны) предоставлять доступ по индексу.
·>Верно. А кто-то что-то говорил, что обязаны?

Да, вы:

Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list."
Я, похоже, неточно перевёл index/position как нумерация. Но имхо это мелкая придирка.
А ещё по другой моей ссылке https://en.wikipedia.org/wiki/List_(abstract_data_type) : "access an item by index".

Найдите здесь или где-то выше в своих словах про опциональность индекса в List.

·>Ещё раз. ADT List — есть индекс/позиция у элементов и _может_ быть доступ по индексу.

Нет. У элементов есть позиция, но индексом она не определяется. Индекс вы можете подсчитать при итерации по List-у.
Точно так же вы можете подсчитать индекс элемента при итерации по Set-у.

S>>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
·>Ты так говоришь, как будто это что-то плохое.

Я так говорю, потому что это не просто плохое, это откровенное говно.

s>>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
·>Физические номера в итераторе ты сам придумал, и сам обиделся.

Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова, а про физические номера в итераторе -- это я сам придумал? Ну чтож, еще одним "это другое" будет больше.

Здравствуйте, so5team, Вы писали:

S>Очередное это другое.

А в чем смысл и какова цель вашего спора? Вы всё еще рассчитываете его в чём-то убедить? Так это невозможно, ибо он не ищет истины. Ему нужна просто формальная победа и ради этого он не брезгует никакой демагогией. Это всё равно, что играть в шахматы с голубем.

Здравствуйте, rg45, Вы писали:

R>А в чем смысл и какова цель вашего спора? Вы всё еще рассчитываете его в чём-то убедить? Так это невозможно, ибо он не ищет истины. Ему нужна просто формальная победа и ради этого он не брезгует никакой демагогией. Это всё равно, что играть в шахматы с голубем.

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

В нескольких случаях в жизни опыт таких вот виртуальных баталий помогал.

PS. Ну и да, с flatMap я изначальный посыл понял неправильно, в процессе спора выяснилось в чем именно я ошибся.

Здравствуйте, so5team, Вы писали:

S>Так смысла и нет, в случае с данным конкретным оппонентом я просто развлекаюсь и поддерживаю форму

S>В нескольких случаях в жизни опыт таких вот виртуальных баталий помогал.

Имхо, данному персонажу давно пора закрыть вход на этот форум. Ни разу не видел, чтоб он участвовал в решении каких-то технических вопросов. Зато любое его появление выливается во флейм и словоблудие. Этот тот же Shmj, только минус адекватность. (Даже не думал, что когда-нибудь употреблю слова "Shmj" и "адекватность" в одном предложении).

Здравствуйте, so5team, Вы писали:

S>·>Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
S>

Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.

S>Именно поэтому вы вставили фразу про то, что flatten в Ruby и в Scala делает одно и тоже. Между тем, обратного я и не говорил, но вы зачем-то выделенное жирным написали.
И что? Каким фактам оно противоречит? И как это меняет мою претензию к корректности твоих слов?

S>·>Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся
S>Мои слова (в прямом негативном контексте):
S>

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

А почему это оксюморон-то?

S>На что вы пишете:
S>

Нет никакого оксюморона... всё очень чётко и однозначно.

S>Если ArrayList не оксюморон, а все очень четко и однозначно, то трактовать сказанное вами как-то отлично от "нормально", у меня не получается.
Так и не обязательно ничего трактовать. Я всё прямо и однозначно стараюсь говорить.

S>·>Я _объяснял_, что java List соответствует общепринятому ADT List.
S>Только вот он не соответствует.
Каким местом не соответствует?

S>·>Верно. А кто-то что-то говорил, что обязаны?
S>Да, вы:
S>

Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list."
S>Я, похоже, неточно перевёл index/position как нумерация. Но имхо это мелкая придирка.
S>А ещё по другой моей ссылке https://en.wikipedia.org/wiki/List_(abstract_data_type) : "access an item by index".

S>Найдите здесь или где-то выше в своих словах про опциональность индекса в List.
Во-первых, это не мои слова, а цитаты. Во-вторых, вот нашел тут: "user can access", "Some languages may allow list types to be indexed", "list data structure may provide some of the following operations: ... access an item by index".

S>·>Ещё раз. ADT List — есть индекс/позиция у элементов и _может_ быть доступ по индексу.
S>Нет. У элементов есть позиция, но индексом она не определяется. Индекс вы можете подсчитать при итерации по List-у.
В чём принципиальная разница в контексте обсуждения *List? Ок, давай забудем "индекс", будем говорить только "позиция". В нашем разговоре это рояли не играет.

S>Точно так же вы можете подсчитать индекс элемента при итерации по Set-у.
Мы можем посчитать нечто, не спорю, но вот только это не будет ни индексом элемента в Set, ни позицией.

S>>>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
S>·>Ты так говоришь, как будто это что-то плохое.
S>Я так говорю, потому что это не просто плохое, это откровенное говно.
Это твоя эмоциональная оценка, никаким фактам не соответствует, поэтому идёт в топку.

s>>>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>>>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
S>·>Физические номера в итераторе ты сам придумал, и сам обиделся.
S>Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова,
Это перепевка ваших слов "порядковый номер во множестве".

S>а про физические номера в итераторе -- это я сам придумал?
Да, конечно. Либо давай в студию мою цитату про физические номера.

Здравствуйте, ·, Вы писали:

S>>·>Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
S>>

Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.

S>>Именно поэтому вы вставили фразу про то, что flatten в Ruby и в Scala делает одно и тоже. Между тем, обратного я и не говорил, но вы зачем-то выделенное жирным написали.
·>И что?

И все.

·>Каким фактам оно противоречит?

Тому факту, что я никак не сравнивал flatten в Ruby с flatten в Scala.

·>И как это меняет мою претензию к корректности твоих слов?

Кардинально.

S>>·>Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся
S>>Мои слова (в прямом негативном контексте):
S>>

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

·>А почему это оксюморон-то?

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

·>Я всё прямо и однозначно стараюсь говорить.

И у вас получается, что "=" как обозначение операции "сравнение на равенство" -- это совершенно другое, чем "flat_map" как обозначение операции "трансформация с собиранием результата в плоский контейнер".

Херня редкая и не дружит с логикой, но зато прямо и однозначно.

S>>·>Я _объяснял_, что java List соответствует общепринятому ADT List.
S>>Только вот он не соответствует.
·>Каким местом не соответствует?

Тем, что в Java List дает доступ к элементу по индексу.

·>Во-вторых, вот нашел тут: "user can access"

Тут вот какое дело: если "user can", значит контейнер дает такую возможность. Не просто "container can provide", а именно "user can" -- возможность предоставлена, значит юзверь может воспользоваться или не воспользоваться. Но контейнером такая возможность предоставлена.

·>В чём принципиальная разница в контексте обсуждения *List? Ок, давай забудем "индекс", будем говорить только "позиция". В нашем разговоре это рояли не играет.

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

Может я не так распарсил твоё высказывание, но это неважно.

Так вот -- это не просто важно, это архиважно.

·>Мы можем посчитать нечто, не спорю, но вот только это не будет ни индексом элемента в Set, ни позицией.

Это будет таким же номером элемента при итерации, как и номер элемента в List-е, который мы можем получить только точно такой же итерацией.

S>>>>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
S>>·>Ты так говоришь, как будто это что-то плохое.
S>>Я так говорю, потому что это не просто плохое, это откровенное говно.
·>Это твоя эмоциональная оценка, никаким фактам не соответствует, поэтому идёт в топку.

Факт неявной смены сложности операции с O(1) на O(N) пациентом отвергается как незначительный. Что характерно, до этого пациент неоднократно утверждал, что его интересуют только факты.

s>>>>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>>>>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>>>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
S>>·>Физические номера в итераторе ты сам придумал, и сам обиделся.
S>>Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова,
·>Это перепевка ваших слов "порядковый номер во множестве".

Только вот в моих примерах не было никаких номеров в итераторах. Был отдельно итератор, отдельно счетчик номеров. И ключевой момент в том, что нам приходится вести этот счетчик номеров именно что отдельно и от контейнера, и от итератора.

S>>а про физические номера в итераторе -- это я сам придумал?
·>Да, конечно. Либо давай в студию мою цитату про физические номера.

Лехко:

Мы имеем порядковый номер в итераторе.

Но, можно предположить, что предлог "в" -- это еще одно "это другое".

Здравствуйте, so5team, Вы писали:

S>·>Каким фактам оно противоречит?
S>Тому факту, что я никак не сравнивал flatten в Ruby с flatten в Scala.
Это твои мысли и слова, а не факты.

S>·>И как это меняет мою претензию к корректности твоих слов?
S>Кардинально.
Ок, о чём конкретно твои слова о "совсем другой смысл" и каким фактам они соответствуют?

S>>>

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

S>·>А почему это оксюморон-то?
S>Подумайте, здесь информации было высказано предостаточно.
Ага-ага.

S>·>Я всё прямо и однозначно стараюсь говорить.
S>И у вас получается, что "=" как обозначение операции "сравнение на равенство" -- это совершенно другое, чем "flat_map" как обозначение операции "трансформация с собиранием результата в плоский контейнер".
Ещё раз. Flat Map это не обозначение, а понятие из CS. А вот "=" — это значок. Даже в scala нет значка "flat_map", а есть другой значок "flatMap", и чё?..

S>>>Только вот он не соответствует.
S>·>Каким местом не соответствует?
S>Тем, что в Java List дает доступ к элементу по индексу.
И? Это ровно то, что написано в https://en.wikipedia.org/wiki/List_(abstract_data_type) "access an item by index".

S>·>Во-вторых, вот нашел тут: "user can access"
S>Тут вот какое дело: если "user can", значит контейнер дает такую возможность. Не просто "container can provide", а именно "user can" -- возможность предоставлена, значит юзверь может воспользоваться или не воспользоваться. Но контейнером такая возможность предоставлена.
И? Можно было предоставить, вот и предоставили. Могли и не предоставлять.

S>·>В чём принципиальная разница в контексте обсуждения *List? Ок, давай забудем "индекс", будем говорить только "позиция". В нашем разговоре это рояли не играет.
S>А вот фигушки. Наличие индекса как ключа для доступа к элементу в List и есть то,
Я кажется стал догадываться в чём твой затык. Ты не различаешь List Abstract Data Type и Linked List Data Structure. Ознакомься, прежде продолжать гнуть свою линию:
https://en.wikipedia.org/wiki/List_(abstract_data_type)
https://en.wikipedia.org/wiki/Linked_list

S>вокруг чего завертелся весь сыр-бор.
Вначале я вообще написал "номер", потом уже перевёл как позиция-индекс, базируясь на цитатах из доков. Согласен, в контексте "оксюморон ArrayList" лучше всего подходит термин "позиция".

S>·>Мы можем посчитать нечто, не спорю, но вот только это не будет ни индексом элемента в Set, ни позицией.
S>Это будет таким же номером элемента при итерации, как и номер элемента в List-е, который мы можем получить только точно такой же итерацией.
Почему будет? Ты можешь свои фантазии подкрепить фактами?

S>>>·>Ты так говоришь, как будто это что-то плохое.
S>>>Я так говорю, потому что это не просто плохое, это откровенное говно.
S>·>Это твоя эмоциональная оценка, никаким фактам не соответствует, поэтому идёт в топку.
S>Факт неявной смены сложности операции с O(1) на O(N) пациентом отвергается как незначительный.
Опять врёшь и фантазируешь. И ведь цитаты-то не будет, как всегда.

S>>>>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
S>>>·>Физические номера в итераторе ты сам придумал, и сам обиделся.
S>>>Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова,
S>·>Это перепевка ваших слов "порядковый номер во множестве".
S>Только вот в моих примерах не было никаких номеров в итераторах. Был отдельно итератор, отдельно счетчик номеров. И ключевой момент в том, что нам приходится вести этот счетчик номеров именно что отдельно и от контейнера, и от итератора.
В моих примерах тоже не было. Прекращай спорить с голосами в голове.

S>>>а про физические номера в итераторе -- это я сам придумал?
S>·>Да, конечно. Либо давай в студию мою цитату про физические номера.
S>Лехко:

Мы имеем порядковый номер в итераторе.

S>Но, можно предположить, что предлог "в" -- это еще одно "это другое".
У меня проблемы со зрением... Сделай в этой цитате слово "физический" жирным, а то никак не вижу.

От:	Великий Реверс	google
Дата:	28.10.24 15:31
Оценка:

	От:	kov_serg
	Дата:	28.10.24 15:41
	Оценка:

От:	Великий Реверс	google
Дата:	28.10.24 15:44
Оценка:

	От:	kov_serg
	Дата:	28.10.24 16:24
	Оценка:

От:	Великий Реверс	google
Дата:	28.10.24 16:27
Оценка:

От:	Alexander_S_U	https://github.com/alexanders-code/cmdxmlinstaller
Дата:	28.10.24 17:47
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	24.12.24 21:02
Оценка:

От:	so5team	https://stiffstream.com
Дата:	25.12.24 04:47
Оценка:	+2 -1

	От:	Doom100500
	Дата:	29.10.24 06:42
	Оценка:

	От:	ononim
	Дата:	26.12.24 09:04
	Оценка:	+1

	От:	ononim
	Дата:	26.12.24 09:07
	Оценка:

	От:	rg45
	Дата:	26.12.24 09:37
	Оценка: