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

В разделе 5.4 поясняется, что перегрузка для универсальных ссылок может привести к целому ряду проблем как для автономных функций, так и для функций-членов (в особенности для конструкторов). Тем не менее в нем также приводятся примеры, когда такая перегрузка может оказаться полезной, если только она будет вести себя так, как мы хотим! В этом разделе исследуются способы достижения желаемого поведения либо путем проектирования, позволяющего избежать перегрузок для универсальных ссылок, либо путем применения их таким образом, чтобы ограничить типы аргументов, которым они могут соответствовать.

Ниже использованы примеры, представленные в разделе 5.4. Если вы читали его давно или вовсе не читали, просмотрите указанный раздел, прежде чем читать данный.

В первом примере раздела 5.4 функция logAndAddявляется типичным представителем функций, которые могут избежать недостатков перегрузки для универсальных ссылок, просто используя разные имена для потенциальных перегрузок. Например, рассматривавшиеся перегрузки logAndAddмогут быть разделены на logAndAddNameи logAndAddNameIdx. Увы, этот подход не будет работать для второго рассматривавшегося примера — конструктора Person, потому что имена конструкторов в языке зафиксированы. Кроме того, кто же захочет отказаться от перегрузки?

Одной из альтернатив является возврат к С++98 и замена передачи универсальной ссылки передачей lvalue-ссылки на const. Фактически это первый подход, рассматривавшийся в разделе 5.4. Его недостаток состоит в том, что данный дизайн не столь эффективен, как нам хотелось бы. С учетом всех нынешних наших знаний о взаимодействии универсальных ссылок и перегрузки отказ от некоторой эффективности в пользу простоты может оказаться более привлекательными компромиссом, чем нам казалось изначально.

Подход, который часто позволяет добиться производительности без увеличения сложности, заключается в замене передачи параметров по ссылке передачей по значению, как бы противоестественно это ни звучало. Этот дизайн основан на совете из раздела 8.1: рассмотреть вопрос о передаче объектов по значению в случае, когда известно, что они будут копироваться. Поэтому я отложу до указанного раздела подробное обсуждение того, как все это работает и насколько эффективным является это решение. Здесь я просто покажу, как этот подход может использоваться в примере с классом Person:

class Person {

public:

explicit Person( std::stringn) // Замена конструктора с T&&

: name(std::move(n)) {} // о применении std::move

// читайте в разделе 8.1

explicit Person(int idx) // Как и ранее

: name(nameFromIdx(idx)) {}

…

private:

std::string name;

};

Поскольку конструктора std::string, принимающего только целочисленное значение, нет, все аргументы типа intи подобных ему (например, std::size_t, short, long), передаваемые конструктору Person, будут перенаправлены к перегрузке для int. Аналогично все аргументы типа std::string(а также аргументы, из которых могут быть созданы объекты std::string, например литералы наподобие "Ruth") будут передаваться конструктору, принимающему std::string. Здесь для вызывающего кода нет никаких сюрпризов. Возможно, некоторые программисты будут удивлены, что применение 0или NULLв качестве нулевого указателя приведет к вызову перегрузки для int, но таким программистам необходимо внимательно прочесть раздел 3.2 и читать его до полного просветления в данном вопросе.

Ни передача lvalue-ссылки на const, ни передача по значению не предоставляют поддержку прямой передачи. Если мотивом использования универсальной ссылки является прямая передача, мы вынуждены использовать универсальную ссылку; у нас просто нет иного выбора. Тем не менее мы не хотим отказываться и от перегрузки. Если мы не отказываемся ни от перегрузок, ни от универсальных ссылок, то как же мы сможем избежать перегрузки для универсальных ссылок?

В действительности это не так трудно. Вызовы перегруженных функций разрешаются путем просмотра всех параметров всех перегрузок, а также всех аргументов в точке вызова с последующим выбором функции с наилучшим общим соответствием — с учетом всех комбинаций “параметр/аргумент”. Параметр, являющийся универсальной ссылкой, обычно обеспечивает точное соответствие для всего, что бы ни было передано, но если универсальная ссылка является частью списка параметров, содержащего другие параметры, универсальными ссылками не являющиеся, достаточно плохое соответствие этих последних параметров может привести к отказу от вызова такой перегрузки. Эта идея лежит в основе подхода диспетчеризации дескрипторов (tag dispatch), а приведенный ниже пример позволит лучше понять, о чем идет речь.

Применим этот метод к примеру logAndAddиз третьего фрагмента кода раздела 5.4. Чтобы вам не пришлось его искать, повторим его здесь:

std::multiset names; // Глобальная структура данных

template // Делает запись в журнале и

void logAndAdd(T&& name) // добавляет name в names

{

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

log(now, "logAndAdd");

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

}

Сама по себе эта функция работает отлично, но если мы добавим перегрузку, принимающую значение типа int, использующееся для поиска объекта по индексу, то получим проблемы, описанные в разделе 5.4. Цель данного раздела — их избежать. Вместо добавления перегрузки мы реализуем logAndAddзаново для делегирования работы двум другим функциям: одной — для целочисленных значений, а другой — для всего прочего. Сама функция logAndAddбудет принимать все типы аргументов, как целочисленные, так и нет.

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

Что вы говорите? “Хватит трепа, переходи к делу”? Да хоть сию секунду! Вот почти корректная версия обновленной функции logAndAdd:

template

void logAndAdd(T&& name)