Здравствуйте, cppguard, Вы писали:
C>Часто можно слышать, что С++ выбирают за быстроту при большом многообразии выразительных средств. И вот читая очередную статью про противоестественную ошибку на пустом месте у меня вдруг возник вопрос: а как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода? Вот допустим описал программист нетривиальный конструктор у класса, который должен по всем правилам избегать двойного копирования (copy elision, move semantics, etc.), но запутался в l-value и r-value ссылках, в итоге код получился неоптимальным. Но если судить по тем статьям, что описывают такие случаи, то проблема обнаруживается или когда бинарный код начинает неимоверно жиреть, или когда производительность заметно падает в узких местах. Получается, что чтобы пользоваться всеми преимуществами С++, нужно или каждый метод при каждом изменении прогонять через godbolt и глазами убеждаться, что компилятор понял идею автора правильно, или обложиться тестами производительности по самое не хочу. Или есть какой-то другой метод? Вариант "мы нанимаем только экспертов С++" я не рассматриваю, потому что вся история ЭВМ построена на уменьшении влияния человеческого фактора на процесс построения корректных и эффективных программ.
Вообще, проблемы решаются по мере возникновения.
А так, тесты, код ревью, различные статические анализаторы кода и программы типа valgrind, и конечно же CI.
Что касается производительности, в CI запускаются также нагрузочные тесты, если производительность просела, то тест зафейлится, потом можно разбираться почему она просела. Особо критичные участки можно и нужно внимательно просматривать, измерять производительность, и смотреть ассемблерный код сгенерированный компилятором. Некритичные участки тестируются только на корректность, но иногда, когда появляется время на рефакторинг можно и их пооптимизировать.
Что касается разбухания бинарника, сейчас на это всем обычно пофиг, но если вдруг он слишком уж разбух, то можно попробовать понять, почему и что-то с этим сделать.
В целом ничего такого уж сложного нет, если постоянно мониторить наиболее критичные параметры. Но конечно ляпы случаются, куда же без них.
C> И вот ещё одно интересное наблюдение: многие именитые фигуры из мира С++ вроде Герба Саттера как таковой рабочий код не пишут, они могут обсуждать новый стандарт, разные скользкие моменты, идиоматичность разных конструкций и вообще что-угодно, кроме написания production-ready кода. А один из самых известных авторов и проповедников С++, Скотт Мейерс, вообще ни разу в жизни не работал программистом, если верить ему самому. Только вдумайтесь — человек, который консультирует в области использования С++, сам никогда не писал на нём!
Вообще, если бы настоящие программисты, которые успели написать миллионы строк говнокода, который как-то работает в продакшене но может посыпаться в любой момент, следовали бы советам Мейерса, мир был бы чуть лучше.
Хоть Мейерс и не работал программистом, в его книгах реомендации дельные и практичные, их можно и нужно применять в том числе и в продакшене.
У Саттера да, по большей части про всякие особо тонкие моменты, которые в реальности редко кому нужны. Но про это тоже иногда полезно почитать и послушпать...
