C++ *

Сейчас ведётся много споров и дискуссий о будущем C++.

Не только на Reddit и одном оранжевом веб-сайте, но и совершенно точно на официальных заседаниях комитета по стандарту C++.

Абсолютное состояние (языка C++)

Похоже, мы находимся в следующей ситуации:

Evolution Working Group (EWG) языка C++ как раз достигла консенсуса по внедрению P3466 R0 - (Re)affirm design principles for future C++ evolution:

Это означает отсутствие поломок ABI, сохранение совместимости компоновки с кодом на C и предыдущими версиями C++.

Также это означает отсутствие «виральных аннотаций» (например, аннотаций времени жизни).

Удвоение усилий по множеству несовместимых задач, например, отсутствия поломок ABI и принципа zero overhead.

Плохо это или хорошо, но это (в буквальном смысле) удвоение усилий по развитию текущей траектории языка C++.

Все знают что std::shared_ptr/weak_ptr тормозят, но это не повод от них отказываться и писать свой велосипед или небезопасный код на сырых указателях, ведь ситуацию можно исправить выключив синхронизацию потоков. Код который я вам покажу, работает в GCC и позволяет сконструировать новый shared_ptr без атомарных синхронизаций. Если у вас однопоточное приложение, вы можете подставить этот новый шаред поинтер за место старого для ускорения программы.

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

Есть в C++ такие штуки, которые вроде как существуют в стандарте, но некоторые о них даже не задумываются, пока не наткнутся на что‑то совсем странное. Вот, например,std::launder. Что это вообще? Стирка чего‑то грязного в коде (launder)? Или std::as_const — зачем делать объект «немного более константным»?

На днях решил покопаться в этих функциях, потому что они звучат интересно. Так что сегодня расскажу, что я выяснил, зачем это всё нужно, и главное — как использовать эти штуки правильно.

Всем доброго времени суток. Хотел бы немного поднять и обсудить тему российского IT рынка трудоустройства, а конкретно положение С++ Junior разработчиков на нём.

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

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

Большинству игр «хватает» одного потока, это обычно подразумевает наличие главного треда, где выполняются все игровые задачи (обработка ввода, обновление мира, рендеринг и т. п.), для каждого кадра. И такая модель последовательных вычислений сохранялась очень долго, да и сейчас применяется в большом числе игр, особенно мобильных, задействую ресурсы одного ядра. Есть конечно хорошо выделяемые задачи, вроде загрузки текстур, звуков, но это скорее исключение, в силу обособленности данных для таких задач. Чтобы сделать исключение правилом разработчики игровых движков приучают пользователей этих самых движков разделять игровые «циклы» на независимые «задачи», которые могут выполняться отдельно в «менеджере задач», который уже в свою очередь может запускать их на разных ядрах. Профит тут конечно очевидный — параллельное выполнение — это основной фактор повышения производительности игр.

Что еще можно вынести в другой поток без особого ущерба для игры?

Понадобилось мне создать панель категорий размещаемых предметов в UI. Как в градостроительных симуляторах. В наследие мне достался уже готовый UENUM, который в будущем будет изменен.

Естественно, очень не хотелось вручную перемещать и настраивать каждый отдельный виджет. Так еще и заниматься этим в будущем с изменениями категорий. Хотелось чего-то простого и универсального. Чтобы вот вызвал условный For Each Loop и сгенерировал все как надо, еще и не обязательно только для этого енама.

Выход был найден! Если мы создаем UENUM, то unreal сам генерирует всю нужную информацию и создает для нас UEnum класс, который является UObject. Нужно лишь правильно использовать эту информацию.

Приветствую, уважаемый читатель!

В первой части мы реализовали простейший аллокатор с минимальным оверхедом. Конечно же на самом деле все сложнее. Так реализация дефрагментации была наивной и не могла сливать блоки даже когда не было распределенных блоков после нескольких вызовов mem_free. Для того, что бы получить исходную картинку где будет только 2 служебных блока и один свободный нужно было бы вызвать mem_alloc с размером большим чем доступно памяти что бы искусственно запустить дефрагментацию. В этой части мы это исправим и напишем юнит тест для нашего аллокатора что бы убедится что он работает правильно.

• Рефлексия времени компиляции и оператор «монобровь»
• Constexpr, много constexpr
• SIMD
• Structured bindings as a pack
• Безопасность, контракты, libc++ hardening, профили, UB и std::launder
• Сколько бит в байте?

Забудьте о призраках, настоящая угроза кроется в повседневных вещах, таких как static_cast, который может неожиданно лишить вас безопасности, и assert, стремительно исчезающий в релизной сборке. Добро пожаловать в мир ловушек, созданных собственными руками!

Доброго времени суток.

При разработке ОС на с++ мы сталкиваемся с рядом трудностей, таких как отсутствие стандартной библиотеки и ABI с++ и прочее в этом духе. При чем перед реализацией PageAllocator и прочих аппаратных механизмов хотелось бы иметь какую то стандартную библиотеку позволяющую делать хоть что то. Об этом и пойдет речь.

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

Речь пойдет о немного переделанном алгоритме Кнута "неявный список блоков с граничными тегами" который описан в конце третьего тома в разделе "Распределение памяти". Его идея предельно проста:

Мы берем некоторый отрезок памяти, назовем его кучей и разбиваем его на блоки такого вида:

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

В какой-то момент я подумал: если компилятор сможет сам посчитать все за тебя, то зачем тогда тебе вообще рантайм? Что ты там будешь делать — ответ выводить что ли? Глупости какие-то. Это неспортивно.

На этом моменте и зародился мой челлендж:

"Без рук" или "даже не думай запускать exe-файл"

C и C++ — культовые языки, на которых написано огромное количество кода. Но какой путь они прошли, чтобы стать таковыми? В этой статье расскажем о появлении C, начале его официальной стандартизации, а также о C with Classes и его окончательном превращении в C++.

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

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

Статический анализатор PVS-Studio способен находить ошибки даже в таком качественном и протестированном проекте, как LLVM. Чтобы это не было пустыми словами, мы время от времени перепроверяем проект и публикуем такие заметки, как эта.

Я использую PostgreSQL 12-й версии! На остальных не проверял! Соответственно, он у вас должен быть скачан и настроен для использования.

Иногда все, что требуется — быстро вывести какой‑то текст в Renderpass. Традиционно отрисовка текста требует отрендерить все возможные символы шрифта в атлас, затем привязать полученный атлас как текстуру и затем отрендерить каждый глиф, рисуя треугольники, каждый из которых должен соотноситься с нужным глифом из текстуры атласа шрифта.

Так делает imgui, равно как и все, кто использует stb_truetype. Сам процесс приятно напоминает процесс наборного производства на физических станках.

Причудливо, правильно, но в то же время напряжно.

Если нам нужно просто вывести какое‑то сообщение для дебага? Нет ли какого‑либо более простого метода?

В данной статье я опишу метод бестекстурной отрисовки дебаг‑текста. Вдобавок, отрисовка будет производиться в один вызов draw.