Стиль C ++ против производительности?

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

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

• Использование Itoa, Atoi и т. Д. Вместо потоков быстрее. Да, это. Но насколько быстрее? Немного. Если большая часть вашей программы не выполняет только преобразования из текста в строку, и наоборот, вы не заметите разницу. Почему люди используют itoa, atoi и т. Д.? Ну, некоторые из них, потому что они не знают об альтернативе c ++. Другая группа делает, потому что это просто один LOC. Для первой группы - позор вам, для второй - почему бы не повысить :: lexical_cast?

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

• необработанных указателей - Мое собственное мнение таково: никогда не используйте умные указатели, когда речь идет не о владении. Всегда используйте умные указатели, когда речь идет о владении. Естественно, с некоторыми исключениями.

• сдвиг бит вместо умножения на степени двух. Это, я считаю, классический пример преждевременной оптимизации. x << 3; Бьюсь об заклад, как минимум 25% ваших коллег потребуется некоторое время, прежде чем они поймут / осознают это средство x * 8; Запутанный (хотя бы на 25%) код, по каким именно причинам? Опять же, если профилировщик скажет вам, что это узкое место (что, я сомневаюсь, будет иметь место в очень редких случаях), тогда зеленый свет, продолжайте и сделайте это (оставив комментарий, который на самом деле означает x * 8)

Подводя итог. Хороший профессионал признает «хорошие стили», понимает, почему и когда они хороши, и по праву делает исключения, потому что знает, что делает. Средние / плохие профессионалы подразделяются на 2 типа: первый тип не признает хороший стиль, даже не понимает, что и почему. уволить их. Другой тип рассматривает стиль как догму, что не всегда хорошо.

1. Функции с изменяемыми char* аргументами плохи в C ++, потому что слишком сложно вручную обрабатывать их память, поскольку у нас есть альтернативы. Они не являются общими, мы не можем легко переключиться с char на wchar_t, как позволяет basic_string. Также lexical_cast является более прямой заменой для atoi, itoa.
2. Если вам не нужен умный указатель - не используйте его.
3. Для обмена используйте swap. Используйте побитовые операции только для побитовых операций - проверка / установка / инвертирование флагов и т. Д.
4. Исключения бывают быстрыми. Они позволяют удалять ветки условий проверки ошибок, поэтому, если они действительно «никогда не происходят», они повышают производительность.

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