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

• Гарантирует совместимость размещения в памяти с размещением, используемым языком программирования С, в отличие от остальных стандартных контейнеров (см. рекомендации 77 и 78).

• Гарантирует наличие самых гибких итераторов (произвольного доступа).

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

Есть ли у вас причины не использовать такой контейнер по умолчанию? Если у вас есть такая причина, связанная с одним из трех аспектов в начале этой рекомендации, то все замечательно — просто воспользуйтесь наиболее подходящим для вас контейнером. Если такой причины нет — возьмите vectorи спокойно работайте, зная, что вы сделали верный выбор.

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

Пример. Использование vector для небольших списков. Распространенное заблуждение — использовать listтолько потому, что "очевидно, что list—подходящий тип для выполнения операций со списком", таких как вставка в средину последовательности. Тип vectorдля небольших списков практически всегда превосходит тип list. Несмотря на то, что вставка в средину последовательности требует линейного времени работы у vector, и постоянного — у list, вектор с небольшим количеством элементов обычно справляется с этой задачей быстрее — за счет меньшего постоянного множителя; преимущества асимптотического времени работы listпроявляются только при больших количествах элементов в контейнере.

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

[Austern99] §5.4.1 • [С++03] §23.1.1 • [Josuttis99] §6.9 • [Meyers01] §1-2, §13, §16, §23, §25 • [Musser01] §6.1 • [Stroustrup00] §17.1, §17.6 • [Sutter00] §7, §20 • [Sutter02] §7

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

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

Вот некоторые из причин, по которым массивам в стиле С следует предпочесть стандартные средства С++.

• Они автоматически управляют собственной памятью. Больше не требуется никаких фиксированных буферов с размером "большим, чем любая разумная длина" ("бомба с часовым механизмом" — вот как правильно прочесть это определение), или сплошных перераспределений памяти при помощи reallоси соответствующих обновлений указателей.

• У них богатый интерфейс. Вы легко и выразительно можете реализовать сложную функциональность.

• Они совместимы с моделью памяти в С. vectorи string::c_strмогут быть переданы функциям API на языке С. В частности, в С++ vectorслужит "переходником" к С и другим языкам программирования (см. рекомендации 76 и 78).

• Они обеспечивают расширенные возможности проверки. Стандартные средства позволяют реализовать (в отладочном режиме) итераторы и операторы индексирования, которые способны выявить большой класс ошибок памяти. Многие из современных реализаций стандартной библиотеки предоставляют такие отладочные возможности — воспользуйтесь ими! (См. рекомендацию 83.)