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

! Это чудное ощущение дежавю раздела 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& и передача по значению — указывают тип каждого параметра в вызываемой функции или функциях. Последние два метода — диспетчеризация дескрипторов и ограничения шаблонов — используют прямую передачу, а следовательно, типы параметров не указывают. Это фундаментальное решение — указывать типы или нет — имеет свои следствия.

Как правило, прямая передача более эффективна, потому что позволяет избежать создания временных объектов исключительно с целью соответствия типу объявления параметра. В случае конструктора