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

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выглядит следующим образом:

class Person {

public:

explicit Person(Person& n) // Инстанцирован из

: name(std::forward(n)) {} // шаблона с прямой

// передачей

explicit Person(int idx); // Как и ранее

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

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

};

В инструкции

auto cloneOfP(p);

pможет быть передан либо копирующему конструктору, либо инстанцированному шаблону. Вызов копирующего конструктора для точного соответствия типа параметра требует добавления к pмодификатора const; вызов инстанцированного шаблона никаких добавлений не требует. Таким образом, перегрузка, сгенерированная из шаблона, представляет собой лучшее соответствие, так что компиляторы делают то, для чего предназначены: генерируют вызов той функции, которая соответствует наилучшим образом. “Копирование” неконстантных lvalue типа Person, таким образом, осуществляется конструктором с прямой передачей, а не копирующим конструктором.

Если мы немного изменим пример, так, чтобы копируемый объект был константным, то увидим совершенно иную картину:

constPerson cp("Nancy"); // Теперь объект константный

auto cloneOfP(cp); // Вызов копирующего конструктора!

Поскольку копируемый объект теперь объявлен как const, он в точности соответствует типу параметра, получаемого копирующим конструктором. Шаблонизированный конструктор также может быть инстанцирован таким образом, чтобы иметь ту же сигнатуру:

class Person public:

explicit Person(const Person& n);// Инстанцирован из шаблона

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

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

};

Но это не имеет значения, поскольку одно из правил разрешения перегрузок в С++ гласит, что в ситуации, когда инстанцирование шаблона и нешаблонная функция (т.e. "нормальная" функция) имеют одинаково хорошее соответствие, предпочтение отдается нормальной функции. Поэтому все козыри оказываются на руках копирующего конструктора (нормальной функции) с той же самой сигнатурой.

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

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

class SpecialPerson: public Person {

public:

SpecialPerson(const SpecialPerson& rhs) // Копирующий

: Person(rhs) // конструктор; вызывает конструктор

{ … } // базового класса с прямой передачей!

SpecialPerson(SpecialPerson&& rhs) // Перемещающий

: Person(std::move(rhs))// конструктор; вызывает конструктор

{ … } // базового класса с прямой передачей!

};

Как указывают комментарии, копирующий и перемещающий конструкторы производного класса не вызывают копирующий и перемещающий конструкторы базового класса; они вызывают конструктор базового класса с прямой передачей! Чтобы понять, почему, обратите внимание, что функции производного класса используют аргументы типа SpecialPersonдля передачи в базовый класс, после чего в игру вступает разрешение перегрузок для конструкторов в классе Person. В конечном итоге код не будет компилироваться, потому что у std::stringнет никакого конструктора, принимающего SpecialPerson.

Я надеюсь, что теперь я убедил вас, что перегрузка для параметров, являющихся универсальными ссылками, — это то, чего лучше избегать, насколько это возможно. Но если перегрузка для универсальной ссылки — плохая идея, то что же делать, если вам нужна функция, которая выполняет передачу большинства типов аргументов, но при этом должна обрабатывать некоторые из них особым образом? Это яйцо может быть разбито массой способов. Этих способов так много, что я посвятил им целый раздел — раздел 5.5, который идет сразу после того, который вы сейчас читаете. Не останавливайтесь, и вы попадете прямо в него.

• Перегрузка для универсальных ссылок почти всегда приводит к тому, что данная перегрузка вызывается чаще, чем вы ожидаете.

• Особенно проблематичны конструкторы с прямой передачей, поскольку они обычно соответствуют неконстантным lvalue лучше, чем копирующие конструкторы, и могут перехватывать вызовы из производного класса копирующих и перемещающих конструкторов базового класса.