За исключением последнего случая мне так и не удалось провести программу с убранным заголовком мимо реализации В. По закону Мэрфи вам всегда придется вести разработку на таких платформах, как А, С, D и Е, и переносить программы на такие платформы, как В, особенно когда это очень важная работа, которую необходимо сделать как можно скорее. Так бывает всегда.
Но не стоит осуждать компиляторы или разработчиков библиотек за трудности с переносом. Пропущенные заголовки на вашей ответственности. При каждой ссылке на элементы пространства имен std вы также отвечаете за включение соответствующих заголовков. Если заголовки опущены, программа теоретически может откомпилироваться, но другие платформы STL имеют полное право отвергнуть ваш код.
Чтобы вам было проще запомнить необходимые заголовки, далее приведена краткая сводка содержимого всех стандартных заголовков, относящихся к 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 и bnd2nd) объявляются в заголовке <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<chaг,char_traits<char>,allocator<char> >
Это связано с тем, что понятие строки С++ было обобщено до последовательности символов произвольного типа, обладающих произвольными характеристиками («traits») и хранящихся в памяти, выделенной произвольными распределителями. Все string-подобные объекты С++ в действительности являются специализациями шаблона 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 перечислены некоторые ресурсы, в которых можно найти альтернативные реализации.
Независимо от того, как тип string упоминается в диагностике компилятора, методика приведения диагностики к осмысленному минимуму остается той же: хитроумная конструкция с basic_string заменяется текстом «string». Если вы используете компилятор командной строки, задача обычно легко решается при помощи программы sed или сценарных языков типа Perl, Python или Ruby (пример сценария приведен в статье Золмана (Zolman) «Аn STL Error Message Decryptor for Visual С++» [26]). В приведенном примере производится глобальная замена фрагмента
std::basic_string<char,struct std::char_traits<char>,class std::allocator<char>>
строкой string, в результате чего будет получено следующее сообщение:
example.срр(20):еггог С2664:'))thscall string::string(const class std::allocator<char>&)':cannot convert parameter 1 from 'const int' to 'const class std::allocator<char>&'
Из этого сообщения можно понять, что проблема связана с типом параметра, переданного конструктору string. Несмотря на загадочное упоминание allocator<char>, вам не составит труда просмотреть различные формы конструкторов string и убедиться в том, что ни одна из этих форм не вызывается только с аргументом размера.
Кстати, упоминание распределителя памяти (allocator) связано с наличием у всех стандартных контейнеров конструктора, которому передается только распределитель памяти. У типа string существуют три одноаргументных конструктора, но компилятор по какой-то причине решает, что вы пытаетесь передать именно распределитель. Его предположение ошибочно, а диагностика лишь сбивает с толку.
Что касается конструктора, получающего только распределитель памяти, — пожалуйста, не используйте его; он слишком часто приводит к появлению однотипных контейнеров с неэквивалентными распределителями памяти. Как правило, такая ситуация крайне нежелательна (более подробные объяснения приведены в совете 11).
Рассмотрим пример более сложной диагностики. Предположим, вы реализуете программу для работы с электронной почтой, которая позволяет ссылаться на адресатов не только по адресам, но и по синонимам — скажем, адресу президента США ( [email protected]) ставится в соответствие синоним «The Big Cheese». В такой программе может использоваться ассоциативный контейнер для отображения синонимов на адреса электронной почты и функция showEmailAddress, которая возвращает адрес для заданного синонима:
class NiftyEmailProgram {
private:
typedef map<string,string> NicknameMap;
NicknameMap ncknames;
public:
void showEmai1Address(const string& nickname) const;
};
В реализации showEmailAddress потребуется найти адрес электронной почты, ассоциированный с заданным синонимом. Для этого может быть предложен следующий вариант:
void NiftyEmail Program::showEmailAddress(const string& nickname) const
{
NicknameMap::iterator =nicknames.find(nickname);
if (i !=ncknames.end ())...
};
Компилятору такое решение не понравится. На то есть веская, но не очевидная причина. Чтобы помочь вам разобраться в происходящем, одна из платформ STL услужливо выдает следующее сообщение:
example.cpp(17):error С2440:'initializing': cannot convert from 'class std::_Tree<class std::basic_string<char.struct std::char_traits<char>,class std::allocator<char> >,struct std::pair<class std::basic_string<char,struct std::char_traits<char>.class std::allocator<char> > const.class std::basic_string<char,struct std::char_traits<char>.class std::allocator<char> > >.struct std::map<class std::basic_string<char.struct std::char_traits<char>,class std::allocator<char> >,class std::basic_string<char,struct std::char_traits<char>.class std::allocator<char> >,struct std::less<class std::basc_string<char.struct std::char_traits<char>.class std::allocator<char> > >,class std::allocator<class std::basc_string<char,struct std::char_traits<char>,class std::allocator<char> > > >::_Kfn.struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > >::const_iterator' to 'class std::_Tree<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >.struct std::pair<class std::basic_string<char.struct std::char_traits<char>.class std::allocator<char> > const.class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >.struct std::map<class std::basic_string<char.struct std::char_traits<char>.class std::allocator<char> >.class std: std::char_traits<char>.class std::allocator<char> >,struct std std::basic_string<char,struct std::char_traits<char>.class std basic_st ring<char,struct :less<class :allocator<char> >,struct std::less<class std::basic_string<char,struct std::char_traits<char>.class std::allocator<char> > >.class std::allocator<class std std::char traits<char>.class std::allocator<char> : basic_string<char. struct : Kfn,struct std::less<class std::<class std::basic_string<char.struct std::char_traits<char>.class std::allocator<char> >.struct std std::char_traits<char>.class std: std::basic_string<char.struct std :pair<class std::basic_string<char.struct allocator<char> > const.class::char traits<char>.class std::allocator<char> >,struct std::map<class std::basic_string<char,struct std::char_traits<char>.class std::allocator<char> >.class std std::allocator<char> >.struct std std::char_traits<char>,class std: std::basic_string<char,struct std ::_Kfn,struct std::less<class std std::allocator<char> > >.class std basic_string<char.struct std::char_traits<char>.class less<class std::basic_string<char.struct allocator<char> > >,class std char_traits<char>,class std: basic string<char.struct std :allocator<class allocator<char> > > > :char traits<char>,class :allocator<class std::basic_string<char.struct std::char_traits<char>.class std::allocator<char> > > >:iterator'
