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

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

Совет 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 перечислены некоторые ресурсы, в которых можно найти альтернативные реализации.

Независимо от того, как тип string упоминается в диагностике компилятора, методика приведения диагностики к осмысленному минимуму остается той же: хитроумная конструкция с basic_string заменяется текстом «string». Если вы используете компилятор командной строки, задача обычно легко решается при помощи программы sed или сценарных языков типа Perl, Python или Ruby (пример сценария приведен в статье Золмана (Zolman) «An STL Error Message Decryptor for Visual C++» [26]). В приведенном примере производится глобальная замена фрагмента

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

строкой string, в результате чего будет получено следующее сообщение:

example.срр(20):error С2664:'))thiscall 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 nicknames;
public:
 void showEmailAddress(const string& nickname) const;
};

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

void NiftyEmail Program::showEmailAddress(const string& nickname) const {
 NicknameMap::iterator i = nicknames.find(nickname);
 if (i !=nicknames.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::basic_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_string<char, struct std::less<class std::allocator<char> >, struct std::less<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char> > >, class std::allocator<class 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::char_traits<char>, class std::basic_string<char, struct std::pair<class std::basic_string<char, struct allocator<char> > const, class 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::allocator<char> >, struct std::char_traits<char>, class std::basic_string<char, struct std::_Kfn, struct std::less<class 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 std::allocator<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char> > > >::iterator'
No constructor could take the source type, or constructor overload resolution was ambiguous

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

Давайте немного сократим эту хаотическую запись и приведем ее к более удобному виду. Начнем с замены конструкции basic_string… на string. Результат выглядит так:

example.cpp(17):error С2440:'initializing': cannot convert from 'class std::_Tree<class string, struct std::pair<class string const, class string >, struct std::map<class string, class string, struct std::less<class string>, class std::allocator<class string > >::_Kfn, struct std::less<class string>, class std::allocator<class string> >::const_iterator' to 'class std::_Tree<class string, struct std::pair<class string const, class string>, struct std::map<class string, class string, struct std::less<class string>, class std::allocator<class string> >::_Kfn, struct std::less<class string>, class std::allocator<class string> >: iterator'
No constructor could take the source type, or constructor overload resolution was ambiguous

Уже лучше. Осталось каких-нибудь 745 символов, можно начинать разбираться в сообщении. В глаза бросается упоминание шаблона std::_Tree. В Стандарте ничего не сказано о шаблоне с именем Tree, но мы помним, что имена, начинающиеся с символа подчеркивания и прописной буквы, зарезервированы для авторов реализаций. Перед нами один из внутренних шаблонов, используемых в реализации некой составляющей STL.

Оказывается, практически во всех реализациях STL стандартные ассоциативные контейнеры (set, multiset, map и multimap) строятся на основе базовых шаблонов. По аналогии с тем, как при использовании string в диагностике упоминается тип basic_string, при работе со стандартными ассоциативными контейнерами часто выдаются сообщения с упоминанием базовых шаблонов. В данном примере этот шаблон называется _Tree, но в других известных мне реализациях встречались имена tree и _rb_tree, причем в последнем имени отражен факт использования красно-черных (Red-Black) деревьев, самой распространенной разновидности сбалансированных деревьев, встречающейся в реализациях STL.

В приведенном выше сообщении упоминается знакомый тип std::map<class string, class string, stuct std::less<class string>, class std::allocator<class string> >. Перед нами тип используемого контейнера map, если не считать типов функции сравнения и распределителя памяти (которые не были заданы при определении контейнера). Сообщение об ошибке станет более понятным, если заменить этот тип нашим вспомогательным определением NicknameMap. Результат:

example.срр(17):error С2440:'initalzing': cannot convert from 'class std::_Tree<class string, struct std::pair<class string const, class string >, struct NicknameMap::_Kfn, struct std::less<class string>, class std::allocator<class string > >::const_iterator' to 'class std::_Tree<class string, struct std::pair<class string const, class string>, struct NicknameMap_Kfn, struct std::less<class string>, class std::allocator<class string> >: iterator'
No constructor could take the source type, or constructor overload resolution was ambiguous

Сообщение стало короче, но его смысл остался туманным; нужно что-то сделать с _Tree. Известно, что шаблон _Tree зависит от реализации, поэтому узнать смысл его параметров можно только одним способом — чтением исходных текстов. Но зачем копаться в исходных текстах реализации STL, если это не нужно? Попробуем просто заменить все данные, передаваемые Tree, условным обозначением «НЕЧТО» и посмотрим, что из этого выйдет. Результат:

example.cpp(17):error С2440:'initalizing': cannot convert from 'class std::_Tree<НЕЧТО::const_iterator' to 'class std::_Tree<НЕЧТО:iterator'
No constructor could take the source type, or constructor overload resolution was ambiguous

А вот с этим уже можно работать. Компилятор жалуется на попытку преобразования const_iterator в iterator с явным нарушением правил константности.

Вернемся к исходному примеру; строка, вызвавшая гнев компилятора, выделена жирным шрифтом:

class NiftyEmailProgram {
private:
 typedef map<string, string> NicknameMap;
 NicknameMap nicknames;
public:
 void showEmailAddress(const string& nickname) const;
};
void NiftyEmailProgram::showEmailAddress(const string& nickname) const {
 NicknameMap::iterator i = nicknames.find(nickname);
 if (i != nicknames.end())…
}

Сообщение об ошибке можно истолковать лишь одним разумным образом — мы пытаемся инициализировать переменную i (типа iterator) значением типа const_iterator, возвращаемым при вызове map::find. Такая интерпретация выглядит несколько странно, поскольку find вызывается для объекта nicknames. Объект nicknames не является константным, поэтому функция find должна вернуть неконстантный итератор.

Взгляните еще раз. Да, объект nicknames объявлен как неконстантный тип map, но функция showEmalAddress является константной, а внутри константной функции все нестатические переменные класса становятся константными! Таким образом, внутри showEmalAddress объект nicknames является константным объектом map. Сообщение об ошибке внезапно обретает смысл. Мы пытаемся сгенерировать iterator для объекта map, который обещали не изменять. Чтобы исправить ошибку, необходимо либо привести i к типу const_iterator, либо объявить showEmalAddress неконстантной функцией. Вероятно, оба способа потребуют значительно меньших усилий, чем выяснение смысла сообщения об ошибке.

В этом совете были показаны некоторые текстовые подстановки, уменьшающие сложность сообщений об ошибках, но после непродолжительной практики вы сможете выполнять подстановки в голове. Я не музыкант, но мне рассказывали, что хорошие музыканты способны читать партитуру целиком, не присматриваясь к отдельным нотам. Опытные программисты STL приобретают аналогичные навыки. Они могут автоматически преобразовать конструкцию вида std::basic_string<char, std::char_traits<char>, std::allocator<char> > в string, нисколько не задумываясь над происходящим. Подобный навык разовьется и у вас, но до этих пор следует помнить, что диагностику компилятора почти всегда можно привести к вразумительному виду заменой длинных типов на базе шаблонов более короткими мнемоническими обозначениями. Во многих случаях для этого достаточно заменить расширенные определения типов именами, используемыми в программе. Именно это было сделано в приведенном примере, когда мы заменили std::map<class string, class string, struct std::less<class string>, class std::allocator<class string> >  на NicknameMap.

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

• Для контейнеров vector и string итераторы обычно представляют собой указатели, поэтому в случае ошибки с итератором в диагностике компилятора обычно указываются типы указателей. Например, если в исходном коде имеется ссылка на vector<double>::iterator, в сообщении почти наверняка будет упоминаться указатель double*. Исключение составляет реализация STLport в отладочном режиме; в этом случае итераторы vector и string не являются указателями. За информацией о STLport и отладочном режиме обращайтесь к совету 50.

• Сообщения, в которых упоминаются back_insert_iterator, front_insert_iterator и insert_iterator, почти всегда означают, что ошибка была допущена при вызове back_inserter, front_inserter или inserter соответственно (back_inserter возвращает объект типа back_insert_iterator, front_inserter возвращает объект типа front_insert_iterator, a inserter возвращает объект типа insert_iterator; за информацией об этих типах обращайтесь к совету 30). Если эти функции не вызывались в программе, значит, они были вызваны из других функций (косвенно или явно).

• Сообщения с упоминаниями binder1st и binder2nd обычно свидетельствуют об ошибке при использовании bind1st и bind2nd(bind1st возвращает объект типа binder1st, a bind2nd возвращает объект типа binder2nd).

• Итераторы вывода (например, ostream_iterator и ostream_buf_iterator — см. совет 29, а также итераторы, возвращаемые back_inserter, front_inserter и inserter) выполняют свои операции вывода или вставки внутри операторов присваивания, поэтому ошибки, относящиеся к этим типам итераторов, обычно приводят к появлению сообщений об ошибке внутри операторов присваивания, о которых вы и понятия не имеете. Чтобы понять, о чем идет речь, попробуйте откомпилировать следующий фрагмент:

vector<string*> v;                     // Попытка вывода содержимого
copy(v.begin(), v.end(),             // контейнера указателей string*
ostream_iterator<string>(cout, "n")); // как объектов string

• Если полученное сообщение об ошибке исходит из реализации алгоритма STL (то есть если код, в котором произошла ошибка, находится в <algoritm>), вероятно, проблема связана с типами, которые вы пытаетесь передать этому алгоритму. Пример — передача итераторов неправильной категории. Попробуйте откомпилировать следующий фрагмент:

list<int>::iterator i1, i2; // Передача двусторонних итераторов
sort(i1, i2);               // алгоритму, которому необходимы итераторы
                            // произвольного доступа

• Если вы используете стандартный компонент STL (например, контейнер vector или string, алгоритм for_each), а компилятор утверждает, что он понятия не имеет, что имеется в виду, скорее всего, вы забыли включить необходимый заголовочный файл директивой #include. Как объясняется в совете 48, эта проблема может нарушить работоспособность кода, успешно компилировавшегося в течение некоторого времени, при переносе его на другую платформу.

Оглавление книги