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

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

Резюме

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

erase

–

remove

.

Обсуждение

Некоторые контейнеры (например,

vector, string

,

deque

) могут иметь "лишнюю" емкость, которая больше не будет использоваться. Хотя стандартная библиотека C++ не предоставляет гарантированного способа для удаления излишней емкости, следующая идиома на практике оказывается вполне работоспособной:

container<T>(c).swap(c); //

Идиома "горячей посадки" для

// устранения излишней емкости

// контейнера

Для того чтобы полностью опустошить

c

, удалив все элементы и убрав всю емкость, идиома должна выглядеть следующим образом:

container<T>.swap(c); // Идиома для удаления всего

// содержимого и емкости

Кроме того, обычно для новичков в программировании с использованием STL оказывается сюрпризом то, что алгоритм

remove

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

erase

. Удаление сводится к перемещению элементов, которые должны быть "удалены", и возврату итератора, указывающего на элемент, следующий за последним неудаленным. Для реального удаления элементов из контейнера после вызова

remove

следует вызвать

erase

— воспользоваться идиомой

erase

–

remove

. Например, для реального удаления всех элементов, равных value, из контейнера с, можно написать:

c.erase(remove(c.begin, c.end, value), c.end);

Если контейнер имеет собственную версию

remove

или

remove_if

, желательно использовать именно ее.

Исключения

Описанная идиома "горячей усадки" не работает с реализациями

std::string

с копированием при записи. Обычно работает вызов

s.reserve(0)

или такой трюк, как

string(s.begin, s.end).swap(s);

, в котором использован конструктор на основе двух итераторов. На практике эти методы обычно работают и устраняют излишнюю емкость. (Было бы еще лучше, чтобы реализации

std::string

не использовали такой устаревший метод оптимизации, как копирование при записи; см. [Sutter02].)

Ссылки

[Josuttis99] §6.2.1 • [Meyers01] §17, §32, §44 • [Sutter00] §7 • [Sutter02] §7, §16

STL: алгоритмы

Предпочитайте алгоритмы циклам.

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

Алгоритмы представляют собой циклы — только они лучше циклов. Алгоритмы — это "шаблоны" циклов, с добавлением дополнительной семантики по сравнению с простыми

for

и

do

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

В этом

разделе мы считаем наиболее значимой рекомендацию 83 — "Используйте отладочную реализацию STL".

83. Используйте отладочную реализацию STL

Резюме

Безопасность превыше всего (см. рекомендацию 6). Используйте отладочную реализацию STL [4] , даже если она имеется только для одного из ваших компиляторов, и даже если она используется только для отладочного тестирования.

Обсуждение

4

Checked implementation — под этим подразумевается реализация STL с дополнительными проверками в коде, необязательными с точки зрения стандарта. — Прим. перев.

Так же, как легко ошибиться при работе с указателями, легко допустить и ошибку при работе с итераторами, причем такую, что программа при этом успешно компилируется, а при работе немедленно аварийно завершается (в лучшем случае) или работает неверно (в худшем). Даже если ваш компилятор не обнаружил ни одной ошибки, вы не должны полагаться на "визуальный контроль": имеются специальные инструменты — воспользуйтесь ими.

Ряд ошибок при работе с STL часто допускают даже опытные программисты.

• Использование недействительных или неинициализированных итераторов. В особенности легко допустить первое.

• Передача индекса, выходящего за границы контейнера. Например, обращение к 113-му элементу 100-элементного контейнера.

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

• Передача неверной позиции итератора. Вызов функции-члена контейнера, которая получает позицию итератора (как, например, позиция, передаваемая функции

insert

), но с передачей итератора, который указывает в другой контейнер.

• Использование неверного упорядочения. Предоставление неверного правила для упорядочения ассоциативного контейнера или в качестве критерия сравнения в алгоритме сортировки (см. примеры в [Meyers01]). Если не использовать отладочной версии STL, такие ошибки обычно проявляются в процессе выполнения программы как неверное поведение или бесконечные циклы, но не как аварийный останов.

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