С++23 уже почти здесь

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

У тех «кто не умеет» всегда все плохо

на любом языке программирования

Жесть! Какое счастье, что я - сишник!

Обычный std::list, aka двусвязный список.

В списке могут (но не обязаны) лежать элементы bucket’ов, сами bucket’ы просто обязаны быть доступны по индексу за O(1) - в этом фундаментальный смысл любой хеш таблички.

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

умные люди давно это поняли и не пишут на C++

Си да C++ удобны для системного программирования

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

модули потихоньку взлетают

в нормальных языках модули взлетели 40-50 лет назад

люди, вам правда не жалко тратить свою жизнь на эту китайскую грамоту? сравните вот эту мешанину синтаксиса с каким-нибудь ocaml, например

Вопрос скорее в том, как лучше его в C++ оформить.

ну ты как будто первый год в плюсах, как-как: придумать очередной нескушный синтаксис ортогональный всему остальному и здравому смыслу, конечно!

с таким успехом можно сказать что и лямбды не нужны

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

они не «удобны», просто люди, которые занимаются т.н. системным программированием,

Да вы братец ЗЛЮЩИЙ КАК БЕС!

Рефлексию-то когда завезут?

За этим нужно к D обращаться. Правда, есть опасность, что это только усугубит огорчение из-за отсутствия рефлексии в с++.

За этим нужно к D обращаться. Правда, есть опасность, что это только усугубит огорчение из-за отсутствия рефлексии в с++.

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

P1673 (P1385) A free function linear algebra interface based on the BLAS [9] NO P1385 (P1673) A proposal to add linear algebra support to the C++ standard library [9] NO

Ну и слава БГ. Тащить в стандарт монстров, нужных нескольким процентам юзеров… И всех тех Бесселей еще бы туда же.

От стандартной библиотеки в первую очередь нужна поддержка языковых возможностей. Удобные примитивы ФП, генераторы. Поддержка итераторов: блин, там до сих пор нужны простыни рутины, куда там спейсшипу, тоже мне приоритеты. Хотя бы Boost.Iterator уже бы помог в std.

Но вместо этого нам тащат BLAS и Chrome.

Удобные примитивы ФП, генераторы

Генераторы добавили: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2168r1.pdf

Да и вообще с ranges провели тьму работы. Стали лучше чем в упомянутом выше D.

В чем их лучшесть?

Да и вообще с ranges провели тьму работы. Стали лучше чем в упомянутом выше D.

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

Интересно, где та тонкая грань между «свобода выбора» и «понаделали всякого, и всё глючит»?

Что ты ожидаешь от языка, который изначально был сделан в виде сплошного слоя костылей над уже имеющимся двойным слоем костылей (Си)? Метапрограммирование в C++ — это трэшак, который использовать нужно, но по минимуму. От него кайфуют разве что всякие любители хаскеля и прочего жесткого порно, где 90% времени ты любишься с языком и 10% времени решаешь задачу. Когда ты, как в хаскеле, опять получаешь сообщения об ошибках на несколько экранов, а тебе нужно к концу недели делать релиз — становится не смешно, и начинаешь завидовать людям, которые пишут на Go.

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

де 90% времени ты любишься с языком и 10% времени решаешь задачу.

А я вот это вижу по-другому: каждый раз когда приходится отклоняться от «курса» и писать на чём-то ещё - проклинаю всё, очередная прослойка «между мной и железом» которая мягко говоря - «достаёт». Мнения могут разниться, очевидно.

пля паттерн мачинга тоже не будет
нафиг это С++23, нужны столетия что бы дождаться что то действительно нужного в С++

Зачем тебе паттерн матчинг? Даже с ним в крестах функциональное программирование не имеет смысла, потому что результирующий код тяжело читать, а ошибки и вовсе нечитаемы. А как ты будешь обрабатывать ошибки паттерн-матчинга? Исключениями? Напоминаю, что в C++ нет сборщика мусора, а исключение в деструкторе при обработке исключения валит всю программу на корню. То есть, нужно либо добавлять сборку мусора и получать D, либо сделать адекватный возврат ошибок (что тяжело, учитываая наследия), ввести глубоко в языке высокоуровневые иммутабельные, а то и персистентные типы данных, как то tagged union/ADT, кортежи, массивы, строки. А еще неплохо было бы наконец сделать рефлексию, чтобы потом эту хрень было реально отлаживать. Но мы же оба понимаем, что этого никогда не будет сделано, потому что язык уже давно чрезмерно перегружен.

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

лучше бы базовыми пробелами занимались и втащили бы уже в стандартную библиотеку сокеты

Сокеты являются настолько сложными и платформозависимыми сущностями (сложнее файлов), что нет особого смысла их туда тащить. Несколько оберток вокруг отдельных аспектов сокетов — да, неплохо было бы иметь. Хотя, оные уже и так есть.

А еще неплохо было бы наконец сделать рефлексию

Не первый раз это слышу. Мы оба понимаем чего это будет стоить в runtime, правда?

It won’t be anything like C++ or Rust or Zig or any of that, but we hope it’ll be good for you, dear reader

То есть понимают, что С++, Rust и Zig гораздо более удобные, чем C

Разрабы сишных стандартво и компиляторов абсолютно четко заявили свою позицию: скорость, скорость, скорость, никаких фич по безопасности и удобству не будет введено — используйте C++ и Rust для последнего. Причем, на самом деле фич по безопасности и удоству в C++ очень мало, навскидку могу вспомнить разве что менее многословное и стандартизированное RAII, vtable, наличие замыканий, и чуть более удобное обобщенное программирование, которое, однако, при злоупотреблении быстро скатывается в то же говно, что и сишные макросы. Всё. Исключения бесполезны (как и связанные с ними «преимущества» RAII), перегрузка операторов и функций откровенно вредна, реализация базовых контейнеров на убогих шаблонах вместо встроенных типов или хотя бы более вменяемого метапрограммирования видится весьма сомнительной. Можно ли это назвать «гораздо более удобные»? Я бы это назвал «чуть менее убогие, чем Си».

Не первый раз это слышу. Мы оба понимаем чего это будет стоить в runtime, правда?

Правда. Но проблема совсем не в этом, на самом деле. Первая проблема в том, что херова туча костылей, опирающихся на бинарное представление объектов, посыпется при добавлении дополнительной ссылки на RTTI. Хотя то же самое давным-давно прекрасно работает в паскале, благодаря чему можно легко узнать тип рандомного объекта в памяти и даже прочитать-записать значения published свойств. Вторая проблема в том, что C++ и Rust злоупотребляют вспомогательными конструкциями, которые при компиляции подлежат оптимизации, то есть, вырезанию из конечного кода, но это как бы подразумевает и вырезание RTTI. А если оставлять RTTI, то внезапно остаются и ссылающиеся на него объекты, которые иначе не выполняют никакой функции. Даже несмотря на то, что это возможно сделать, реализация такого компилятора станет очень трудоемкой задачей — примерно как ни у кого не доходят руки реализовать обобщенные виртуальные функции в C++.

А я вот это вижу по-другому: каждый раз когда приходится отклоняться от «курса» и писать на чём-то ещё - проклинаю всё, очередная прослойка «между мной и железом» которая мягко говоря - «достаёт». Мнения могут разниться, очевидно

Да, я помню тебя, ты тот самый человек, для которого 5% производительности — это пропасть, потому что «теряем миллионы же». Зачем тебе C++ тогда? Если ты пишешь на C++, как на Си, то мы говорим про одно и то же — я только порицал конкретную реализацию метапрограммирования, а не весь язык в целом и общем.

Первая проблема в том, что херова туча костылей, опирающихся на бинарное представление объектов, посыпется при добавлении дополнительной ссылки на RTTI.

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

В стандартную библиотеку и так вносят все подряд

Блин, в стандартной либе C++ не так давно в принципе не существовало поддержки клавиатуры и экрана. Норм заявочка, да? Да, в последнее время их занесло в другую крайность, не спорю.

ну так-то это 2 перпендикулярные вещи и executors можно пользовать без сокетов, и сокеты можно пользовать без них, как-то же люди пишут код на POSIX сокетах и тредах и проблем не знают

Твой тезис актуален для какого-нибудь BIND или классического Apache. Но в 2021 году даже от достаточно малонагруженных сервисов ожидается параллельная обработка нескольких запросов, что тяжело сделать без хорошей поддержки асинхронности, с которой в C++ были серьезные проблемы. То есть, ты принимаешь соединение, ждешь, пока в него прилетят данные, а в это время читаешь только что пришедшие данные из старых соединений. Это произошло потому, что скорость обработки данных и ширина канала увеличились непропорционально круговой задержке, а бездарные физики не научились передавать информацию быстрее скорости света. Да, в стандартной либе крестов уже есть примитивы для асинхронного выполнения, но их мало — для полноценной сети нужен дополнительный слой абстракций над ними.

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

Я извиняюсь за личный вопрос, но... ты кроме крестов ни на чем не пишешь? Ты не сталкивался с языками, где можно отладчиком в релизной версии начать налево и направо махать объектами? Потому что только безнадежно привыкший к враждебности крестовой отладки человек может писать «в 99.99% случаев нах никому не сдалась», типа «не жили — и неча начинать». В прикладной разработке не только RTTI нужно, но еще и проверки выхода за границы буфера и чисел в рантайме, и другие способы раннего обнаружения ошибок, имеющие цену в рантайме. Кстати, в крестах уже научились в релизных сборках портируемо запоминать стэк исключения?

Да, в стандартной либе крестов

Да сдалась вам эта стандартная либа - пишите своё «родное», вы же можете - я знаю ;)

ты кроме крестов ни на чем не пишешь?

Грешон - не писал. Ну - только asm и машинный код.

Ты не сталкивался с языками, где можно отладчиком в релизной версии начать налево и направо махать объектами?

Это как? И оно быстрее asm который я «ручками» напишу?

Да сдалась вам эта стандартная либа - пишите своё «родное», вы же можете - я знаю

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

И еще сетевые драйвера с прямым отображением данных в память процесса.

Мы сейчас о чём? Solar Flare (или кто там их купил нынче)?

Я извиняюсь за личный вопрос

Не мог не спросить - с ИПАМ сложилось чего?

Не мог не спросить - с ИПАМ сложилось чего?

У меня они в долгом ящике, потому что есть два варианта привлекательнее. А c EPAM всегда успею.

А c EPAM всегда успею.

И правильно. Болото то ещё.

А как ты будешь обрабатывать ошибки паттерн-матчинга?

Какие именно ошибки?

Исключения бесполезны (как и связанные с ними «преимущества» RAII), перегрузка операторов и функций откровенно вредна, реализация базовых контейнеров на убогих шаблонах вместо встроенных типов или хотя бы более вменяемого метапрограммирования видится весьма сомнительной.

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

А вот когда вы пытаетесь своим словесным поносом поспорить с объективной реальностью, то выглядите э… неадекватно, мягко говоря.

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

С этим в C++ не было особых проблем еще в 1990-х, когда такие вещи писались посредством select-а в Unix-ах или overlappedIO в Windows. А уж с появлением библиотек вроде ACE и Asio это вообще перешло в разряд обыденности.

Но, судя по уровню вашего развития, вас тогда еще даже в планах у ваших родителей не было.

А как ты будешь обрабатывать ошибки паттерн-матчинга?

Какие именно ошибки?

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

Что такое «тэг типа» применительно к C++?

Что такое «тэг типа» применительно к C++?

Ну что у нас в std::variant хранится?

С этим в C++ не было особых проблем еще в 1990-х, когда такие вещи писались посредством select-а в Unix-ах или overlappedIO в Windows. А уж с появлением библиотек вроде ACE и Asio это вообще перешло в разряд обыденности

Если так судить, то и без C++ можно обойтись. Select и Overlapped IO — это ведь сишные интерфейсы.

Отвечать вопросом на вопрос не есть хорошо. С std::variant все просто – количество вариантов жестко ограничено и известно во время компиляции. Поэтому компилятор может проверить полноту матчинга (практически так, как это сейчас происходит при использовании std::visit).

Посему еще раз: о каких ошибках матчинга вы говорите?

Давайте с примерами.

Можно обойтись. Только вот стоить (в человекочасах) это будет сильно дороже. По моему опыту, в разы.

ЗЫ. Как раз последние 2 недели писал код, который под Windows использует overlappedIO. И C++ные возможности по инкапсуляции данных и RAII очень полезны оказались.

POSIX-сокеты есть на всех *nix-системах, а виндовые сокеты не настолько отличаются от позиксовых, поэтому не соглашусь, что там настолько все страшно и сложно, что нельзя сделать кроссплатформенную обертку. Вон, у парней из Qt все давно получилось и работает https://doc.qt.io/qt-5/qtcpsocket.html. Да, в бусте там навернута еще асинхронность, но все надо делать поступательно и было бы очень здорово хотя бы иметь просто кроссплатформенный сокет в стандрате, а поверх навернуть асинхронность всегда можно будет.

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

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

+100500

к сожалению в комитете одни бестолочи по нетворкинг дев направлению

У тебя очень плохо с пониманием темы. Изучи её лучше.

Ты так ничего не знаешь. Никакого «несуществующего» тега быть не может, а уж тем более содержимое не может некорректно.

При этом это даже не проблема в том, что C++ - такой херни нет и в си. Да везде. Это в какой такой вселенной существуют некорректные значения?

Разве что в жаваскрипте с жсоном из внешнего мира. И то даже там люди додумываются проверять всё по приходу и не пускать по программе непонятно что.

А ну я правильно задетектил скриптуха-адепта. Ну да, когда напишешь на эти «языках» что-то сложнее хеловорлда - приходи, расскажешь.

Ну и базворды уровня «релизный», «сборка» - это уровень совсем в районе дна.