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

Александреску Андрей

Однако хуже всего то, что спецификации исключений — очень "тупой" инструмент: при нарушении они по умолчанию немедленно прекращают выполнение программы. Вы можете зарегистрировать функцию-обработчик данного нарушения, но этот вряд ли вам поможет, поскольку такой обработчик только один на всю программу, и все, что он может сделать для того, чтобы избежать немедленного завершения программы, — это сгенерировать допустимое исключение. Но, напомним, такой обработчик — единственный для всего приложения, так что трудно представить, как можно сделать что-то полезное в такой ситуации или как

узнать, какое исключение можно повторно сгенерировать в нем без вмешательства во все спецификации исключений (например, определить, что все спецификации исключений должны

включать некоторое общее исключение

UnknownException

, генерируемое обработчиком. Заметим, что это автоматически уничтожит все преимущества от использования спецификаций исключений).

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

Снижение производительности в обмен на введение ограничений практически всегда бесполезно. Это отличный пример преждевременной пессимизации (см. рекомендацию 9).

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

Исключения

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

class Base { //... // В чужом классе имеется

 virtual f // спецификация исключений,

throw(X, Y, Z) ; // и если вы не можете

}; // ее удалить...

class MyDerived

 : public Base { //... // ... то в вашем классе при

 virtual f // перегрузке функции она должна

throw(X, Y, Z); // иметь совместимую (желательно

}; // идентичную) спецификацию исключений

Из опыта [BoostLRG] следует, что только пустые спецификации исключений (т.е.

throw

) у невстраиваемых функций "могут давать некоторое преимущество у некоторых компиляторов". Не слишком оптимистичное заявление для одного из наиболее

продвинутых, разрабатываемого экспертами мирового уровня проекта…

Ссылки

[BoostLRG] • [Stroustrup00] §14.1, §14.6 • [Sutter04] §13

STL: контейнеры

Если вам нужен контейнер, по умолчанию используйте

vector

.

— Бьярн Страуструп (Bjarne Stroustrup), [Stroustrup00] §17.7

Мы знаем, что вы уже предпочитаете использовать стандартные контейнеры вместо написанных вручную. Но какой именно контейнер следует использовать? Что должно (и что не должно) храниться в контейнерах и почему? Как следует заполнять контейнеры? Какие важные идиомы надо знать?

В этом разделе имеются ответы на все перечисленные (и не только) вопросы. И не случайно, что три первые рекомендации в нем содержат слова "Используйте

vector

...".

В этом разделе мы считаем наиболее значимой рекомендацию 79 — "Храните в контейнерах только значения или интеллектуальные указатели". К ней мы добавим — если даже вы не планируете применять [Boost] и [C++TR104] для иных целей, все равно воспользуйтесь их интеллектуальным указателем

shared_ptr

.

76. По умолчанию используйте

vector

. В противном случае выбирайте контейнер, соответствующий задаче

Резюме

Очень важно использовать "правильный контейнер". Если у вас есть весомые причины выбрать определенный тип контейнера, используйте тот контейнер, который наиболее подходит для вашей задачи.

Если конкретных предпочтений нет, возьмите

vector

и спокойно работайте, зная, что вы сделали верный выбор.

Обсуждение

Ниже представлены три главных аспекта, которые касаются программирования вообще, и выбора контейнера в частности.

• Следует писать в первую очередь корректный, простой и понятный код (см. рекомендацию 6). Предпочтителен выбор контейнера, который позволит вам написать наиболее понятный код. Так, если вам требуется вставка в определенную позицию, используйте последовательный контейнер (например,

vector

,

list

). Если вам нужен итератор произвольного доступа, выберите

vector

,

deque

или

string

. Если нужен словарный поиск наподобие

c[0]=42;

, воспользуйтесь ассоциативным контейнером (например,

set

,

map

) — но если вам требуется упорядоченная ассоциативная коллекция, то вы не можете использовать контейнеры с использованием хеширования (нестандартные

hash_

… или стандартные

unordered_

… контейнеры).