Зависит от бизнес-логики. Если нужны эксперименты - проще, т.к. есть динамические конфиги. Если нужно чтобы бизнес-логика укладывалась в таймауты - проще, есть готовые кеши, метрики и возможность на лету менять таймауты.
Может, быстрее таймтумаркет? Или стала проще поддержка кода?
В гите лежат шаблоны сервисов, они ускоряют первые шаги в разработке и улучшают таймтумаркет. Готовая инфраструктура для тестирования микросервиса, поднятия базы и мока сервисов - тоже положительно влияет. Отлаженность инструмента на масштабах большой компании - тоже плюс, поддержка кода сильно проще. Статсистика, опентрейсинг и изкоробочное логирование помогают диагностике и тоже положительно влияют на таймтумаркет и поддержку.
Вы не спросили про другие важные пункты:
Эффективность по CPU - да, есть. Железо нынче дорогое, это важно.
Эффективность по времени ответа - да, есть. Времена ответа бека влияют на удобство пользоватлей, влияют на частоту использования сервиса.
Простота написания кода - да, есть. Вся асинхронность и коллбеки спрятаны, при разработке не надо страдать с ними.
Ну и от себя могу сказать следующее: лично я всегда рад когда какой-то проект выходит в опенсорс. Я не знаю, какая технология мне понадобится завтра, возможно что та, которую открыли вчера. А ещё в опенсорс проектах всегда можно найти интересные решения, научиться чему-то новому и в дальнейшем использовать в своей разработке.
Нам важна проработанность различных компонентов и плотная их интеграция друг другом. Например в каких-то фреймворках есть драйвер для некоторых баз данных, в каких-то есть библиотека для изменения конфигурации сервиса без рестарта, где-то есть библиотеки для записи метрик. Фреймворков на C++, где есть все эти компоненты и они состыкованы друг с другом - до сегодняшнего момента не было.
Вот пример, для чего нам нужна состыкованность: Мы пишем статистики по неудачным запросам. На их основе можно делать алерты - всякие рассылки разработчикам "Внимание! Происходит что-то странное, ваш запрос стал в 10 раз чаще завершаться с ошибкой". Получив такой алерт разработчик пойдёт диагностировать проблему. И например поймёт, что внезапно количество пользователtй стало в 10 раз больше. После чего разработчик с помощью динамической конфигурации, увеличит количество соединений с базой данных. Проблема уйдёт, при этом рестарт сервиса или его перевыкатка не потребовались.
Название появилось благодаря следующим трансформациям: берём слово 'microserver', сокращаем его согласно международной системе единиц СИ, получаем 'µserver', превращаем букву 'µ' в 'u' (чтобы проще было в коде использовать).
В C++23 было много багфиксов в C++20. Сейчас вроде пыль улеглась, так что стандартные библиотеки начнут активнее новый функционал реализоввывать. Ядерная же часть языка C++20 подтормаживает, и не понятно сколько будет тормозить: корутины и модули оказались крайне сложными для реализации.
Стандартные модули в собранном виде должны поставляться из коробки. Если модуль находится по нестандартному пути, то путь до директории с модулями можно указать флагом компилятору. В обоих случаях, никаких проблем с cmake быть не должно.
Если планируете собирать собственный модуль, то придется написать немного cmake текста для создания таргета и его установки. Со временем писать придётся меньше, так как добавят нужный функционал https://gitlab.kitware.com/cmake/cmake/-/issues/18355
В std::format уже есть предопределённые форматтеры на ширину выведения числа, на точность, на предстваление, на заполненители и т.д.
Если нужно что-то большее, то можно для своих типов можно добавлять любые форматтеры через специализацию std::formatter для своего типа.
Можно ли переопределить стандартную реализацию?
Да, например можно сделать
```
template <typename Range> struct MyPrinter{ Range r; };
```
И специализировать std::formatter<MyPrinter<T>>. Тогда, если надо как-то по особомо отформатировать свой диапазон, то надо будет написать std::print("{:ваши-флаги-форматирования}", MyPrinter{range});
не могу пользовать стандартную реализацию из-за кастом вьюс
Есть способы писать свои вьюихи, но если это делать по всем правилам, получается нетривиально. Со статическим operator() это становится попроще
они конфликтуют с перегрузкой оператора (,)
Использование этого оператора в operator[] было задепрекейчено в C++20, а оператор для многомерных массивов был добавлен в C++23. Так что если есть подобные использования, то предлагается сначала мигрировать на C++20, поправить все использования, после чего уже переезжать на C++23. Решение не самое изящноеб но рабочее.
какова судьба библиотек типа boost::phoenix, boost::karma, boost::spirit
Там вроде не используется оператор запятая в квадратных скобках
В комитете есть несколько людей, которые активно следят за простотой использования языка. Например Nicolai Josuttis преподаёт C++ студентам, и часто приходит в комитет со словами "Вот этот момент студенты не понимают, и я кажется тоже! Давайте вот так переделаем" или "Тут приходится слишком много и долго объяснять, смотрите как можно упростить"
В C++23 просто не успели принять, сконцентрировались на других вещах :(
Но то что приняли в C23 - очень позитивная новость. Значит скоро примут и в C++, ведь комитет старается сохранять совместимость. Ну и когда реализуют в C компиляторах, фича сама "просочится" в C++
Если он подходит под ваши нужды - то почему бы не использовать. Нам не подошёл по ряду причин :(
Зависит от бизнес-логики. Если нужны эксперименты - проще, т.к. есть динамические конфиги. Если нужно чтобы бизнес-логика укладывалась в таймауты - проще, есть готовые кеши, метрики и возможность на лету менять таймауты.
В гите лежат шаблоны сервисов, они ускоряют первые шаги в разработке и улучшают таймтумаркет. Готовая инфраструктура для тестирования микросервиса, поднятия базы и мока сервисов - тоже положительно влияет. Отлаженность инструмента на масштабах большой компании - тоже плюс, поддержка кода сильно проще. Статсистика, опентрейсинг и изкоробочное логирование помогают диагностике и тоже положительно влияют на таймтумаркет и поддержку.
Вы не спросили про другие важные пункты:
Эффективность по CPU - да, есть. Железо нынче дорогое, это важно.
Эффективность по времени ответа - да, есть. Времена ответа бека влияют на удобство пользоватлей, влияют на частоту использования сервиса.
Простота написания кода - да, есть. Вся асинхронность и коллбеки спрятаны, при разработке не надо страдать с ними.
Ну и от себя могу сказать следующее: лично я всегда рад когда какой-то проект выходит в опенсорс. Я не знаю, какая технология мне понадобится завтра, возможно что та, которую открыли вчера. А ещё в опенсорс проектах всегда можно найти интересные решения, научиться чему-то новому и в дальнейшем использовать в своей разработке.
Стриминг уже есть, все gRPC стримы поддержаны и асинхронно работают.
Или вас другой стриминг интересует?
Цитируя правила сайта:
Нам важна проработанность различных компонентов и плотная их интеграция друг другом. Например в каких-то фреймворках есть драйвер для некоторых баз данных, в каких-то есть библиотека для изменения конфигурации сервиса без рестарта, где-то есть библиотеки для записи метрик. Фреймворков на C++, где есть все эти компоненты и они состыкованы друг с другом - до сегодняшнего момента не было.
Вот пример, для чего нам нужна состыкованность:
Мы пишем статистики по неудачным запросам. На их основе можно делать алерты - всякие рассылки разработчикам "Внимание! Происходит что-то странное, ваш запрос стал в 10 раз чаще завершаться с ошибкой". Получив такой алерт разработчик пойдёт диагностировать проблему. И например поймёт, что внезапно количество пользователtй стало в 10 раз больше. После чего разработчик с помощью динамической конфигурации, увеличит количество соединений с базой данных. Проблема уйдёт, при этом рестарт сервиса или его перевыкатка не потребовались.
У нас сейчас этим как раз занимается один доброволец, но задача не самая приоритетная
u-server, по русски читается как "у-сервер"
Название появилось благодаря следующим трансформациям: берём слово 'microserver', сокращаем его согласно международной системе единиц СИ, получаем 'µserver', превращаем букву 'µ' в 'u' (чтобы проще было в коде использовать).
Готово! Мы выложили userver в опенсорс: https://habr.com/ru/company/yandex/blog/674902/
Работа не идёт, последнее предложение было в 2013 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3744.pdf
Ханна работала над продвижением CTRE в стандарт, сейчас кажется отвлеклась на статическую рефлексию.
Расширения в стандарт уже есть, они называются TS. Например из недавнего - Transactional Memory TS
В C++23 было много багфиксов в C++20. Сейчас вроде пыль улеглась, так что стандартные библиотеки начнут активнее новый функционал реализоввывать. Ядерная же часть языка C++20 подтормаживает, и не понятно сколько будет тормозить: корутины и модули оказались крайне сложными для реализации.
А как же std::stacktrace ? Классная ведь штука :)
Стандартные модули в собранном виде должны поставляться из коробки. Если модуль находится по нестандартному пути, то путь до директории с модулями можно указать флагом компилятору. В обоих случаях, никаких проблем с cmake быть не должно.
Если планируете собирать собственный модуль, то придется написать немного cmake текста для создания таргета и его установки. Со временем писать придётся меньше, так как добавят нужный функционал https://gitlab.kitware.com/cmake/cmake/-/issues/18355
Да, это оно https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2141r0.html
Над этим идёт активная работа, будет выглядеть вот так https://en.cppreference.com/w/cpp/experimental/simd/simd
В GCC уже добавили реализацию, можно пользоваться :)
std::expected добавили в C++23 в феврале. Вот тут мы делились подробностями https://habr.com/ru/company/yandex/blog/649497/
В std::format уже есть предопределённые форматтеры на ширину выведения числа, на точность, на предстваление, на заполненители и т.д.
Если нужно что-то большее, то можно для своих типов можно добавлять любые форматтеры через специализацию std::formatter для своего типа.
Да, например можно сделать
```
template <typename Range>
struct MyPrinter{ Range r; };
```
И специализировать std::formatter<MyPrinter<T>>. Тогда, если надо как-то по особомо отформатировать свой диапазон, то надо будет написать std::print("{:ваши-флаги-форматирования}", MyPrinter{range});
Есть способы писать свои вьюихи, но если это делать по всем правилам, получается нетривиально. Со статическим operator() это становится попроще
Использование этого оператора в operator[] было задепрекейчено в C++20, а оператор для многомерных массивов был добавлен в C++23. Так что если есть подобные использования, то предлагается сначала мигрировать на C++20, поправить все использования, после чего уже переезжать на C++23. Решение не самое изящноеб но рабочее.
Там вроде не используется оператор запятая в квадратных скобках
А расскажите поподробнее, что именно вам пригодится?
В комитете есть несколько людей, которые активно следят за простотой использования языка. Например Nicolai Josuttis преподаёт C++ студентам, и часто приходит в комитет со словами "Вот этот момент студенты не понимают, и я кажется тоже! Давайте вот так переделаем" или "Тут приходится слишком много и долго объяснять, смотрите как можно упростить"
В C++23 просто не успели принять, сконцентрировались на других вещах :(
Но то что приняли в C23 - очень позитивная новость. Значит скоро примут и в C++, ведь комитет старается сохранять совместимость. Ну и когда реализуют в C компиляторах, фича сама "просочится" в C++