Эффективное использование STL, Мейерс Скотт

Эффективное использование STL

на обложку

Мейерс Скотт

Шрифт:

Да, используйте STL в своей работе. Используйте хорошо и эффективно… но избегайте написания «нечитаемого» кода. В долгосрочной перспективе такой код будет каким угодно, но только не эффективным.

Совет 48. Всегда включайте нужные заголовки

При программировании в STL нередко встречаются программы, которые успешно компилируются на одной платформе, но требуют дополнительных директив

#include

на другой. Этот раздражающий факт связан с тем, что Стандарт C++ (в отличие от Стандарта C) не указывает, какие стандартные заголовки могут или должны включаться в другие стандартные заголовки. Авторы реализаций пользуются предоставленной свободой и выбирают разные пути.

Попробую пояснить, что это значит на практике. Однажды я засел за пять платформ STL (назовем их A, B, C, D и E) и попробовал экспериментальным путем определить, какие стандартные заголовки можно убрать, чтобы программа при этом нормально компилировалась. По этим данным становится ясно, какие заголовки включают другие заголовки директивой

#include

. Вот что я узнал:

• на платформах A и C

включает

;

• на платформе C

включает

;

• на платформах C и D

включает

;

• на платформе D

включает

;

• на платформах D и E

включает

;

• во всех пяти реализациях

<set>

включает

За исключением последнего случая мне так и не удалось провести программу с убранным заголовком мимо реализации B. По закону Мэрфи вам всегда придется вести разработку на таких платформах, как A, C, D и E, и переносить программы на такие платформы, как B, особенно когда это очень важная работа, которую необходимо сделать как можно скорее. Так бывает всегда.

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

Чтобы вам было проще запомнить необходимые заголовки, далее приведена краткая сводка содержимого всех стандартных заголовков, относящихся к STL.

• Почти все контейнеры объявляются в одноименных заголовках, то есть

vector

объявляется в заголовке

list

объявляется в заголовке

<list>

и т. д. Исключениями являются

<set>

<map>

. В заголовке

<set>

объявляются контейнеры

set

multiset

, а в заголовке

<map>

объявляются контейнеры

map

multimap

• Все алгоритмы, за исключением четырех, объявляются в заголовке

. Исключениями являются алгоритмы

accumulate

(см. совет 37),

inner_poduct

adjacent_difference

partial_sum

. Эти алгоритмы объявляются в заголовке

• Специализированные разновидности итераторов, включая

istream_iterator

streambuf_iterator

(см. совет 29), объявляются в заголовке

• Стандартные функторы (например

less<T>

) и адаптеры функторов (например

not1

bind2nd

) объявляются в заголовке

Не забывайте включать соответствующую директиву

#include

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

Совет 49. Научитесь читать сообщения компилятора

При определении вектора в программе вы имеете полное право указать конкретный размер:

vector<int> v(10); // Создать вектор из 10 элементов

Объекты string имеют много общего с vector, поэтому кажется, что следующая команда тоже допустима:

string s(10); // Попытаться определить string из 10 элементов

Однако эта команда не компилируется, поскольку у контейнера

string

не существует конструктора, вызываемого с аргументом типа

int

. На одной из платформ STL компилятор реагирует на эту команду следующим образом:

example.cpp(20):error С2664:'))thiscall std::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::std::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >(const class std::allocator<char>&)': cannot convert parameter 1 from 'const int' to 'const class std::allocator<char>&'

Reason: cannot convert from 'const int' to 'const class std::allocator<char>'

No constructor could take the source type, or constructor overload resolution was ambiguous

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

string