C++ *

В C++ инкапсуляция — один из ключевых принципов ООП, и приватные (private) члены класса защищены от прямого доступа извне. Однако иногда возникают ситуации, когда такой доступ необходим (например, при тестировании, сериализации или отладке). Обычно для этого используют friend-функции или геттеры/сеттеры, но есть и более экзотический способ — использование шаблонов и указателей на члены класса.

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

Расскажу, как устроена архитектура консоли Nintendo Gameboy, как можно эмулировать её основные компоненты, какие решения я принимал в процессе разработки и какие инструменты использовал.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

Корутины в C++20 открывают новые возможности для асинхронного программирования, но они также могут привести к ошибкам, связанным с управлением памятью и синхронизацией. Здесь о том, какие проблемы могут возникнуть и чего ожидать от будущих обновлений корутин в C++.

Мэтт Годболт, знаменитый разработчик Compiler Explorer — потрясающий человек, вам стоит найти в вебе и изучить весь созданный им контент. Именно этим и занимался, просматривая Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Я уже больше двадцати лет работаю с C/C++, поэтому эта тема была мне близка.

Когда я смотрел его доклад, ко мне постоянно приходила мысль: «Да! И именно поэтому в Rust это делается так». После просмотра видео я подумал, что этот доклад — отличный способ понять, как Rust помогает разработчикам не только в безопасности по памяти, и в своей статье я расскажу об этом.

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

Началось все с того, что при проектировании своего устройства на микроконтроллере ATtiny 85, которое должно было работать от встроенного li‑ion аккумулятора, я изначально не задавался целью измерения заряда АКБ, поскольку в этом не было необходимости. Однако, собрав все устройство на печатной плате, я подумал над тем, почему бы не добавить такую возможность.

Прочитав в Интернете, как это можно было реализовать, стало ясно, что сделать это вряд ли удастся, поскольку все порты PB[0:5] уже были заняты и, следовательно, не было возможности применения АЦП с аналогового пина (при чем порт PB0 я не мог настроить на вход опорного напряжения AREF - он должен был использоваться как управляющий выход).

Долгое изучение состояния регистров АЦП в datasheet на ATTiny 85 привело меня к следующей идее: в качестве опорного напряжения может быть выбрано само напряжение питания VCC (биты REFS [0:2] регистра ADMUX установлены в 0), а в качестве измеряемого ‑ напряжение VBG с внутреннего стабилизатора в 1.1В (биты MUX [3:0] регистра ADMUX установлены соответственно в 1100). То есть, для измерения напряжения питания не нужно ничего, кроме, собственно, самого питания VCC!

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

После прочтения большинства этих статей и нескольких лет кодинга на C# я заявляю: «ООП - это один большой обман. Никто не понимает, что это такое. Люди просто говорят какие-то умные термины, их собеседники с умным видом кивают, хотя на деле трактуют эти же термины совершенно по-разному».

И вот почему.

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

Во время разработки одного из своих проектов я обнаружил, что мне нужен контейнер, способный менять свой размер по мере необходимости. Так как я большую часть времени разрабатываю на С++, а не на С, я очень хотел получить что-то похожее на std::vector<T> из С++. Я начал искать в интернете реализации, но они мне не подходили по разным причинам. Тогда я решил разработать свой вариант.

В один прекрасный день мне написал рекрутер с крайне заманчивым предложением.

Я на тот момент как раз находился в поиске новой работы, поэтому предложение принял. Опустим стандартный звонок с этим рекрутером, с HR'ом компании и онлайн-тестовое и перейдём к более интересному - тестовому заданию. Сразу скажу, что тестовое не оплачивалось, и я взялся за него по нескольким причинам. Во-первых, оно мне и вправду понравилось, во-вторых, кодовую базу я планировал использовать в своём с корешами pet-проекте по финансам, в-третьих, не оставлял надежд пройти отбор до конца и получить желаемый offer. Спойлер - игра стоила свеч, поэтому прошу к прочтению.

В Steam завершился «Фестиваль передвижных ящиков», посвященный играм, где разными способами можно передвигать ящики. На английском фестиваль называется «Sokoban Fest» в честь первой игры, где появилась эта механика.

Игра-головоломка «Sokoban» (яп. 倉庫番, рус. кладовщик) вышла в Японии в 1982 году. А разработал ее годом ранее Хироюки Имабаяси. Она имела колоссальный успех. И механика привлекла тогда внимание многих геймдизайнеров, которые стали применять ее в новых играх и продолжают применять в современных играх разных жанров.

В своем проекте X-Drums 2.0 на Unreal Engine 5 мне захотелось добавить эту механику. И в этой статье я расскажу, что из этого получилось и какие еще игры повлияли на финальную реализацию.

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

Эта серия статей родилась как заметки на полях к замечательной книге Game Engine Architecture, книга большая, объемная и охватывает все аспекты создания движка. Но там нет нюансов практической разработки. А чтобы видеть нюансы надо понимать не только теорию, все же GAE больше теория, но знать как работает код игры изнутри. Чтобы понимать как, и главное почему, используются выбранные механизмы внутри игры, чтобы видеть проблемы с производительностью и архитектурой, как их искать и как чинить, для этого придется понять как работают и как создавались игровые движки.

Если мне не изменяет память - Кармак сказал, что лучший способ [создания игр] — написать собственный движок ( "The right move is to build your own engine" ), на что многие возразят: это вовсе не так просто. Но папа Doom'a известен не только своим вкладом в разработку игровых движков, но и довольно часто высказывался критически о развитии игровых движков в целом, и о преимуществах создания собственных технологических решений вместо использования готовых.

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

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

В этой статье рассмотрим возможно самый простой способ рисования всех емодзи из шрифта NotoColorEmoji.ttf.

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

На днях вышел GCC 15.1.0 с поддержкой некоторых фич C++26.

Однако нынешняя версия Ubuntu все еще использует старый GCC 13.

Здесь мы и рассмотрим, как вручную установить GCC 15.1 на Ubuntu и начать использовать новейшие элементы C++26 уже сегодня.

Книга Design Patterns: Elements of Reusable Object-Oriented Software («Приёмы объектно-ориентированного проектирования. Паттерны проектирования»), также известная под названием "синей книги", по цвету обложки первого издания, или книги "банды четырех/GoF" издана почти тридцать лет назад.

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

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

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

Заходите, великов и граблей хватит на всех.

Работа с API и создание динамических текстур в Unreal Engine может показаться сложной задачей, особенно для новичков. В этом материале на реальном примере мы разберем, как с помощью C++ получить изображение из публичной базы данных The Art Institute of Chicago, преобразовать его в текстуру, добавить её в материал и отобразить на 3D-объекте прямо в движке. Вместе мы шаг за шагом создадим интерактивную виртуальную галерею, познакомимся с основами работы с HTTP-запросами, JSON-данными, динамическими материалами и текстурами, а также научимся строить структуру собственного актора для подобных проектов.

Сборка проектов на CMake вызывает множество вопросов у новичка. Так как это ударило непосредственно по мне, я решил показать и рассказать о том, как быстро создать универсальные скрипты для сборки на CMake.

Привет, Хабр! Меня зовут Никита, мне 14 лет, и я владелец телеграмм канала NikitaTech Nexus. С детства мечтал создавать игры, но со временем мои амбиции выросли - теперь я планирую разрабатывать не только игры, но и серьезные десктопные приложения. В этой статье хочу поделиться своим прогрессом, текущими проектами и планами на будущее.