Работа в комитете по стандартизации языка C++ активно кипит. Недавно состоялось очередное заседание. Как один из участников, поделюсь сегодня с Хабром свежими новостями и описанием изменений, которые планируются в С++26.

До нового стандарта C++ остаётся чуть больше года, и вот некоторые новинки, которые попали в черновик стандарта за последние две встречи:

• запрет возврата из функции ссылок на временное значение,
• [[indeterminate]] и уменьшение количества Undefined Behavior,
• диагностика при =delete;,
• арифметика насыщения,
• линейная алгебра (да-да! BLAS и немного LAPACK),
• индексирование variadic-параметров и шаблонов ...[42],
• вменяемый assert(...),
• и другие приятные мелочи.

Помимо этого, вас ждут планы и прогресс комитета по большим фичам и многое другое.

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



Поэтому мы вышли из беты и сделали релиз!

Что нового в релизе? Зачем вообще нужен userver и какие существуют технологии для обеспечения надёжной работы серверных приложений? Можно ли воспользоваться крутыми C++ классами из userver, не используя при этом корутины? Какие дальнейшие планы? Ответы на все эти вопросы ждут вас под катом.

На недавней встрече комитет C++ активно взялся за C++26. Уже есть первые новинки, которые нас будут ждать в готовящемся стандарте C++:

• улучшенный static_assert,
• переменная _,
• оптимизация и улучшение для std::to_string,
• Hazard Pointer,
• Read-Copy-Update (так же известное как RCU),
• native_handle(),
• целая вереница классов *function*,
• множество доработок по constexpr,
• std::submdspan,
• и прочие приятные мелочи.

Прошло больше полугода с момента выхода фреймворка для C++ 🐙 userver в open-source. За это время мы многое узнали, на многом настрадались, а главное — получили много приятных сюрпризов.

И мы решили об этом написать. Рассказ будет полезен тем, кто ведёт или планирует вести свой open-source проект или занимается контрибьютами. Остальным будет интересно почитать про чужое набивание шишек и что вообще open-source даёт проекту.

С момента моей прошлой публикации состоялось уже две встречи международного комитета по стандартизации C++.

Комитет занимался полировкой C++23:

• static operator[];
• static constexpr в constexpr-функциях;
• безопасный range-based for;
• взаимодействие std::print с другими консольными выводами;
• монадический интерфейс для std::expected;
• static_assert(false) и прочее.

И прорабатывал новые фичи C++26:

• std::get и std::tuple_size для агрегатов;
• #embed;
• получение std::stacktrace из исключений;
• stackful-корутины.

Сегодня мы анонсируем выход в опенсорс фреймворка userver для создания высоконагруженных приложений. Для нас это важный способ поделиться опытом в разработке микросервисов, который мы накопили. Вот ссылка на Гитхаб-репозиторий c исходным кодом, документацией, примерами, шаблоном для создания своих сервисов (с настроенным CI, сборкой и тестовым окружением) и сервисом динамических конфигов. Всё это опубликовано под лицензией Apache 2.0.



🐙userver позволяет быстро создавать эффективные микросервисы на языке C++ и уже много лет активно используется в Яндекс Go, Еде, Лавке, Доставке, Маркете, финтехе и других проектах. Вот из каких требований мы исходили в процессе разработки:

• Простота. Стажёр или студент, приходя к нам, может уже через неделю написать и отправить в продакшен новый микросервис.
• Надёжность. Многие ошибки, в том числе и связанные с многопоточностью, можно поймать на этапе компиляции. Кроме того, фреймворк даёт подсказки по исправлению проблем.
• Полнота. В userver есть всё необходимое для тестирования, работы с разными базами данных, кеширования, логирования, трейсинга, распределённых блокировок, работы с JSON, BSON, YAML, изменения параметров сервиса на лету и так далее.

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

На недавней встрече комитет C++ «прорвало», и в черновую версию C++23 добавили:

• std::mdspan
• std::flat_map
• std::flat_set
• freestanding
• std::print("Hello {}", "world")
• форматированный вывод ranges
• constexpr для bitset, to_chars/from_chars
• std::string::substr() &&
• import std;
• std::start_lifetime_as
• static operator()
• [[assume(x > 0)]];
• 16- и 128-битные float
• std::generator
• и очень много другого

Без лишних слов, прямо к делу — вот какие новые вкусности будут нас ждать в C++23:

• std::expected — новый механизм сообщения об ошибках без использования исключений и без недостатков кодов возврата.
• constexpr-математика — теперь на этапе компиляции можно доставать разные части чисел с плавающей запятой, копировать знаки и округлять числа.
• std::ranges::to — результаты работы алгоритмов можно легко превратить в контейнер.
• std::views::join_with — добавление разделителя между элементами.

Что мы не увидим в C++23, на что ещё можно надеяться и что ещё приняли в текущий черновик стандарта? Всё это ждёт вас под катом.

Привет! В этой статье я расскажу об устройстве асинхронных движков с корутинами и без них. Для начала сосредоточимся не на конкретном движке, а на том, почему во всех популярных языках программирования появились корутины и чем они так хороши. Это может быть интересно не только C++-разработчикам, но и всем, кто занимается разработкой сетевых приложений или интересуется архитектурой современных фреймворков.

Пройдёмся по разным архитектурам построения серверов — от самой простой синхронной к более интересным, посмотрим на типичную архитектуру корутинового движка, а после окунёмся в дебри C++ и взглянем на самое страшное на примере нашего фреймворка userver.

Пишем синхронный сервер

Представьте, что у вашего сервиса очень маленькая нагрузка — 100 rps, и вам дали задачу написать простой сервер, понятный каждому второму школьнику. У вас получится что-то наподобие следующего:

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}

Прошло четыре месяца с прошлой онлайн-встречи ISO-комитета, а значит, настало время собраться опять.



В этот раз в черновик нового стандарта C++23 добавили весьма полезные и вкусные новинки:

• operator[](int, int, int)
• монадические интерфейсы для std::optional
• std::move_only_function
• std::basic_string::resize_and_overwrite
• больше гетерогенных перегрузок для ассоциативных контейнеров
• std::views::zip и zip_transform, adjacent, adjacent_transform

Подробности об этих и других (даже более интересных!) вещах, а также о том, что за диаграмма стоит в шапке, ждут вас под катом.

Вчера прошла встреча рабочей группы ISO C++, добавляли фичи в C++23, исправляли C++20. Мы участвуем в работе комитета, поэтому сегодня поделюсь с вами свежими новостями о развитии стандарта.



Должен заметить, что международный комитет в онлайне работает совсем уж неторопливо… Настолько неторопливо, что на февральской встрече из полезного приняли только std::to_underlying() — функцию, преобразовывающую значение enum к нижележащему целочисленному типу:

enum class ABCD : std::uint64_t { A = 0x1012, B = 0x405324, };

constexpr std::uint64_t value = std::to_underlying(ABCD::A); 

На современных 64-битных PC-архитектурах использование C++-исключений означает всего лишь добавление к функциям недостижимого кода с вызовами деструктора и ухудшение производительность менее чем на 1%. Такие небольшие ухудшения производительности сложно даже измерить. Обработка редких ошибок с использованием возвращаемых значений требует дополнительных операций ветвления, которые, в реалистичных сценариях, замедляют программы примерно на 5%. Такой подход, кроме того, менее удобен, чем использование исключений. Если выбрасывается исключение, то на «раскрутку» каждого кадра стека тратится примерно 2 мкс.



C считается самым быстрым языком программирования. В C++ есть возможности, которые лишь повышают удобство работы, не влияя на производительность, в сравнении с C, и возможности, которые на производительность влияют. Эти возможности очень помогают в деле улучшения качества кода. В результате ими, несмотря ни на что, достаточно часто пользуются. Полиморфизм времени выполнения — это буквально вездесущая возможность, а вот исключения распространены меньше.

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

Я расскажу о подходах, которые мы используем в Яндекс.Такси для написания читаемого кода на C++, Python, JavaScript и других языках.

Немного прошерстив Habr удивился тому, что очень мало опубликовано статей на тему (beta-)фичи GitHub'а — Actions.

Казалось бы, можно объяснить такую недосказанность тем, что функционал еще в тестировании, пусть и "beta". Но именно полезная особенность беты позволяет использовать этот инструмент в приватных репозиториях. Именно про работу с данной технологией я расскажу в этой статье.

Сегодня речь пойдет про одну интересную идиому, которую ввел Шон Парент (Adobe) — известный деятель в C++-сообществе. Он часто выступает с докладами и публикует цикл статей Better Code. Одна из его идей, которую используют в Photoshop — это Concept-Based Polymorphism. Это когда мы реализуем полиморфизм не через явное наследование, а с помощью техники, включающей обобщенное программирование, и по итогам получаем некоторые дополнительные преимущества.

Статья устроена следующим образом:

1. Что вообще такое Concept-Based Polymorphism и зачем он нужен
   
2. Немного про LLVM и ее устройство
   
3. Пример Concept-Based Polymorphism в LLVM PassManager
   
4. Преимущества подхода
   

Картинка, иллюстрирующая тезис «Наследование — это зло». Источник

Деление — одна из самых дорогих операций в современных процессорах. За доказательством далеко ходить не нужно: Agner Fog[1] вещает, что на процессорах Intel / AMD мы легко можем получить Latency в 25-119 clock cycles, а reciprocal throughput — 25-120. В переводе на Русский — МЕДЛЕННО! Тем не менее, возможность избежать инструкции деления в вашем коде — есть. И в этой статье, я расскажу как это работает, в частности в современных компиляторах(они то, умеют так уже лет 20 как), а также, расскажу как полученное знание можно использовать для того чтобы сделать код лучше, быстрее, мощнее.

На днях прошла встреча международного комитета по стандартизации C++ в Кёльне. В прошлый раз был принят feature freeze на C++20, так что комитет должен был обсуждать только исправления уже принятых вещей, а добавлять новинки уже в C++23…

… но всё было не так!



Что сделали с std::flat_map; останутся ли страшные ключевые слова co_return, co_await и co_yield; успели ли доделать std::format; в каком виде будут контракты в C++20? Всё это вас ждёт под катом.

В С++20 появилось контрактное программирование. На текущий момент ни один компилятор ещё не реализовал поддержку этой возможности.

Но есть способ уже сейчас попробовать использовать контракты из C++20, так как это описано в стандарте.

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

Подобных проектов в интернете уже море, но практически все они показывают законченные программы, в которых разобраться крайне непросто. Вот, например, очень известная программа рендеринга, влезающая на визитку. Очень впечатляющий результат, однако разобраться в этом коде очень непросто. Моей целью является не показать как я могу, а детально рассказать, как подобное воспроизвести. Более того, мне кажется, что конкретно эта лекция полезна даже не столь как учебный материал по комьпютерной графике, но скорее как пособие по программированию. Я последовательно покажу, как прийти к конечному результату, начиная с самого нуля: как разложить сложную задачу на элементарно решаемые этапы.

Внимание: просто рассматривать мой код, равно как и просто читать эту статью с чашкой чая в руке, смысла не имеет. Эта статья рассчитана на то, что вы возьмётесь за клавиатуру и напишете ваш собственный движок. Он наверняка будет лучше моего. Ну или просто смените язык программирования!

Итак, сегодня я покажу, как отрисовывать подобные картинки:

Классы, которые люди самостоятельно пишут, а потом копируют из одного проекта в другой, хотя они уже есть в стандартных библиотеках, в простонародье называются велосипедами. Первый вопрос, который возникает при встрече с таким «велосипедом» — зачем люди переписывают что-то заново? Вариантов может быть несколько.

• Некоторые делают это для самообучения: берут класс стандартной библиотеки, пишут его сами с нуля, сравнивают то, что получилось, с тем, что есть в стандартной библиотеке — в процессе узнают для себя что-то новое.
  
• Некоторые проекты имеют особое требования к коду. В embedded-разработке принято работать без RTTI и без exception, поэтому части стандартной библиотеки, которые используют RTTI и exception, необходимо переписать без них.
  
• Редко, но бывает, когда велосипед пишут, потому что могут написать лучше, чем в стандартной библиотеке. Как правило, такие нововведения рано или поздно попадают в стандартную библиотеку.
  
• Другим только кажется, что они могут написать лучше, и таких людей больше. Но в процессе они обучаются, выясняют для себя что-то новое и что-то интересное открывают.
  
• Могут быть другие причины.
  

Сегодня мы не будем говорить о том, что велосипеды — это плохо, это не обязательно так. Мы поговорим о том, что действительно плохо:

• бездумно переносить устаревшие технологии 20-30-летней давности в современные проекты;
  
• пользоваться «вредными» бенчмарками и оптимизациями.
  

А также затронем «вредные» советы, обсудим новейшие практики программирования (C++ 11 и позднее), подумаем, что делать с «идеальным» велосипедом.