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

Кстати, если у вас есть негативный опыт с ranges_v3 и Boost.Range, то std::ranges

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

менее вырывающий глаз линк имеет old вместо www https://old.reddit.com/r/cpp/comments/qug17i/c23_near_the_finish_line/

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

спасибо, я поправил ссылку.

пля паттерн мачинга тоже не будет

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

пля паттерн мачинга тоже не будет

Да. Паттерн мачинга тоже не будет.

Bjarne Stroustrup в соавторах не помог…

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf

за то я почти уверен что все что предложил саттер, все будет

как не вспомнить про спейс шип, который по итогу так никто и не знает как использовать и на вопрос чем же strong от weak ордера отличается

никто внятно ответить не может))

потому что под капотом там одна и та же малина :DD

Жалко linear algebra support to the C++ standard library NO

вообще не жалко.

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

Интересно, много ли человек знает C++ от и до.

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

У меня возникает хоть и ничем не подкреплённое, но всё же ощущение, что значение количества этих людей не превосходит ноль.

Скоро очередной франкенштейн-уродец зарелизится.

Жалко, что [в стандарт на, блин, язык не вошли раковина и чистилка бананов]

Но тем не менее получилось не мало.

Срыв покровов, наконец-то стала понятна система ценностей плюсовиков.

Рефлексию завезли?

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

и про SOLID в комитете не знают

поэтому считаю что сокет может быть только асинхронным

нет

Может быть.

Это был отчет о возможностях стандартной библиотеки.

Возможности в компилятор ещё могут добавляться. Так что рефлексия и паттерн матчинг ещё могут быть добавлены в С++23. Но могут и не добавить…

Срыв покровов, наконец-то стала понятна система ценностей плюсовиков.

ну можно почитать про прогресс С23: https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting

Кстати, прикольно там написано:

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.

Паттерн матчинг не нужен в С++.

как не вспомнить про спейс шип, который по итогу так никто и не знает как использовать

Что еще расскажешь?

вопрос чем же strong от weak ордера отличается

никто внятно ответить не может))

Советую сменить круг общения на более компетентный.

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

Сокеты и нетворкинг в целом можно втащить только после executors. Без этого получится либо вещь в себе, либо неполноценное и бесполезное убожество.

Ну да, а швейцарский нож лучше двуручной пилы.

пила лучше набора инструментов по изготовлению пилы

Научиться не сравнивать инструмент без задачи лучше, чем трындеть на ЛОРе.

P2370 Stacktrace From Exception тоже не войдёт.

Паттерн мачинг был говёный. Ещё один кривой мета-язычёк хотели в C++ затолкать.

Интересно, много ли человек знает C++ от и до.

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

Это главное

Что до тех кто предпочитает вычислить 2 + 2 с использованием тройного интеграла, то это от того, что они не умеют использовать знания, полученные при изучении арифметики …

Так выпьем же за

Кибернетики  

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

Пост был не о том, что стандарты не нужны, а о том, что часто некоторые похожи на «тракториста»

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

Паттерн матчинг не нужен в С++.

Вынужден активно применять std::visit совместно с трюком overloadded (потому, что остальные способы работы с std::variant сильно хуже). Выглядит это в коде так себе: и излишне многословно, и читать приходится чуть-ли не задом наперед.

Есть надежда, что паттерн-матчинг сделает подобную работу намного удобнее и понятнее.

Но если «паттерн матчинг не нужен в C++», то что можно взять взамен?

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

Вынужден активно применять std::visit совместно с трюком overloadded (потому, что остальные способы работы с std::variant сильно хуже)

Речь не только о std::variant, а об сопоставлении с образцом практически произвольных типов данных.

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

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

С++ можно условно разделить на два уровня. Базовый язык – (за вычетом некоторых расхождений) С (возможно, с классами), и ++ сверху. Отношение достаточно сильно напоминает отношение TS и JS.

В С++ есть сопоставление с образцом, оно крайне развито и постоянно используется – это сопоставление с образцом при выборе перегрузки из overload set. В С++20, с появлением концептов, оно стало полноправным членом языка – SFINAE не имело своего синтаксиса, и было откровенно уродливым.

В «С» сопоставления с образцом нет.

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

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

Этот пропозал добавляет новый синтаксис – во многих местах ломающий совместимость – буквально для всего подряд. При этом он не предлагает почти ничего, чего нельзя было бы реализовать средствами языка, по сути являясь синтаксическим сахаром. Наконец, этот сахар завязывается на чисто библиотечные элементы языка – T::index(), что еще ухудшает его позиции.

При этом паттерн-матчинг над «С» достаточно просто реализуется средствами «++». Здесь уже был топик с примером того, как просто реализовать сопоставление с образцом. Я не буду сейчас его искать, но приведу код, который писал сам какое-то время назад.

// примитив для compile-time строк
template <std::size_t N>
struct string_lit {
    constexpr string_lit(const char (&s)[N]) {
        std::copy_n(s, N, str);
    }
    constexpr bool operator == (std::string_view view) const {
        return std::string_view{ str } == view;
    }
    char str[N];
};

template <string_lit word>
constexpr auto on_(auto && f) {
    return [=](std::string_view sample) -> bool {
        auto matches = word == sample;
        if (matches) {
            f();
        }
        return matches;
    };
};

constexpr auto else_(auto && f) {
    return [=](auto _) { f(); return true; };
};

void match(std::string_view sample, auto && try1) {
    try1(sample);
}

void match(std::string_view sample, auto && try1, auto && ... tries) {
    if (!try1(sample)) {
        match(sample, std::forward<decltype(tries)>(tries)...);
    }
}

Этих 40 строк уже достаточно для того, чтобы писать

match(
    sample,
    on_<"ABC">([&]() { ... },
    on_<"CDE">([&]() { ... },
    else_([&](){ ... })
) 

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

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

Речь не только о std::variant, а об сопоставлении с образцом практически произвольных типов данных.

Речь о том, как упростить жизнь конкретным разработчикам в конкретных ситуациях. Например, включение std::variant в стандарт упрощает жизнь тем, кто не хочет тащить в проект какую-то стороннюю реализацию variant-а.

Вот у меня сейчас не то, чтобы проблемы с std::visit, но явное ощущение, что работа с std::variant должна быть проще. И это проще хотелось бы получить из коробки вместе с компилятором.

Не понял, что вы имеете в виду под «чуть-ли не задом наперед».

Вместо:

match(do_something()) {
  case variant1: ...;
  case variant2: ...;
  ...
}

приходится читать в обратном направлении:

std::visit( overloadded {
  [](variant1) {...},
  [](variant2) {...},
  ...
  },
  do_something() );

Когда списки захвата не пустые, а сами лямбды для обработки вариантов не однострочники, то среди простыни std::visit не так-то и просто выцепить глазами вызов do_something.

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

Только вот никто не предупредит вас о забытом else.

Речь о том, как упростить жизнь конкретным разработчикам в конкретных ситуациях.

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

приходится читать в обратном направлении:

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

Когда списки захвата не пустые, а сами лямбды для обработки вариантов не однострочники, то среди простыни std::visit не так-то и просто выцепить глазами вызов do_something.

Это тоже правда. Однако, предлагаемый синтаксис тоже вовсе не выглядит чистым.

Только вот никто не предупредит вас о забытом else.

Ну почему же. Достаточно сделать static_assert на то, что else не находится в середине списка, и выводить warning, если else не в конце списка.

Какая рефлексия? У них в std::unordered_map нет итератора в обратном направлении, из-за чего из QHashIterator решили задепрекейтить previous (и прочее). Зато об ranges и views упариваются как могут, скоро туда добавят и код кофеварки заодно, но стандартные контейнеры так и будут вручную проверять индексы.

Однако, предлагаемый синтаксис тоже вовсе не выглядит чистым.

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

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

unordered

нет итератора в обратном направлении.

Кто-то не умеет в логику. Какое обратное направление? Его просто нет.

Какое обратное направление?

Обратное «прямому».

Кто-то не умеет в логику.

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

Кто сказал что unordered_map - это последовательность? «Последовательность» не может быть неупорядоченной (если я правильно угадал, что ты под ним подразумеваешь)

Еще раз. В Qt QHash все это было из коробки через QHashIterator.

«Unordered» и «Hash»: найди хоть одно различие.

а, не. удалили https://doc.qt.io/qt-5/qhashiterator-obsolete.html во благо «выравнивания» функциональности std::unordered_set

Кто сказал что unordered_map - это последовательность?

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

Последовательность» не может быть неупорядоченной

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

если я правильно угадал, что ты под ним подразумеваешь

Видимо, нет.

Unordered_map - это Container. Container требует только наличия типа ForwardIterator.

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

поСЛЕДОВАТельность - это упорядоченный набор. Если менее строго, набор, где определено отношение «следующий».

А вот набор порядка не имеет, он неупорядоченный.

поСЛЕДОВАТельность - это упорядоченный набор. Если менее строго, набор, где определено отношение «следующий».
А вот набор порядка не имеет, он неупорядоченный.

Пчёл, давай ты со своими фантазиями проследуешь обратно в 3-ый «Б», и спокойно там дождёшься перехода в 4-ый, где училка объяснит тебе разницу между последовательностью и порядком в ней?

последовательностью -> https://ru.wikipedia.org/wiki/Множество

Вместо ru.wikipedia.org/wiki/Последовательность

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

Пчёл, давай ты со своими фантазиями проследуешь обратно в 3-ый «Б»…

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

Кто сказал что unordered_map - это последовательность? «Последовательность» не может быть неупорядоченной

Давай ЭШО …

В математике последовательность

И какое отношение эта последовательность имеет к контейнерам stl? М-м-м, школтрон?

Как только объяснишь это отношение

последовательностью -> https://ru.wikipedia.org/wiki/Множество

Потом поговорим про какое отношение имеют последовательности (твои и мои) к stl.

М-м-м, школтрон?

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

Советую сменить круг общения на более компетентный.

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

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

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

и не должен быть привязан к контексту экзекутора