Сначала я хотел включить в книгу отдельную главу, посвященную вопросам эффективности, но в итоге решил, что лучше оставить привычное деление на советы. Тем не менее многие советы посвящены минимизации затрат памяти и ресурсов на стадии исполнения. Для удобства ниже приводится краткое содержание «виртуальной главы», посвященной эффективности.
Совет 4.Вызывайте empty вместо сравнения size() с нулем
Совет 5.Используйте интервальные функции вместо одноэлементных
Совет 14.Используйте reserve для предотвращения лишних операций перераспределения памяти
Совет 15.Помните о различиях в реализации string
Совет 23.Рассмотрите возможность замены ассоциативных контейнеров сортированными векторами
Совет 24.Тщательно выбирайте между map::operator[] и map::insert
Совет 25.Изучите нестандартные хэшированные контейнеры
Совет 29.Рассмотрите возможность использования istreambuf_iterator при посимвольном вводе
Совет 31.Помните о существовании разных средств сортировки
Совет 44.Используйте функции контейнеров вместо одноименных алгоритмов
Совет 46.Передавайте алгоритмам объекты функций вместо функций
Рекомендации, составляющие 50 советов этой книги, основаны на мнениях и наблюдениях опытнейших программистов STL. Они в краткой форме подводят итог всему, что практически всегда следует (или наоборот, не следует) делать для успешного использования библиотеки STL. С другой стороны, это всего лишь рекомендации, и в некоторых ситуациях их нарушения вполне оправданны. Например, в заголовке совета 7 говорится о необходимости вызова >delete для указателей перед уничтожением контейнера. Но из текста совета становится ясно, что это правило действует лишь в тех случаях, когда объекты, на которые ссылаются указатели, должны уничтожаться раньше самого контейнера. Обычно это действительно так, но не всегда. Приведу другой пример — в заголовке совета 35 предлагается использовать алгоритмы STL для выполнения простых сравнений строк без учета регистра, но из текста совета следует, что в некоторых случаях лучше использовать функцию не только внешнюю по отношению к STL, но даже не входящую в стандарт С++!
Только хорошее знание специфики программы и условий ее работы позволит определить, стоит ли нарушать представленные рекомендации. Обычно этого лучше не делать, но в отдельных случаях возможны исключения. Как рабская покорность, так и безрассудное легкомыслие одинаково вредны. Прежде чем сходить с проторенной дороги, убедитесь в том, что для этого есть достаточно веские причины.
