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

Добавлю еще, что одним из мощных стимулов к написанию данной статьи стало то, что очень часто на глаза попадаются объемные флеймыобсуждения на тему «ООП не нужно» и, особенно, «шаблоны-дженерики на практике почти никогда не нужны». Мне, как далеко не молодому программисту, начинавшему в 1990-ом как раз с инструментов, в которых не было ни ООП, ни шаблонов-дженериков, странно сталкиваться с подобными точками зрения. Но, чем дальше, тем чаще с ними сталкиваешься. Особенно со стороны приверженцев новых языков программирования, вроде Go или Rust-а.

Сложно сказать, чем это вызвано. Может быть людей перекормили ООП (а это так и было)… Может быть задачи за несколько минувших десятилетий сильно поменялись (а это так и есть)… Может быть и просто «вот и выросло поколение»… Как бы то ни было, можно попробовать на примере из реальной жизни показать, что все не так однозначно ©.

Итак, о чем пойдет речь?

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

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