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

Мейерс Скотт
Шрифт:

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

vector
объявляется в заголовке
<vector>
,
list
объявляется в заголовке
<list>
и т. д. Исключениями являются
<set>
и
<map>
. В заголовке
<set>
объявляются контейнеры
set
и
multiset
, а в заголовке
<map>
объявляются контейнеры
map
и
multimap
.

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

<algorithm>
. Исключениями являются алгоритмы
accumulate
(см. совет 37),
inner_poduct
,
adjacent_difference
и
partial_sum
. Эти алгоритмы объявляются в заголовке
<numeric>
.

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

istream_iterator
и
streambuf_iterator
(см. совет 29), объявляются в заголовке
<iterator>
.

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

less<T>
) и адаптеры функторов (например
not1
и
bind2nd
) объявляются в заголовке
<functional>
.

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

#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
.

Вспомните, что

string
— не самостоятельный класс, а простой синоним для следующего типа:

basic_string<char, char_traits<char>, allocator<char> >

Это связано с тем, что понятие строки C++ было обобщено до последовательности символов произвольного типа, обладающих произвольными характеристиками («traits») и хранящихся в памяти, выделенной произвольными распределителями. Все

string
– подобные объекты C++ в действительности являются специализациями шаблона
basic_string
, поэтому при диагностике ошибок, связанных с неверным использованием
string
, большинство компиляторов упоминает тип
basic_string
(некоторые компиляторы любезно включают в диагностику имя
string
, но большинство из них этого не делает). Нередко в диагностике указывается на принадлежность
basic_string
(а также вспомогательных шаблонов
char_traits
и
allocator
) к пространству имен
std
, поэтому в сообщениях об ошибках, связанных с использованием string, нередко упоминается тип

std::basic_string<char, std::char_traits<char>, std::allocator<char> >

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

string
по-разному. На другой платформе STL ссылка на
string
выглядит иначе:

basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >

Имена

string_char_traits
и
default_alloc_template
не являются стандартными, но такова жизнь. Некоторые реализации STL отклоняются от Стандарта. Если вам не нравятся отклонения в текущей реализации STL, подумайте, не стоит ли перейти на другую реализацию. В совете 50 перечислены некоторые ресурсы, в которых можно найти альтернативные реализации.