Здравствуйте, пффф, Вы писали:
П>Здравствуйте, 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 и даже как ">>=") — соединяет одно вычисление с другим, создавая новое комбинированное. Теперь путаницы станет еще больше
Единственный пункт, с которым я могу согласиться, так уже давно замечено, что если раньше комитет пытался думать сам, то сейчас просто тащит штуки из буста. То есть, если это уже давно было названо так, то лучше так и оставить. Но запутанности это не отменяет. unordered_map тоже flat, если уж на то пошло. В целом, ещё со времён unordered_map абстракции начали сильно протекать. Раз вы такой мега-эксперт, можете подсказать реализации ассоциативных массивов НЕ через деревья поиска, и НЕ через хэш-функции? Наивные реализации типа массив пар ключ-значение рассматривать не будем.
S>Тогда почему бы вам не писать такие приколы в какой-нибудь из соцсетей? Кому интересно ваше мнение, те пойдут и почитают. А вот зачем мне на профильном форуме видеть что-то вроде "в C++ опять выбрали неудачное название, не знают люди, что значит flat map в Python-е" от вас или "тупые комитетчики не сумели обойтись без ключевого слова constexpr" от Музыченко? S>Вы излили эмоции, вам, может быть, даже полегчало. Но мне и другим C++никам, которые сюда приходят ради обмена опытом, это вот все зачем?
Может потому что это не ваш личный форум? Не хотите видеть — не читайте. Посмотрите функционал, может тут как-то можно скрыть сообщения от определённых пользователей. Или напишите расширение для браузера — вы же не хрен с горы, а эксперт по С++, такие могут и тетрис написать чисто на constexpr. Кстати, эмоции я изливаю в оффлайне. В интернете больше для лулзов что-то могу написать. К С++ я отношусь нейтрально, но к плюсовикам с иронией, потому что они реально пытаются решить сложные задачи добавлением энтропии, как в язык, так и в свои программы. Где-то за это платят большие деньги, это здорово! Но мне больше по душе технологии, которые позволяют сократить издержки, а не увеличить их.
S>А вы попробуйте пойти дальше и предложить решение якобы увиденных вами якобы проблем. S>Так любой желающий может прочитать ветку диалога и попробовать найти там кто же эти самые настоящие инженеры. Заодно и сделать свои выводы о том, кто и как слился: https://rsdn.org/forum/cpp/8828809
Да изначально же было понятно, что вы не собираетесь рассматривать мои ответы нейтрально =) Смысл чего-то выяснять? Программисты С++ круты в разговорах, когда они работают в найме. Вот когда вы станете основателем компании и будете смотреть, как из-за слишком долгого времени компиляции, из-за чрезмерно сложного кода, из-за постоянно падающих сервисов ваша компания как-то не очень зарабатывает, тогда можно будет поговорить серьёзно. Я с удовольствием выслушаю, как С++ помогает вам решить хотя бы одну из фундаментальных проблем промышленной разработки.
Здравствуйте, пффф, Вы писали:
П>Очередные неосиляторы П>Любой язык можно использовать неаккуратно П>Да нам наплевать
Вот это очень ёмкое и блестащее представление положения дель в отрасли. Пока ты в найме, то тебе действительно плевать да и в целом пофиг на то, как вообще строчки кода превращаются в деньги.
Здравствуйте, 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++ вообще не имеет отношения.
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.
Здравствуйте, 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> И если вам кажется, что одно эквивалентно другому, то кто-то из нас явно чего-то не понимает.
Это вам кажется, что мне что-то кажется.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
list (список) — что хранится, пронумерованная коллекция элементов (в отличие от Set), а array (массив) — как хранится, расположение элементов одним блоком.
Так это не из конретного ЯП, а из теории, там где монады и прочий ФП.
Это ты где такое видел?! Множества в математике обозначаются через {}. А [] обозначает обычно вектор-строку.
