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

Но прямая передача имеет свои недостатки. Один из них тот, что некоторые виды аргументов не могут быть переданными прямой передачей, несмотря на то что они могут быть переданы функциям, принимающим конкретные типы. Эти сбои прямой передачи исследуются в разделе 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.1 говорилось, что, когда аргумент передается в шаблонную функцию, выведенный для параметра шаблона тип указывает, является ли аргумент lvalue или rvalue. В разделе не было упомянуто, что это происходит только тогда, когда аргумент используется для инициализации параметра, являющегося универсальной ссылкой, но тому есть уважительная причина: универсальные ссылки появились только в разделе 5.2. Вместе эти наблюдения об универсальных ссылках и кодировании lvalue/rvalue означают, что для шаблона

template

void func(T&& param);

выведенный параметр шаблона Tбудет включать информацию о том, был ли переданный в paramаргумент lvalue или rvalue.

Механизм этого кодирования прост. Если в качестве аргумента передается lvalue, Tвыводится как lvalue-ссылка. При передаче rvalue вывод типа приводит к тому, что Tне является ссылкой. (Обратите внимание: lvalue кодируются как lvalue-ссылки, но rvalue кодируются как не ссылки .) Следовательно:

Widget widgetFactory(); // Функция, возвращающая rvalue

Widget w; // Переменная (lvalue)

func(w); // Вызов функции с lvalue; тип T

// представляет собой Widget&

func(widgetFactory()); // Вызов функции с rvalue; тип T

// представляет собой Widget

В обоих вызовах funcпередается Widget, но так как один Widgetявляется lvalue, а второй представляет собой rvalue, для параметра шаблона Tвыводятся разные типы. Это, как вы вскоре увидите, и определяет, чем становятся универсальные ссылки: rvalue- или lvalue-ссылками; а кроме того, это механизм, лежащий в основе работы std::forward.

Прежде чем более внимательно рассмотреть std::forwardи универсальные ссылки, мы должны заметить, что ссылка на ссылку в С++ не существует. Попытайтесь объявить ее, и компилятор вынесет вам строгий выговор:

int x;

…

auto & &rx = x; // Ошибка! Объявлять ссылки на ссылки нельзя

Но рассмотрим, что произойдет, если передать lvalue шаблону функции, принимающему универсальную ссылку:

template

void func(T&& param); // Как и ранее

func(w); // Вызов func с lvalue;