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

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

Но прямая передача имеет свои недостатки. Один из них тот, что некоторые виды аргументов не могут быть переданными прямой передачей, несмотря на то что они могут быть переданы функциям, принимающим конкретные типы. Эти сбои прямой передачи исследуются в разделе 5.8.

Второй неприятностью является запутанность сообщений об ошибках, когда клиенты передают недопустимые аргументы. Предположим, например, что клиент, создающий объект Person, передает строковый литерал, составленный из символов char16_t (тип С++11 для представления 16-разрядных символов) вместо char (из которых состоит std::string):

Person p(u"Konrad Zuse"); // "Konrad Zuse" состоит из
                          // символов типа const char16_t

При использовании первых трех из рассмотренных в данном разделе подходов компиляторы увидят, что доступные конструкторы могут принимать либо int, либо std::string, и выведут более или менее понятное сообщение об ошибке, поясняющее, что не существует преобразования из const char16_t[12] в int или std::string.

Однако при подходе с использованием прямой передачи массив const char16_t связывается с параметром конструктора без замечаний и жалоб. Оттуда он передается конструктору члена-данных типа std::string класса Person, и только в этот момент обнаруживается несоответствие между тем, что было передано (массив const char16_t), и тем, что требовалось (любой тип, приемлемый для конструктора std::string). В результате получается впечатляющее сообщение об ошибке. Так, в одном из компиляторов оно состояло более чем из 160 строк!

В этом примере универсальная ссылка передается только один раз (из конструктора Person в конструктор std::string), но чем более сложна система, тем больше вероятность того, что универсальная ссылка передается через несколько слоев вызовов функций до того, как достигнет точки, в которой определяется приемлемость типа аргумента (или типов). Чем большее количество раз будет передаваться универсальная ссылка, тем более непонятными и громоздкими будут выглядеть сообщения об ошибках, если что-то пойдет не так. Многие разработчики считают, что одно это является основанием для применения универсальных ссылок только там, где особенно важна производительность.

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

class Person {
public:
 template< // Как и ранее
  typename T,
  typename = std::enable_if_t<
   !std::is_base_of>::value
   &&
   !std::is_integral>::value
  >
 >
 explicit Person(T&& n)
 : name(std::forward(n)) {
  // Проверка возможности создания std::string из T
  static_assert(
   std::is_constructible::value,
   "Параметр n не может использоваться для "
   "конструирования std::string"
  };
  … // Здесь идет код обычного конструктора
 }

 …  // Остальная часть класса Person (как ранее)
};

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

Следует запомнить

• Альтернативы комбинации универсальных ссылок и перегрузки включают использование различных имен, передачу параметров как lvalue-ссылок на const, передачу параметров по значению и использование диспетчеризации дескрипторов.

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

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

5.6. Свертывание ссылок

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