Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специфичных. Это девятая статья из серии, список предыдущих статей приведен в разделе 6. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена специальным функциям-членам.

В C++ жизненный цикл экземпляра класса/структуры/объединения (объект, представляемый в коде переменной) начинается с инициализации, то есть задания его начального состояния. Далее, почти всегда, объект копируется, выполняются присваивания или их перемещающие аналоги. Эти операции необходимы для работы функций, контейнеров, алгоритмов. Финальной точкой жизненного цикла объекта является его уничтожение. Именно для поддержки этих операций в C++ и предназначены специальные функции-члены.

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

Итак, попробуем рассказать о специальных функциях-членах максимально подробно.

Когда-то давным-давно (то есть до C++20) мы форматировали вывод либо по-старинке через printf, либо используя громоздкие стримы ввода-вывода из <iostream>. Оба подхода, мягко говоря, не очень. printf работал шустро и лаконично, но требовал строгого соответствия типов, забудешь правильный %d или %s в формате, и получишь неопределённое поведение вплоть до падения программы. Компиляторы иногда предупреждают о несоответствиях, но полностью проблему не решают (особенно если форматируемая строка не литерал). Кроме того, printf не умеет выводить пользовательские классы, только примитивы.

Сейчас ситуация изменилась. В C++20 завезли библиотеку <format>, современный подход к форматированию строк, сочетающий лаконичность printf с безопасностью iostream. Инструмент называется std::format и объявлен в заголовке <format>. По сути, это адаптация популярной библиотеки fmt.

Существует довольно много распространённых «мудростей» о разработке игр на C++, различных обрядах и видах магии. И как это часто бывает с подобными сакральными знаниями, при внимательном осмотре - у части действительно есть право на жизнь, часть можно отправить в Каирский музей отбирать славу у мумий, а часть вообще оказывается родом из чужой реальности, и работать как предполагалось отказывается. Но это не мешает некоторым компаниям относиться к таким советам как к скрижалям, бережно принесённым с великой горы совещаний. Новым сотрудникам их передают почти с торжественностью обряда посвящения: «Так делали наши предки, так делаем и мы».

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

CryEngine2 использовал класс собственный CString для реализации работы со строками и немного использовал строки из стандартной строковой библиотеки Windows. Насколько я помню, последняя версия CryEngine всё ещё использует те же самые CString, она кардинально поменялась внутри, но как дань истории название класса менять не стали, зато сильно расширили функционал. Я не на 100% уверен, применялся ли CString только в редакторе или в рантайме игры тоже, вы можете сами это посмотреть в исходниках, которые все еще доступны на гитхабе. Это один подход к работе со строками, довольно распространенный в мире игростроя - когда мы все нужное пишем сами, не оглядываясь... хотя, тут больше уместно слово поглядывая, на существующие реализации и утаскивая в проект все самое лучшее.

Есть и другой подход... Я работал в команде над некоторым проектом, который должен был выйти на консолях, и в какой‑то момент на проект пришел эффективный тимлид, который хорошо умел в красивые презентации, и продавил использование std::string из sdk. Все очень опытные программисты, синьоры и руководство важно кивали на совещании и согласились всё перевести на std::string… не такие уж они оказались опытные, как выяснилось. В итоге мы заменили большую часть CString на std::string. Не сказал бы, что это сильно повлияло на время компиляции — плюс‑минус минута к проекту, который собирается двадцать минут, особой погоды не делают, но это также превратило наш довольно понятный базовый код в запутанный кошмар. Возможно, для переносимости это было лучше, но ни наш проект, ни CryEngine2 Editor так и не были портированы ни на Linux, ни на какую‑либо другую платформу.

Прошло десять лет, я вижу ровно туже ситуацию на текущем проекте — новый тимлид решил перевести местный MySuperPupeString на std::string, уже предчувствуя «нижней чуйкой» последствия — запасаюсь попкорном и беру отпуск на следующий месяц после принятия решения. Но не это интересно, а то — какие вообще строки могут быть в вашем с++ коде.

Статей про Docker много не бывает.

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

Предположим, вы пишете многопоточное приложение для Linux, которое рассчитано на длительную работу. Может — это СУБД или какой-нибудь сервер. Представим ещё, что ваша программа не рассчитана на какую-нибудь среду выполнения кода (скажем — на JVM, Go или BEAM), которая берёт на себя управление низкоуровневыми вещами. Вы сами управляете порождением потоков (thread), прибегая к системному вызову clone. Когда пишут на C — потоки создают с помощью pthread_create, а в C++ применяется std::thread. (1)

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

Каждый, кто прошел через курс линейной алгебры или физики в универе, помнит этот странный дуализм. Нас учили, что у векторов есть целых ДВА вида произведения. Первое, скалярное, съедает два вектора и выдает число. Геометрически — это что-то про проекции и углы. Второе, векторное, тоже съедает два вектора и… внезапно выплевывает третий вектор, перпендикулярный первым двум. Причем работает этот фокус только в 3D и 7D.

Всегда казалось, что это какой-то математический «костыль».

Почему так сложно? Почему два разных продукта для разных задач? Почему один зависит от косинуса, а другой от синуса?

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

Эта статья — приглашение в мир Геометрической Алгебры. Мы собираемся переизобрести умножение.

В этой статье я расскажу, как можно улучшить читаемость асинхронного кода и сократить немалое, на мой взгляд, количество писанины. И это благодаря такой возможности стандарта уже минувшего года, как сопрограммы. На Хабре опубликовано некоторое количество статей об этой интересной языковой технологии, но я хочу показать практическое применение в проектах UnrealEngine, а так же приоткрыть завесу сопрограмм для тех, кто ещё не в курсе.

Во всех устройствах YADRO, будь то системы хранения данных, серверы или коммутаторы, есть система BMC, через которую администраторы гибко управляют серверами. 

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

Меня зовут Максим Гончаров, и я расскажу, как мы оптимизировали кодовую базу на C++ по размеру конечного образа, чтобы новые фичи были доступны на всех уже работающих у заказчиков серверах.

Данное руководство позволит читателю составить полную картину того, как организовать сборку C++ библиотек с использованием современных возможностей CMake. Предполагается, что читатель имеет представление о базовых понятиях из мира CMake и динамических/статических C++ библиотек, так как в руководстве они могут не объясняться.

^{Bernard de Go Mars}

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

Но, за пределами наблюдения остаётся весьма существенный объект - воздушный океан вокруг! 

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

И для этого, существует специальный метод фото/видео фиксации процессов прозрачных сред*, называемый "шлирен-методом" (от «schlieren» - «полосы» (нем.) – здесь под «полосами» подразумеваются неоднородности).

При работе с C или C++ необходимо в какой-то степени разбираться в неопределённом поведении (UB): что это такое, каковы его эффекты, и как о него не споткнуться. Для простоты картины я буду в этой статье рассказывать только о C, но всё изложенное здесь также применимо и к C++, если явно не указано иное.

Многим людям нравится научная фантастика, я тоже люблю иногда почитать "Автостопом по галактике" или посмотреть "Интерстеллар". Во время потребления подобного контента возникает один и тот же вопрос: как они путешествуют на такие далекие расстояния за такое короткое время? Я хочу попробовать ответить на этот вопрос с точки зрения релятивистской механики.

В данной статье мы рассмотрим полет ракеты с Земли до ближайшей к Солнцу звезде - Проксиме Центавра.

Привет, Хабр!

Векторизация в C++ давно живёт на двух этажах. Внизу автоворожбы компилятора: достаточно аккуратно написать цикл, и при нужных флагах он соберёт SIMD-инструкции сам. Наверху низкоуровневые intrinsics, где вы контролируете каждый shuffle и predication, но платите за это портируемостью и временем на поддержку. Между ними появился удобный этаж: std::simd. Он даёт вам явные векторные типы и операции без прыжков по AVX/NEON-интринсикам и при этом остаётся переносимым. В 2025 году картина такая: полноценный std::simd принят в стандарт C++26, а использовать в проде уже сейчас можно std::experimental::simd из Parallelism TS v2, которая есть в libstdc++ (GCC 11+) и постепенно доезжает до остальных реализаций. Для чтателя это означает простую вещь: сегодня пишем под <experimental/simd>, а миграция на <simd> будет механической.

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

В рамках микросервисной архитектуры достаточно легко делать «реактивные» сервисы: к вам приходит событие или вызов HTTP-метода, и в ответ на это происходит какое-то действие. Однако бывают более сложные сценарии, когда надо собрать некоторое количество информации или событий прежде, чем что-то делать. В таком случае нужен пайплайн — механизм организации сложных правил обработки событий. 

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

— Как хранить в одном контейнере разные типы и использовать тип в качестве ключа контейнера 

— Как средствами метапрограммирования удобно сериализовать и десериализовать разнотипные объекты 

— Как сделать универсальный запускатель функций, который будет запускать любую функцию и сам искать, откуда «добыть» эти аргументы 

— И главное, как сделать интерфейс для написания пайплайна обработки события — удобный и полностью изолированный от инфраструктуры

У меня есть забавный профессиональный рефлекс, который выработался у меня за годы работы. Я, как человек, находящийся сразу в обеих лагерях игровой индустрии и в окопах разработки, и в кресле дизайнера — на слово «память» реагирую уточняющим вопросом:

— «О какой именно памяти мы говорим?»

Зачастую, конечно, речь идет о ней родимой — об оперативной памяти компьютера. О RAM, гигабайтах, скорости загрузки, прогрузке полигонов и вот этом всем техническом великолепии, которое заставляет наши игры выглядеть и работать так, как они работают. Это понятный, измеримый, абсолютно конкретный ресурс, с которым мы, как разработчики, постоянно боремся, пытаясь впихнуть невпихуемое и оптимизировать неоптимизируемое.

Но есть и другая память. Та, что скрывается за сухой статистикой «количества одновременно играющих». За каждым мощным ПК, за каждым гигагерцем и терафлопсом сидит не просто железо. Там сидит человек. И эта статья — именно о нем. О человеке, чья память, в отличие от компьютерной, работает чуть менее предсказуемо. Она капризна, избирательна, подвержена эмоциям и легко может «зависнуть» от перегрузки. Но, не поверите... она все ещё достаточно предсказуема!