Понадобится только python и jinja. Они уже давно проставлены зависимостями в userver

От всей команды - спасибо!

В ближайшие месяцы появился автогенерация структур, парсеров и сериализаторов из JSON schema (и схем из Swagger / OpenAPI). Так что можно будет делать что-то на подобие:

std::string MyComponent::HandleRequestThrow(
    const server::http::HttpRequest& request,
    server::request::RequestContext&) const {
  MyStruct value = MyStruct::FromJsonString(request.RequestBody());
  value.foo += 100;
  return ToJsonString(value);
}

Синтаксис может немного измениться

Давайте поправлю документацию, на что-то на подобие "Готово к использованию, но слабо протестировано на огромных масштабах и нагрузках".

А ещё лучше введу обозначения на подобие:

* Platinum Tier - протестировано крупными игроками, работает отлично

* Golden Tier - нет больших известных проблем, но не тестировалось крупными игроками на больших нагрузках

И размечу ими все драйвера и части фреймворка

Подскажите, чего именно вам не хватает в текущей реализации RabbitMQ?

У меня дети назвали его Уся Пуся.

Имя "Уся" от "userver", фамилия "Пуся" от "octopus"

Но это пока не официальное название, в команде мы над именем ещё не думали

Пока что многие разработчики используют C++17, так что отказываться от его поддержки в ближайшее время не планируем (*).

При этом, мы поддерживаем сборку в C++20/C++23/... и используем фишки новых стандартов если они доступны.

(*) - драйвер YDB требует C++20 или выше. Понижать требования до C++17 в этом месте мы не планируем, если не будет ощутимого количества желающих.

Ещё и регрессию в компиляторе нашли https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114559 на этом коде

Есть целый чатик https://t.me/supapro где помогают и подсказывают по C++

Поправили https://github.com/userver-framework/userver/commit/354b36e0a1d48109505533787cc01acd58621309

Стандартную библиотеку C++ (и скорее всего C) разметят этими атрибутами и не erroneous поведение (как в случае с std::cin) не будет приводить к предупреждениям.

В остальных местах могут появиться предупреждения

Авторы предложения на линал хотели добавить операторы, но столкнулись с целой кучей проблем https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html#arithmetic-operators-and-associated-expression-templates

В чачтности некоторые операторы не однозначны (например умножение может значить разное); некоторые операторы предполагают аллоцирование, что не ложится на парадигму невладения и убирает возможность указать другой результирующий тип и т.п.

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

Она там тоже не бесплатная, просто накладные расходы в отдельном потоке (*есть нюансы). К тому же, практически во всех языках с GC тоже есть способ получить память быстрее, без зануления. Просто эти техники бадьше спрятаны, чтобы ими не воспользовались случайно

В хорошем примере этот код был бы обложен ограничениями на типы аргументов функций foo и bar.

Всё верно. В стандарте такого кода не будет, а в статье он без концептов для упрощения примера

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

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

Увы, это наносит удар по производительности. Например убирание такой инициализации нулями позволяет раза в 3 ускорить некоторые горячие пути в коде (https://github.com/userver-framework/userver/commit/a24d86474cb850510484c0d78fa4924bea16505c)

О, и правда! Спасибо, сейчас поправим

Все операции работают над std::mdspan. В примере std::vector для того, чтобы показать как std::mdspan создать над массивом данных.

Да, std::mdspan не владеющий класс. Посмотрите примеры в proposal, часто нужны операции над частью матрицы и соответственно на практике нужен именно не владеющий класс

Точно так же - значение 65535 в такой интерпретации не является валидным для ushort_16.

В случае арифметики насыщения, краевые значения (0 и 65535) не надо воспринимать как не валидные. Это просто значения

Пример задачи где такая арифметика хорошо подходит: наполнение резервуара. Есть резервуар на 65535 единиц. Чтобы вылить из него `x`, надо позвать res = std::sub_sat<unsigned short>(res, x), чтобы долить `y` надо позвать res= std::add_sat<unsigned short>(res, y)

С такими операциями насыщения у вас резервуар не будет содержать больше чем он вмещает, а при заполнении нет риска что резервуар случайно "опустеет" из-за переполнения.

На всякий случай подсвечу, что "ошибочное поведение != ошибка компиляции". На ошибочное поведение компилятор выдаст предупреждение.

Подсвечу это в статье поярче