Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация

Передача параметров по ссылке (рекомендация 25), использование префиксной формы операторов ++и --(рекомендация 28) или подобных идиом, которые при работе должны естественным образом "стекать с кончиков ваших пальцев", преждевременной оптимизацией не являются. Это всего лишь устранение преждевременной пессимизации (рекомендация 9).

Пример. Ирония использования inline . Это простейшая демонстрация скрытой стоимости преждевременной микрооптимизации. Профайлеры легко могут сказать вам (исследовав количество вызовов функций), какие функции должны быть встраиваемыми, но не являются таковыми. Но те же профайлеры не в состоянии подсказать, какие встраиваемые функции не должны быть таковыми. Очень многие программисты используют "встраивание по умолчанию" во имя оптимизации, почти всегда за счет большей связности программы достигая в лучшем случае весьма сомнительных результатов. (Сказанное означает, что делать функцию встраиваемой должен компилятор, а не программист. См. [Sutter00], [Sutter02] и [Sutter04].)

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

[Bentley00] §6 • [Cline99] §13.01-09 • [Kernighan99] §7 • [Lakos96] §9.1.14 • [Meyers97] §33 • [Murray93] §9.9-10, §9.13 • [Stroustrup00] §6 introduction • [Sutter00] §30, §46 • [Sutter02] §12 • [Sutter04] §25

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

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

• Передача параметров по значению там, где применима передача параметров по ссылке (рекомендация 25).

• Использование постфиксной версии ++там, где с тем же успехом можно воспользоваться префиксной версией (рекомендация 28).

• Использование присваивания в конструкторах вместо списка инициализации (рекомендация 48).

Не является преждевременной оптимизацией снижение количества фиктивных временных копий объектов, в особенности во внутренних циклах, если это не приводит к усложнению кода. В рекомендации 18 поощряется максимально локальное объявление переменных, но там же приведено и описание исключения — возможный вынос переменных из цикла. В большинстве случаев такое действие не усложняет понимание предназначения кода, более того, может помочь пояснить, что именно делается в цикле и какие вычисления являются его инвариантами. Конечно же, предпочтительно использовать готовые алгоритмы вместо написания явных циклов (рекомендация 84).

Два важных способа усовершенствования программы, которые делают ее одновременно и яснее, и эффективнее — это использование абстракций (см. рекомендации 11 и 36) и библиотек (рекомендация 84). Например, использование vector, list, map, find, sortи других возможностей стандартной библиотеки, стандартизированных и реализованных экспертами мирового класса, не только делают ваш код яснее и легче понимаемым, но зачастую и более быстрым.

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

[Keffer95] pp. 12-13 • [Stroustrup00] §6 introduction • [Sutter00] §6

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

Это утверждение носит более общий характер, чем более узкое требование рекомендации 18.

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

Имена объектов в глобальном пространстве имен приводят к его дополнительному засорению.

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

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

Предпочтительно обеспечить низкую связность и минимизировать взаимодействие классов (см. [Cargill92]).

Такие средства уровня программы, как cin, coutи cerr, являются специализированными и реализуются специальным образом. Фабрика должна поддерживать реестр функций, которые должны вызываться для создания данного типа, и такой реестр обычно один на всю программу (тем не менее предпочтительно, чтобы он был внутренним объектом по отношению к фабрике, а не глобальным совместно используемым объектом; см. рекомендацию 11).