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

да да такие которые кричат «не нужен» обычно создают лапшу из говнокода и вариант-визиторов

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

Спорим, не снимут звездочку

Не только не снимут, но ещё и добавят. «За борьбу с школотронами».

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

Так когда с себя снимешь звезду, «борец с школотронами».

«упорядоченную последовательность»

а что такое - неупорядоченная последовательность???

Ты меня спрашиваешь? Спроси автора С++23 уже почти здесь (комментарий)

папрашу не путать «неупорядоченную последовательность» с «неупорядоченной последовательностью чисел» например.

то есть говорить о «неупорядоченной последовательности» еще имеет смысл, если на элементах существует порядок сам по себе(вне этой последовательности), как на натуральных числах, например.

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

папрашу не путать «неупорядоченную последовательность» с «неупорядоченной последовательностью чисел» например.

Опять мимо. Пиши это автору С++23 уже почти здесь (комментарий)

афтар бредит.

последовательность это то, что имеет операции first() и next(). prev() - не только не обязательна, но даже и нежелательна. поскольку это уже более сильная спецификация.

афтар бредит.

Почему ты пишешь мне? Пиши ему. Или ты боишься его звездочек? Кто он тебе?

Кто он тебе?

никто, как и ты. я просто пишу, на кого бог пошлет.

я просто пишу

Я так и понял - чукча. :)

Я так и понял - чукча. :)

ты может расист?(вынимая чукотский нож из-за голенища)…

ты может расист?

А какой у чукчи RGB или CMYK кожи? Мне надо свериться с расистской палитрой.

А какой у чукчи RGB или CMYK кожи?

наступит полярный день - скажу. а пока полярная ночь, все чукчи черные

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

Нет, нельзя. Вплоть до С++20 лямбды умели делать то, чего нельзя было достичь другими языковыми средствами.

да да такие которые кричат «не нужен» обычно создают лапшу из говнокода и вариант-визиторов

Аргументов, я так понимаю, не будет?

Свет включать не пробовал? Точно чукча.

и поймут что сокет для начала не асинхронный

Сокет, для начала, асинхронный. Если рассматривать исключительно berkeley sockets API, то сокет может быть как синхронным, так и асинхронным.

лапша элегантный простой код ?

браво,слив засчитан, марш с профессии

сокет не привязанная к экзекутору сущность

проблема всего лишь в дерьмовом asio который пытаются втянуть в стандарт

и который досих пор не умеет work stealing, а без него он нахрен не нужен ни в продакшинах ни тем более в стандарте

марш SOLID изучать, школота

если они друг друга взаимо заменяют

Взаимозаменяют исключительно в рамках традиционного сравнения. А отличие очень простое – strong_ordering гарантирует f(a) == f(b), а weak_ordering – нет.

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

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

Так-то паттерн-матчинг в современном C++ (с учетом современных тенденций в программировании) был бы более чем полезен.

Это спорный момент. Я немало времени писал код на Rust и других языках с поддержкой паттерн-матчинга, и я ни капли страдаю от его отсутствия в С++. Конечно, это мой субъективный опыт, но все же.

ВНЕЗАПНО, она предназначена именно для того, чтобы представить содержимое контейнера как некую последовательность, абстрагировано от конкретной реализации контейнера.

Ничто не мешает сделать reverse_iterator для односвязного списка, но нужен ли такой reverse_iterator?

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

У тех кто это предложил, есть такие основания:

The C++ Standard Library includes many «mathematical special functions» ([sf.cmath]), like incomplete elliptic integrals, Bessel functions, and other polynomials and functions named after various mathematicians. Any of them comes with its own theory and set of applications for which robust and accurate implementations are indispensible. We think that linear algebra operations are at least as broadly useful, and in many cases significantly more so.

https://en.cppreference.com/w/cpp/numeric/special_functions

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

https://en.cppreference.com/w/cpp/14

https://en.cppreference.com/w/cpp/17

https://en.cppreference.com/w/cpp/20

для 23 пока не готово :(

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

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

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

Обычный Си простой как пять копеек и код проще читается. Как по мне.

Потому что в реализациях std::unordered_map используется именно односвязный список из bucket’ов.

Я бы и прямую итерацию запретил, чтобы не гуляли по нулям.

Да, вот прямо таки вчера с удивлением узнал, что в cmath уже с c++17 есть модифицированные функции Бесселя. Мягко говоря неожиданно было :)

Реализации std::unordered_map на 95%+ являются клонами std::map. Если std::map в состоянии предоставить std::reverse_iterator, то и std::unordered_map может.

есть модифицированные функции Бесселя.

и мир заиграл новыми красками?

Реализации std::unordered_map на 95%+ являются клонами std::map.

Нет.

std::map – RB-Tree. std::unordered_map – список bucket’ов и массив для хранения указателей на некоторые bucket’ы из списка.

Реализации std::unordered_map на 95%+ являются клонами std::map

«Борец с школотронами» совсем не палится.

Потому что в реализациях std::unordered_map используется именно односвязный список из bucket’ов.

Вот с этого места поподробнее можно, пожалуйста?

Монстр стал ещё страшнее.

Выше ссылка на реализацию. Также рекомендую ознакомиться с видео, по таймингу, указанному в ссылке, достаточно наглядно разбирается идея в основе std::unordered_map.

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

какая разница, как реализован тот или иной их контейнер внутри???

Списка «bucket’ов» там не может быть по определению, ни односвязного, ни двусвязного, никакого. У господина Siborgium терминология немножко неправильная.

Вроде может:

1. https://github.com/microsoft/STL/blob/3c2fd04d441d46ec9d914d9cbb621a3bac96c3a5/stl/inc/unordered_map#L67

Наследуемся от _Hash

2. https://github.com/microsoft/STL/blob/3c2fd04d441d46ec9d914d9cbb621a3bac96c3a5/stl/inc/xhash#L319-L321

https://github.com/microsoft/STL/blob/3c2fd04d441d46ec9d914d9cbb621a3bac96c3a5/stl/inc/xhash#L1936-L1942

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

Подробнее не смотрел…

Это не важно. Если человек не знает как устроена хеш-таблица, эти «умные» слова, как их не расположи в предложении, ничего не скажут.

Спорим, не снимут звездочку

Ты что, эту ветку нельзя удалять. Где еще на ЛОРе узнаешь всю такую правду =)

узнаешь всю такую правду

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

Пусть каждый решает для себя =)

Да, согласен. У M$ так же.

Пусть каждый решает для себя

Анархия будет.

https://www.youtube.com/watch?v=OQn4xzLQD6E

Господи какое же уродство этот ваш C++

Обычный Си простой как пять копеек и код проще читается. Как по мне.

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