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

{

logAndAddImpl(std::forward(name),

std::is_integral()); // Не совсем корректно

}

Эта функция передает свой параметр в logAndAddImplи при этом передает также аргумент, указывающий, является ли тип параметра ( T) целочисленным. Как минимум это то, что она должна делать. То же самое она делает и для целочисленных аргументов, являющихся rvalue. Но, как поясняется в разделе 5.6, если lvalue-аргумент передается универсальной ссылке name, то выведенный тип для Tбудет lvalue-ссылкой. Так что если в функцию logAndAddпередается lvalue типа int, то тип Tбудет выведен как int&. Но это не целочисленный тип — ссылка таковым не является. Это означает, что std::is_integralбудет иметь ложное значение для любого lvalue-аргумента, даже если этот аргумент на самом деле является целочисленным значением.

Понимание данной проблемы равносильно ее решению, поскольку в стандартной библиотеке имеется такое средство, как std::remove_reference(см. раздел 3.3), которое делает то, о чем говорит его имя и в чем мы так нуждаемся: удаляет любые квалификаторы ссылок из типа. Так что верный способ написания logAndAddимеет следующий вид:

template

void logAndAdd(T&& name) {

logAndAddImpl(

std::forward(name), std::is_integral<

typename std::remove_reference::type

>()

);

}

Это в определенной мере трюк. (Кстати, в С++14 можно сэкономить несколько нажатий клавиш, воспользовавшись вместо выделенного текста std::remove_reference_t. Подробнее об этом рассказывается в разделе 3.3.)

После принятия этих мер мы можем перенести наше внимание к вызываемой функции, logAndAddImpl. Имеются две перегрузки, первая из которых применима к любому нецелочисленному типу (т.e. ко всем типам, для которых значение std::is_integral::type>ложно):

// Нецелочисленный аргумент добавляется

// в глобальную структуру данных: template

void logAndAddImpl(T&& name, std::false_type) {

auto now = std::chrono::system_clock::now();

log(now, "logAndAdd");

names.emplace(std::forward(name));

}

Этот код прост, если вы понимаете механику, лежащую в основе выделенного параметра. Концептуально logAndAddпередает в функцию logAndAddImplбулево значение, указывающее, передан ли функции logAndAddцелочисленный тип, но значения trueи falseявляются значениями времени выполнения, а нам для выбора верной версии logAndAddImplнеобходимо разрешение перегрузки, т.e. явление времени компиляции . Это означает, что нам нужен тип , соответствующий значению true, и другой тип, соответствующий значению false. Такая необходимость — настолько распространенное явление, что стандартная библиотека предоставляет то, что нам нужно, под именами std::true_typeи std::false_type. Аргумент, передаваемый в logAndAddImplфункцией logAndAdd, является объектом типа, унаследованного от std::true_type, если T — целочисленный тип, и от std::false_type, если Tтаковым не является. Конечный результат заключается в том, что эта перегрузка logAndAddImplявляется реальным кандидатом для вызова в logAndAdd, только если Tне является целочисленным типом.

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

std::string nameFromIdx(int idx); // Как в разделе 5.4

// Целочисленный аргумент: поиск имени и

// вызов с этим именем функции logAndAdd:

void logAndAddImpl(int idx,, std::true_type) {

logAndAdd(nameFromIdx(idx));

}

Наличие функции logAndAddImplдля поиска по индексу соответствующего имени и передача его функции logAndAdd(откуда оно будет передано с помощью std::forwardдругой перегрузке функции logAndAddImpl) позволяет избежать размещения кода для записи в журнале в обеих перегрузках logAndAddImpl.

В таком решении типы std::true_typeи std::false_typeявляются “дескрипторами”, единственная цель которых — обеспечить разрешение перегрузки требующимся нам способом. Обратите внимание, что нам даже не нужны эти параметры. Они не служат никакой цели во время выполнения, и мы фактически надеемся, что компиляторы распознают, что параметры дескрипторов не используются, и соответствующим образом оптимизируют выполнимый образ программы. (Некоторые компиляторы так и поступают, по крайней мере иногда.) Вызов перегруженных функций реализации в logAndAdd“диспетчеризует” передачу работы правильной перегрузке путем создания нужного объекта дескриптора. Отсюда и название этого метода проектирования: диспетчеризация дескрипторов . Это стандартный строительный блок шаблонного метапрограммирования, и чем больше вы будете просматривать код внутри современных библиотек С++, тем чаще вы будете с ним сталкиваться.

Для наших целей важно не столько то, как работает диспетчеризация дескрипторов, сколько как она позволяет комбинировать универсальные ссылки и перегрузку без проблем, описанных в разделе 5.4. Функция диспетчеризации — logAndAdd— принимает параметр, являющийся неограниченной универсальной ссылкой, но эта функция не перегружается. Перегружается функция реализации — logAndAddImpl, — которая принимает параметр, представляющий собой универсальную ссылку, но разрешение вызова этой функции зависит не только от параметра универсальной ссылки, но и от параметра дескриптора, а значения дескрипторов спроектированы таким образом, чтобы было не более одной совпадающей перегрузки. В результате то, какая из перегрузок будет вызвана, определяется дескриптором. Тот факт, что параметр, представляющий собой универсальную ссылку, всегда генерирует точное соответствие своему аргументу, значения не имеет.

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

По правде говоря, реальная проблема не в том, что генерируемые компиляторами функции иногда обходят диспетчеризацию дескрипторов; на самом деле она в том, что они не всегда ее обходят. Вы практически всегда хотите, чтобы копирующий конструктор класса обрабатывал запрос на копирование lvalue этого типа, но, как показано в разделе 5.4, предоставление конструктора, принимающего универсальную ссылку, приводит к тому, что при копировании неконстантных lvalue вызывается конструктор с универсальной ссылкой, а не копирующий конструктор. В этом разделе также поясняется, что когда базовый класс объявляет конструктор с прямой передачей, именно этот конструктор обычно вызывается при традиционной реализации производным классом копирующего и перемещающего конструкторов, несмотря на то что корректным поведением является вызов копирующих и перемещающих конструкторов.