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

В этой статье разберём мутный, но крайне важный инструмент ‒ std::launder. Мы поглядим, зачем его протащили в C++17 и что компилятор делает, когда видит launder.

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

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

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

И вот почему.

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

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

Might and Magic – одна из самых дорогих моему сердцу игровых вселенных. Невозможно сосчитать, сколько тысяч часов я провёл в её мирах – будь то основная серия, «Герои» или «Крестоносцы». И даже спустя десятилетия что-то неизменно влечёт меня обратно. Причём дело не только в ностальгии – эти игры обладают особой атмосферой, дарящей чувство уюта, словно вернулся в родной с детства двор, в котором не был десятки лет, или очутился дома после длительной поездки.

Но, несмотря на столь теплые эмоции, сложно отрицать, что эта серия по-настоящему увлекательна и обладает душой, что делает возвращение в её миры всегда особенным событием. А в более поздних частях Might & Magic мы и вовсе можем от первого лица посетить знакомые места, пообщаться с персонажами, а также сразиться с существами, которых мы помним ещё по «Героям». Таким образом, становясь не сторонним наблюдателем, что лишь движет фигурки по карте, а полноценным участником событий!

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

В этой статье отвечу на три вопроса: какие существуют виды языков программирования; почему нужно сначала изучить SQL; как учить SQL бесплатно.

C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?

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

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

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

Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?

Привет, Хабр, меня зовут Александра, я программист в отделе разработки серверных решений ЮMoney. В этой статье описываю, как принципы объектно-ориентированного программирования можно использовать в психологии человека. Моя цель — показать, что за техническими терминами часто скрываются идеи, которые могут обогатить наше восприятие не только программирования, но и природы человека.

Вашему вниманию предлагается полный список разделов электронной книги (12 из 11 :)), посвящённой неопределённому поведению. Книга не является учебным пособием и рассчитана на тех, кто уже хорошо знаком с программированием на C++. Это своего рода путеводитель C++ программиста по неопределённому поведению, причём по самым его тайным и экзотическим местам. Автор книги — Дмитрий Свиридкин, редактор — Андрей Карпов.

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

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

К сожалению, и сам С++ не особо стремится стать более "безопасным". Точнее, подобное стремление плохо сочетается с требования к стандарту языка, которые принимаются комитетом по стандартизации С++. Ведь любой стандарт должен обеспечивать обратную совместимость со всем старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++.

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

Таким образом, возникают, казалось бы, взаимоисключающие и не разрешимые противоречия:

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

Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".

Или почему не нужно бояться того, что удобно работает. Узнаем, что по этому поводу пишет стандарт, потом заглянем в реализации std::array в libc++ и libstdc++, затем посмотрим на ассемблер некоторых операций с этими объектами. Завершим всё это дело, как и полагается, бенчмаркингом.

Привет, Хабр! Сегодня я расскажу про whitespace.

Whitespace — это уникальный язык программирования, который использует в качестве своего алфавита только непечатные символы: пробелы, табуляцию и новые строки. Этот эзотерический язык был создан Эдвином Брэди и Крисом Моррисом в 2003 и, разумеется, не предназначен для практического применения, существуя как определенный вызов для программистов — мол, попробуй отладить невидимый код.

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

И в этой статье мы рассмотрим базовые принципы этого безумного языка.

int safeDiv(int a, int b) {
   if (b == 0)
      throw Div0(); // Исключения передаются особым образом
   return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}

Десятки, а то и сотни трёхмерщиков и разработчиков работают над играми. Впрочем, примерный образ пайплайна всем и так известен.

Сегодня мы не рассказываем про нейронку, которая запилит Uncharted 5 или Dark Souls 4, но она сформировала интересный кейс среди нейронок последних годов. Обычно, когда мы говорим про генеративные ИИ, мы представляем себе Идеограмм, Stable Diffuison или SORA.

Но вот разработчики с Google собрали из Stable Diffiusion движок, который генерирует игровой процесс уже существующей игры — Doom из 90s.

О том, как работает подобная нейронка рассказываем ниже.

Периодически читаю комментарии в духе «Разница между Past Simple и Present Perfect – простая грамматическая тема, в школьной программе нормально даётся, или у вас школы какие-то не такие были». Это неправда. Тема тяжелейшая. Не бывает людей, которым она даётся легко. Нередко в ней путаются даже выпускники инязов. Например, в ситуациях, когда оба времени возможны. Пока есть слова-маркеры (when, just, already) – всё более-менее. Без них плывут, потому что плохо понимают саму суть.

Есть мнение, что занятия по иностранному языку на русском ведут только преподаватели с низкой квалификацией. Английский надо преподавать на английском!

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

У меня была студентка, которая ездила на велосипеде не держась руками за руль и при этом вязала. Это не так уж сложно: она любит ездить на велосипеде, часто отпускает руль, вяжет с детства. А представьте учить кого-то СРАЗУ ездить на велосипеде не держась за руль, и чтобы он при этом ещё вязал! Научится, конечно, в конце концов, если не свернёт себе шею в процессе. При изучении языка шею сворачивают редко, зато часто приходят к твёрдому убеждению, что «языки – не моё». По мне, это такая же нелепость, как «я не способен осилить химию в объёме школьного курса – не дано».

Исторически потребность в строках и их использование в игровых движках было довольно ограниченое, кроме, разве что, локализации ресурсов, где была необходимость полноценной поддержки чего-то отличного от набора ASCII символов. Но, при желании, даже эти ресуры разработчики умудрялись упаковать в доступные 200 элементов набора ASCII, а учитывая что игра обычно запускается только в одной локали, то никаких потребностей в конвертации не было. Но есть тут и отличия от стандарта, стараниями Sony практически с начала нулевых, еще до 20 стандарта разработчикам игр были доступны несколько моделей символьных литералов. Стандартый ASCII на PS1 и частичная поддержка Unicode (ISO 10646), с выпуском сдк для второй плойки добавили поддержку UTF-16 и UTF-32, а после выхода PS3 добавили поддержку UTF-8.

Принцип подстановки Лисков гласит, что если метод использует базовый класс, то он должен иметь возможность использовать любой из его производных классов без необходимости иметь информацию о производном классе.

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

Рассмотрим тонкости соблюдения этого принципа, на довольно сложном примере. Начнем с класса хранения данных.

Привет, Хабр! Сегодня я хочу вам представить подборку интересных новостей и материалов по C++ за последнюю неделю.

Приятного чтения!

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