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

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

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

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

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

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

};

Это тот же код, который вы видели ранее, в конце предыдущего раздела, включая комментарии, увы, оставшиеся справедливыми. Копируя или перемещая объект SpecialPerson, мы ожидаем, что части базового класса будут скопированы или перемещены с помощью копирующего или, соответственно, перемещающего конструктора базового класса. Однако в этих функциях мы передаем объекты SpecialPersonконструкторам базового класса, а поскольку SpecialPersonне совпадает с Person(даже после применения std::decay), конструктор с универсальной ссылкой в базовом классе оказывается включенным и без проблем проходит проверку на идеальное совпадение с аргументом SpecialPerson. Это точное соответствие лучше преобразования производного класса в базовый, необходимого для связывания объекта SpecialPersonс параметром Personв копирующем и перемещающем конструкторах класса Person, так что при имеющемся коде копирование и перемещение объектов SpecialPersonбудет использовать для копирования и перемещения частей базового класса конструктор с универсальной ссылкой класса Person! Это чудное ощущение дежавю раздела 5.4…

Производный класс просто следует обычным правилам реализации копирующего и перемещающего конструкторов производного класса, поэтому решение этой проблемы находится в базовом классе и, в частности, в условии, которое контролирует включение конструктора с универсальной ссылкой класса Person. Теперь мы понимаем, что надо включать шаблонный конструктор не для любого типа аргумента, отличного от Person, а для любого типа аргумента, отличного как от Person, так и от типа, производного от Person. Ох уж это наследование!

Вас уже не должно удивлять обилие всяческих полезных шаблонов в стандартной библиотеке, так что известие о наличии шаблона, который определяет, является ли один класс производным от другого, вы должны воспринять с полным спокойствием. Он называется std::is_base_of. Значение std::is_base_of::valueистинно, если T2— класс, производный от T1. Пользовательские типы рассматриваются как производные от самих себя, так что std::is_base_of::valueистинно, если Tпредставляет собой пользовательский тип. (Если Tявляется встроенным типом, std::is_base_of::valueложно.) Это удобно, поскольку мы хотим пересмотреть наше условие, управляющее отключением конструктора с универсальной ссылкой класса Person таким образом, чтобы этот конструктор был включен, только если тип Tпосле удаления всех ссылок и квалификаторов constи volatileне являлся ни типом Person, ни классом, производным от Person. Применение std::is_base_ofвместо std::is_sameдает нам то, что требуется:

class Person {

public:

template<

typename T,

typename = typename std::enable_if<

!std:: is_base_of

typename std::decay::type

>::value

>::type

>

explicit Person(T&& n);

};

Вот теперь работа завершена. Вернее, завершена при условии, что мы пишем код на С++11. При использовании С++14 этот код будет работать, но мы можем использовать псевдонимы шаблонов для std::enable_ifи std::decay, чтобы избавиться от хлама в виде typenameи ::type, получая несколько более приятный код:

class Person { // С++14

public:

template<

typename T,

typename = std::enable_if _t< // Меньше кода здесь

!std::is_base_of

std::decay _t // И здесь

>::value

> // И здесь

>

explicit Person(T&& n);

};

Ладно, я признаю: я соврал. Мы до сих пор не сделали всю работу. Но мы уже близки к завершению. Соблазнительно близки. Честно!

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

Все, что нам нужно сделать (и на этот раз “все” действительно означает, что это уже все), — это (1) добавить перегрузку конструктора Personдля обработки целочисленных аргументов и (2) сильнее ограничить шаблонный конструктор так, чтобы он был отключен для таких аргументов. Положите эти ингредиенты в кастрюлю со всем остальным, что мы уже обсуждали, варите на медленном огне и наслаждайтесь ароматом успеха:

class Person {

public:

template<

typename T,

typename = std::enable_if_t<

!std::is_base_of>::value

&&

!std::is_integral>::value

>

>

explicit Person(T&& n) // Конструктор для std::string и

: name(std::forward(n)) // аргументов, приводимых к

{ … } // std::string

explicit Person(int idx) // Конструктор для

: name(nameFromIdx(idx)) // целочисленных аргументов

{ … }

… // Копирующий и перемещающий конструкторы и т.д.

private:

std::string name;

};

Красота! Ну ладно, красота в основном для тех, кто фетишизирует метапрограммирование с использованием шаблонов, но факт остается фактом: этот подход не только справляется с работой, но и делает это с чрезвычайным апломбом. Применение прямой передачи предполагает высокую эффективность, а управление сочетанием универсальных ссылок и перегрузки вместо их запрета позволяет применять этот метод в обстоятельствах (таких, как разработка конструкторов), когда перегрузка неизбежна.

Первые три рассмотренные в данном разделе метода — отказ от перегрузки, передача const T&и передача по значению — указывают тип каждого параметра в вызываемой функции или функциях. Последние два метода — диспетчеризация дескрипторов и ограничения шаблонов — используют прямую передачу, а следовательно, типы параметров не указывают. Это фундаментальное решение — указывать типы или нет — имеет свои следствия.

Как правило, прямая передача более эффективна, потому что позволяет избежать создания временных объектов исключительно с целью соответствия типу объявления параметра. В случае конструктора Personпрямая передача допускает передачу строкового литерала, такого как "Nancy", непосредственно в конструктор для std::stringвнутри Person, в то время как методы, не использующие прямой передачи, вынуждены создавать временный объект std::stringиз строкового литерала для удовлетворения спецификации параметра конструктора Person.