Работаешь ли ты со своей техникой?

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

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

Профилирование — вот где собака зарыта. perf — это мой основной молоток, легкий и смертоносный. А для особо замороченных случаев, когда надо понять, что там у процессора в конвейере творится, беру VTune. Это уже, блядь, хирургический инструмент.

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

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

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

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

Стиль и автоматизация Стиль кода — в основном Google C++ Style Guide, но без фанатизма. Если в проекте свои заморочки — адаптируюсь. Главное — чтобы в одном проекте было единообразие, а то смотришь на код — а там у каждого свой почерк, как у врача, нихуя не понять.

Поэтому clang-format и clang-tidy — святое. Форматтер перед каждым коммитом прогоняю, чтобы не было споров из-за пробелов и отступов. А clang-tidy ловит всякие потенциальные косяки, которые в голову не придут. Доверия к себе, блядь, ноль — лучше пусть машина проверит.

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

• Взял perf stat, запустил — смотрю, где время жрёт.
• Оказалось, проблема даже не в вычислениях, а в постоянных аллокациях памяти внутри горячего цикла. Каждая итерация — новый new, потом delete. Ядрёна вошь! Память-то дефрагментируется, кэш промахивается — вот и тормоза.
• Переписал. Вынес std::vector за цикл, сделал ему reserve() на нужный размер, а внутри цикла использовал std::move или emplace_back, чтобы объекты перекладывались, а не копировались.
• Результат? 40% прирост скорости, просто заменив паттерн работы с памятью. Без единой ассемблерной вставки. Вот тебе и хитрая жопа — проблема была не там, где искали изначально.

В общем, суть подхода Система не стоит на месте. Сейчас вот C++20 Concepts осваиваю — офигенная вещь для тех самых интерфейсов, ошибки компиляции читабельнее становятся в разы. Для сборки монструозных проектов присматриваюсь к Bazel. Если не учиться новому, так и останешься в 2011-м году с boost::bind и ручным управлением памятью. А это, я тебе скажу, путь в никуда.