Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

В этой перегрузке параметр nameсвязывается с переданным значением типа short. Таким образом, nameпередается с помощью std::forwardфункции-члену emplaceобъекта names(std::multiset), которая, в свою очередь, послушно передает его конструктору std::string. Но конструктора std::string, который принимал бы значение short, не существует, так что вызов конструктора std::stringв вызове multiset::emplaceв вызове logAndAddнеудачен. Все дело в том, что перегрузка для универсальной ссылки точнее соответствует аргументу типа short, чем перегрузка для int.

Функции, принимающие универсальные ссылки, оказываются самыми жадными в С++. Они в состоянии выполнить инстанцирование с точным соответствием практически для любого типа аргумента (несколько видов аргументов, для которых это не так, описаны в разделе 5.8). Именно поэтому сочетание перегрузки и универсальной ссылки почти всегда является плохой идеей: перегрузка для универсальных ссылок годится для гораздо большего количества типов аргументов, чем обычно ожидает разработчик перегрузок.

Простой способ свалиться в эту яму — написать конструктор с прямой передачей. Небольшое изменение функции logAndAddдемонстрирует эту проблему. Вместо написания свободной функции, которая принимает либо std::string, либо индекс, который можно использовать для поиска std::string, представим себе класс Personс конструкторами, которые выполняют те же действия:

class Person {

public:

template

explicit Person(T&& n) // Конструктор с прямой передачей

: name(std::forward(n)){} // инициализирует члены-данные

explicit Person(int idx) // Конструктор с параметром int

: name(nameFromIdx(idx)) {}

…

private:

std::string name;

};

Как и в случае с logAndAdd, передача целочисленного типа, отличного от int(например, std::size_t, short, longи т.п.), будет вызывать перегрузку конструктора для универсальной ссылки вместо перегрузки для int, и это будет вести к ошибкам компиляции. Однако проблема гораздо хуже, поскольку в Person имеется больше перегрузок, чем видит глаз. В разделе 3.11 поясняется, что при соответствующих условиях С++ будет генерировать как копирующие, так и перемещающие конструкторы, и это так и будет, даже если класс содержит шаблонный конструктор, который при инстанцировании в состоянии дать сигнатуру копирующего или перемещающего конструктора. Если таким образом генерируются копирующий и перемещающий конструкторы для Person, класс Personбудет выглядеть, по сути, следующим образом:

class Person {

public:

template // Конструктор с прямой передачей

explicit Person(T&& n)

: name(std::forward(n)) {}

explicit Person(int idx); // Конструктор от int

Person(const Person& rhs);// Копирующий конструктор

// (сгенерирован компилятором)

Person(Person&& rhs); // Перемещающий конструктор

// (сгенерирован компилятором)

};

Это приводит к поведению, интуитивно понятному, только если вы потратили на работу с компиляторами и общение с их разработчиками столько времени, что забыли, каково это — быть человеком:

Person p("Nancy");

auto cloneOfP(p); // Создание нового объекта Person из p;

// этот код не компилируется!

Здесь мы пытаемся создать объект Personиз другого объекта Person, что представляется очевидным случаем копирующего конструирования ( pявляется lvalue, так что можно выбросить из головы все фантазии на тему “копирования” с помощью операции перемещения). Но этот код не вызывает копирующий конструктор — он вызывает конструктор с прямой передачей. Затем эта функция будет пытаться инициализировать член-данные std::stringобъекта Personзначением из объекта Person( p). Класс std::string не имеет конструктора, получающего параметр типа Person, так что ваш компилятор будет вынужден просто развести руками и наказать вас длинными и непонятными сообщениями об ошибках.

“Но почему, — можете удивиться вы, — вызывается конструктор с прямой передачей, а не копирующий конструктор? Мы же инициализируем Personдругим объектом Person!” Да, это так, но компиляторы приносят присягу свято соблюдать правила С++, а правила, имеющие отношение к данной ситуации, — это правила разрешения вызовов перегруженных функций.

Компиляторы рассуждают следующим образом. cloneOfPинициализируется неконстантным lvalue ( p), а это означает, что шаблонный конструктор может быть инстанцирован для получения неконстантного lvalue типа Person. После такого инстанцирования класс Personвыглядит следующим образом: