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

Из этого сообщения можно понять, что проблема связана с типом параметра, переданного конструктору string. Несмотря на загадочное упоминание allocator, вам не составит труда просмотреть различные формы конструкторов stringи убедиться в том, что ни одна из этих форм не вызывается только с аргументом размера.

Кстати, упоминание распределителя памяти (allocator) связано с наличием у всех стандартных контейнеров конструктора, которому передается только распределитель памяти. У типа stringсуществуют три одноаргументных конструктора, но компилятор по какой-то причине решает, что вы пытаетесь передать именно распределитель. Его предположение ошибочно, а диагностика лишь сбивает с толку.

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

Рассмотрим пример более сложной диагностики. Предположим, вы реализуете программу для работы с электронной почтой, которая позволяет ссылаться на адресатов не только по адресам, но и по синонимам — скажем, адресу президента США (president@whitehouse.gov) ставится в соответствие синоним «The Big Cheese». В такой программе может использоваться ассоциативный контейнер для отображения синонимов на адреса электронной почты и функция showEmailAddress, которая возвращает адрес для заданного синонима:

class NiftyEmailProgram {

private:

typedef map 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::allocator >, struct std::pair, class std::allocator > const, class std::basic_string, class std::allocator > >, struct std::map, class std::allocator >, class std::basic_string, class std::allocator >, struct std::less, class std::allocator > >, class std::allocator, class std::allocator > > >::_Kfn, struct std::less, class std::allocator > >, class std::allocator, class std::allocator > > >::const_iterator' to 'class std::_Tree, class std::allocator >, struct std::pair, class std::allocator > const, class std::basic_string, class std::allocator > >, struct std::map, class std::allocator >, class std: std::char_traits, class std::allocator >, struct std std::basic_string, class std::basic_string >, struct std::less, class std::allocator > >, class std::allocator, class std::allocator : basic_string, class std::allocator >, struct std::char_traits, class std::basic_string > const, class std::char_traits, class std::allocator >, struct std::map, class std::allocator >, class std std::allocator >, struct std::char_traits, class std::basic_string > >, class std::basic_string, class less > >, class std::char_traits, class std::basic_string > > >::char traits, class std::allocator, class std::allocator > > >::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, struct std::map, class std::allocator >::_Kfn, struct std::less, class std::allocator >::const_iterator' to 'class std::_Tree, struct std::map, class std::allocator >::_Kfn, struct std::less, class std::allocator >: 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.