C++ сложный и интересный язык, совершенствоваться в нем можно чуть ли не всю жизнь. В какой-то момент мне захотелось изучать его следующим образом: взять какой-то аспект языка, возможно довольно узкий, и разобраться с ним максимально глубоко и подробно. Такой подход в значительной степени был стимулирован замечательными книгами Скотта Мейерса, Герба Саттера и Стефана Дьюхэрста. Когда накопилось определенное количество материалов, решил познакомить с ними Хабровчан. Так появилась эта серия, которую я назвал «C++, копаем вглубь». Серия помечена как Tutorial, но ориентирована она все-таки не на начинающих, а скорее на intermediate уровень. Первая тема — это перегрузка в C++. Тема оказалась очень обширной и получилось три статьи. Первая статья посвящена перегрузке функций и шаблонов, вторая перегрузке операторов и третья перегрузке операторов new/delete. Итак, начнем копать.
   Введение
  1. Общие положения
    1.1. Перегруженные функции
    1.2. Общая схема алгоритма поиска функции
    1.3. Текущая область видимости и разрешение перегрузки во вложенных областях видимости
      1.3.1. Выбор текущей области видимости
      1.3.2. Разрешение перегрузки в классах
      1.3.3. Локальное объявление функций
    1.4. Расширение области видимости для разрешения перегрузки
      1.4.1. Использования using-объявления в классе
      1.4.2. Использования using-объявления локально и в пространстве имен
      1.4.3. Использования using-директивы
      1.4.4. Поиск, зависимый от типа аргументов
  2. Некоторые правила разрешения перегрузки
    2.1. Неявные преобразования типа и параметры «близкого» типа
    2.2. Нулевой указатель
    2.3. Универсальная инициализация и списки инициализации
    2.4. Функции с переменным числом параметров
    2.5. Шаблоны функций
      2.5.1. Общие правила перегрузки
      2.5.2. Принцип SFINAE
      2.5.3. Пример разрешения перегрузки
      2.5.4. Управление перегрузкой шаблонов
    2.6. Правила разрешения перегрузки для параметров «родственного» типа
      2.6.1. Передача параметров по ссылке, ссылке на константу и по значению
      2.6.2. Rvalue ссылки
      2.6.3. Универсальные ссылки
  3. Другие темы, связанные с перегрузкой
    3.1. Параметры неполного типа
    3.2. Инициализация указателя на функцию
    3.3. Перегрузка и параметры по умолчанию
    3.4. Перегрузка виртуальных функций
    3.5. Метапрограммирование
  4. Итоги
  Приложения
    Приложение А. Двойная диспетчеризация и паттерн Visitor
    Приложение Б. Подмена стандартных функций пользовательскими версиями
  Список литературы
 В широком смысле перегрузка (overloading) — это возможность одновременно использовать несколько функций с одним именем. Компилятор различает их благодаря тому, что они имеют разный набор параметров. В точки вызова компилятор анализирует типы аргументов и определяет, какая конкретно функция должна быть вызвана. В русскоязычной литературе иногда можно встретить термин «совместное использование», но, похоже, он не прижился.
 Перегрузка поддерживается многими языками программирования, мы будем рассматривать только C++17.
 Функции (а также шаблоны функций) называются перегруженными (overloaded), если они объявлены в одной области видимости (scope) и имеют одно и то же имя. Перегруженные функции не могут иметь разные типы возвращаемого значения, спецификатор исключений или спецификатор удаленной функции (=delete) при одинаковых параметрах.
 Но несколько идентичных объявлений допустимы, компилятор просто игнорирует копии.
 Также надо учитывать, что компилятор выполняет некоторые стандартные преобразования типов параметров функций. Для типа массива выполняется сведение (decay) к указателю, поэтому
 не перегруженные функции, это одно и то же.
 Параметры типа функция сводятся к указателю на функцию.
 Для параметров, передаваемых по значению, удаляется квалификатор const (и volatile), поэтому
 не перегруженные функции, это одно и то же.
 В общих чертах алгоритм поиска функции можно описать следующим образом. На первом этапе компилятор осуществляет поиск (lookup) тех перегруженных функций, которые по правилам языка допустимы для данного вызова (candidate functions). В случае шаблонов выполняется еще вывод аргументов шаблона (template argument deduction). У этих функций количество параметров должно совпадать с количеством аргументов и тип аргументов должен совпадать с типом параметров (или существовать неявное преобразование типа аргументов к типу параметров). Если таких функций не найдено, поиск завершается ошибкой. Если найдена ровно одна функция, то поиск завершается успешно. Если найдено несколько функций, то начинается следующий этап, компилятор пытается выбрать ту, которая подходит «лучше всего» для данных аргументов (match the arguments most closely). Этот этап называется разрешением перегрузки (overload resolution). Если такая функция найдена, то разрешение перегрузки завершается успешно, иначе возникает ошибка (ambiguous call to overloaded function). Рассмотрим пример:
 Для вызова Foo("meow") ни одной подходящей функции не найдено, для вызова Foo(42) подходят обе функции, компилятор не может выбрать наиболее подходящую, а вот вызовы Foo(3.14f) и Foo(3.14) разрешаются успешно.
 Правила выбора наиболее подходящей функции (overload resolution rules) при попытке полного и формального описания могут оказаться весьма сложными и запутанными (это из тех вещей, которые до конца знают только разработчики компилятора), но как это часто бывает, во многих практически значимых случаях они являются интуитивно понятными и особых проблем у программиста не вызывают. Часть из них будет описана ниже.
 Обычно термином «разрешение перегрузки» удобно описывать обе фазы: поиск функций-кандидатов и выбор наиболее подходящей функции. В дальнейшем мы будем придерживаться этого соглашения.
 Но успешное разрешение перегрузки — это еще не все. После разрешения перегрузки производится проверка на доступность выбранной функции в точке вызова (то есть не является ли она private или protected). В случае успеха производится проверка на удаленность (то есть не объявлена ли она как =delete). Если эти проверки не проходят, компиляция завершается с ошибкой. Обратим внимание на то, что эти проверки никак не влияют на процедуру разрешения перегрузки, они всегда выполнятся после.
 Как уже отмечалось выше, перегруженные функции по определению находятся в одной области видимости. Области видимости вложены друг в друга. Области видимости, определяемые пространствами имен могут быть вложены друг в друга. Любое пространство имен вложено в глобальное пространство имен. Область видимости производного класса вложена в области видимости базовых классов, которые, в свою очередь, вложены в область видимости пространства имен. Локальные области видимости (блоки) вложены в другие блоки и далее в область видимости класса или пространства имен.
 При разрешении перегрузки компилятор прежде всего должен выбрать область видимости, в которой и будет выполнятся разрешение перегрузки. Такая область видимости называется текущей. Если в текущей области видимости нет ни одной функции с искомым именем, текущей областью видимости становится объемлющая область видимости. Но, если в текущей области видимости найдена хотя бы одна функция с искомым именем, то выполняется разрешение перегрузки в данной области видимости и объемлющая область видимости рассматриваться не будет. Функции из текущей области видимости будут скрывать (hide) одноименные функции из объемлющих областей видимости. Подчеркнем, что это не зависит от результата разрешения перегрузки, подходящая функция может быть не найдена, оказаться неоднозначной, недоступной или удаленной, все равно продолжения поиска в объемлющей области видимости не будет.
 Первоначальная текущая область видимости и возможные объемлющие области видимости, в которые может осуществляться переход для разрешения перегрузки, определяется контекстом в точке вызова функции. Приведем примеры.
 В этих случаях первоначальной текущей областью видимости будет класс X. Объемлющие области видимости ограничены базовыми классами X.
 В этом случае первоначальной текущей областью видимости будет пространство имен N, переход в объемлющие области вообще не выполняется.
 В этом случае первоначальной текущей областью видимости будет глобальное пространство имен, объемлющих областей видимости нет.
 Рассмотрим теперь «голые» вызовы функций без дополнительных квалификаторов класса или пространства имен.
 Если такой вызов находится в пространстве имен, то это пространство имен и будет первоначальной текущей областью видимости, объемлющими областями видимости будут объемлющие пространства имен.
 Если такой вызов находится в пространстве имен класса (например при инициализации статического члена), то соответствующий класс будет первоначальной текущей областью видимости, объемлющими областями видимости будут базовые классы и далее объемлющие пространства имен.
 Пусть такой вызов находится в блоке
 В этом случае первоначальной текущей областью видимости будет этот блок. (Напомним, что возможны локальные объявления функций, подробнее см. далее.) Объемлющими областями видимости будут объемлющие блоки, далее класс (если блок находится в функции-члене) и далее объемлющие пространства имен.
 Рассмотрим пример.
 Какая из двух доступных Foo, будет выбрана? Правильный ответ D::Foo(double), хотя B::Foo(int) подходит лучше и доступна в точке вызова. Поиск начинается с текущей области видимости (в данном случае класс D), найдена функция с соответствующим именем, объемлющая область видимости (в данном случае класс B) не рассматривается. Единственная найденная функция D::Foo(double) может быть вызвана с данным аргументом и разрешение перегрузки завершается успешно. Если бы D::Foo(double) была бы объявлена закрытой или защищенной или удаленной, то компиляция завершилась бы ошибкой, но B::Foo(int) все равно бы не рассматривалась, хотя она и доступна в точке вызова. И только, если из класса D совсем убрать Foo, то компилятор сделал бы текущей областью видимости класс B и выбрал бы B::Foo(int).
 Эти правила могут оказаться достаточно неожиданными для программиста. Наследование в C++ спроектировано так, чтобы сделать границу между производным и базовым классом максимально прозрачной, а в данном случае такой прозрачности нет. При неблагоприятных условиях это может привести к трудно обнаруживаемым ошибкам. Например, можно получить бесконечную рекурсию. (Но это еще не худший вариант, такая ошибка сразу обнаружится при выполнении.)
 Рассмотрим теперь одну редко используемую особенность C++, которая называется локальные объявления функций. Функции можно объявлять локально (в блоке), например:
 Функции, объявленные локально, должны быть определены в глобальном пространстве имен, локальные определения в C++ не разрешены. Если функция вызывается в блоке без дополнительных квалификаторов класса или пространства имен, то текущей областью видимости, в которой происходит разрешение перегрузки, будет этот блок. Если в блоке есть локальные объявления функций, то одноименные функции из объемлющих областей видимости будут скрыты. Если в блоках нет локальных объявлений функций (что обычно и бывает), то текущая область видимости переместится в конце концов в класс (если блок находится в функции-члене класса) и далее в объемлющие пространства имен.
 Область видимости для разрешения перегрузки можно расширить с помощью using-объявления и using-директивы. Также, в определенном случае, компилятор самостоятельно расширяет область видимости для разрешения перегрузки.
 Следует обратить внимание, на то, что расширение области видимости может вызвать конфликты, например, если в расширенную область видимости добавляются функции с таким же набором параметров, как и в текущей.
 Вот как это делается для предыдущего примера:
 После этого в разрешении перегрузки будут участвовать перегруженные Foo из области видимости класса B, и компилятор выберет B::Foo(int).
 Использовать using-объявление с использованием имени класса можно только в области видимости производного класса, как показано в предыдущем разделе. Локально или в области видимости пространства имен можно использовать using-объявления с использованием имени пространства имен. Но надо быть внимательным, так как такое объявление будет скрывать соответствующие имена из объемлющей области видимости и, если неудачно выбрать область видимости для размещения using-объявления, то можно получить не расширение, а нежелательное изменение области видимости для разрешения перегрузки. Пример:
 В данном случае, для того чтобы обе версии Foo участвовали в разрешении перегрузки, using-объявление надо размещать так:
 Пусть у нас есть некоторое пространство имен N. Инструкция
 называется using-директивой. В области ее видимости можно использовать имена из пространства имен N без квалификатора N::. При разрешении перегрузки также будут участвовать функции из N, то есть using-директива приводит к расширению области видимости для разрешения перегрузки (и, в отличии от using-объявления, ничего не скрывает). Но, вообще, к using-директиве надо относиться весьма осторожно, об этом написано немало.
 Если используется анонимное пространство имен, то функции, объявленные в нем, будут участвовать в разрешении перегрузки вместе с одноименными функциями, объявленными в объемлющем пространстве имен. (Фактически анонимное пространство имен доступно через скрытую using-директиву.)
 Есть одна ситуация, когда компилятор самостоятельно расширяет текущую область видимости для разрешения перегрузки. Рассмотрим объявление класса и функции в некотором пространстве имен:
 Рассмотрим код (вне пространства имен N):
 В этом случае при разрешении перегрузки компилятор подключит пространство имен N и, если не будет конфликта с текущей областью видимости, будет выбрана N::Foo(const X&). Это и называется поиском, зависимым от типа аргументов (argument depended lookup, ADL), называемый еще поиском Кёнига. ADL играет важную роль при перегрузке операторов, функций стандартной библиотеки и в других случаях.
 В данном разделе рассматриваются более специальные правила разрешения перегрузки, применяемые в особых случаях.
 В C++ довольно много неявных преобразований типа. Это в определенных ситуациях может привести к проблемам, в том числе создавать неоднозначность при разрешении перегрузки. Но тем не менее при разрешении перегрузки типы, преобразующиеся в друг друга с помощью неявных преобразований, различаются. Общее правило такое: вариант, не требующий преобразований, имеет приоритет.
 Одним из проблемных типов является bool. Для совместимости с С существует неявное преобразование bool в int и неявное преобразование любого числового типа и указателя в bool. Это может породить много трудно обнаруживаемых ошибок. Но в простых случаях при разрешении перегрузки bool четко отделяется от int.
 Но для таких перегруженных функций
 неоднозначный вызов уже сделать легче, вот пример:
 Определенные проблемы также доставляют перечисления, тип перечисления неявно преобразуется в целочисленные типы. При перегрузке тип перечисления может четко отделятся от int.
 Семантически и побитово совпадающие типы, например, int и long также различаются при разрешении перегрузки.
 Иногда при разрешении перегрузки желательно исключить некоторые неявные преобразования. В этом случае можно воспользоваться удаленными функциями. Предположим мы хотим иметь функции, которые можно вызывать для целочисленных аргументов, но нельзя вызывать для аргументов плавающего типа. Это можно сделать так:
 В C++11 был введен новый тип — std::nullptr_t с единственным значением nullptr. Это позволило избежать потенциальных проблем связанных с неявным преобразованием литерального нуля к типу указателя.
 В C++98 приходилось писать
 Но это еще не все преимущества. Так как nullptr имеет свой собственный тип, можно перегружать функции по значению nullptr.
 Подобные перегрузки используются в интерфейсе стандартных интеллектуальных указателей.
 В С++11 появилась концепция универсальной инициализации (uniform initialization) с использованием фигурных скобок и добавлен новый шаблон — std::intializer_list<>. Как это часто бывает, возникли некоторые неоднозначности, которые пришлось устранять с помощью дополнительных правил. По существу эти правила относятся к правилам разрешения перегрузки для конструкторов. Вот эти правила.
 Рассмотрим несколько примеров для стандартного вектора std::vector<T>, который имеет конструктор с параметром типа std::intializer_list<T>.
 Вот первый пример:
 В этом случае v1 — это вектор размера 3 с элементами равными 1. v2 — это вектор размера 2 с элементами равными 3 и 1, выбирается конструктор с параметром типа std::intializer_list<int>, хотя есть и другой конструктор, принимающий элементы списка.
 Другой пример:
  В этом случае u1 и u2 одинаковы, векторы размера 3. Для u2 элементы списка не подходят для конструктора с параметром типа std::intializer_list<const char*> и поэтому выбирается конструктор тот же, что и для u1.
 И третий пример:
 В этом случае b1 вектор размера 3 с элементами, равными true. А вот b2 не компилируется, так как для конструктора с параметром типа std::intializer_list<bool> требуется сужающее преобразование от int к bool.
 Подробнее про универсальную инициализацию можно почитать у Скотта Мейерса [Meyers2].
 Функция с переменным числом параметров, то есть имеющая ... в конце списка параметров, как кандидат на разрешение перегрузки всегда будет рассматриваться только в тех случаях, когда нет ни одной подходящей функции с постоянным числом параметров. Наличие хотя бы одной подходящий функции с постоянным числом параметров исключает функцию с переменным числом параметров из кандидатов на разрешение перегрузки.
 Напомним, что шаблоны функций могут иметь полную специализацию для некоторого шаблонного аргумента, но не могут иметь частичных специализаций. Вместо частичной специализации используется перегруженный шаблон — одноименный шаблон функции c другими параметрами.
 Шаблоны функций и их полные специализации могут участвовать в перегрузке вместе с нешаблонными функциями. Полные специализации шаблонов участвуют в перегрузке довольно специфическим образом (можно даже говорить, что они в перегрузке не участвуют), детали изложены ниже.
 При разрешении перегрузки сначала рассматриваются нешаблонные функции и конкретизации шаблонов. В первую очередь рассматриваются варианты точного совпадения типов аргументов и параметров, то есть варианты не требующие неявных преобразований типов аргументов. Если таких вариантов насколько, то приоритет имеют нешаблонные функции. Если нешаблонная функция не выбрана, то среди конкретизаций шаблонов приоритет будут иметь более специализированные шаблоны.
 Если выбрана конкретизация шаблона, то проверяется, нет ли полной специализации этого шаблона для выведенного типа аргумента конкретизации. Если такая специализация есть, то выбирается она. Обратим внимание на то, что полные специализации рассматриваются в последнюю очередь, после выбора шаблона. Подробнее про описанный алгоритм разрешения перегрузки можно почитать у Герба Саттера [Sutter2].
 В C++11 появились шаблоны с переменным количеством параметров или вариативные шаблоны (variadic templates). Если для некоторого вызова допустимыми являются конкретизации вариативного шаблона и обычного, то последний всегда будет считаться более специализированным и, соответственно, выбран при разрешении перегрузки.
 Если у нас есть шаблон функции, то может возникнуть ситуация, когда для некоторого вызова компилятор не сможет вывести тип аргумента шаблона. Вот пример:
 В этом случае, если в текущей области видимости есть перегруженные шаблоны, для которых аргументы выведены успешно, или перегруженные нешаблонные функции, то ошибки не возникает, такой шаблон просто «молча» исключается из разрешения перегрузки. Это и называется принципом SFINAE, который расшифровывается как Substitution Failure is not an Error (сбой при подстановке не является ошибкой).
 Рассмотрим пример перегруженных функций, шаблонов и полных специализаций шаблонов. Посмотрим, как в соответствии с описанными выще правилами разрешается перегрузка для следующих вызовов:
 В первом вызове есть точно подходящая нешаблонная функция и одна точно подходящая конкретизация: шаблон 1 для int. Выбирается нешаблонная функция.
 Во втором вызове нешаблонная функция подходит не точно, требуется преобразование от double к int. Есть одна точно подходящая конкретизация: шаблон 1 для double и есть полная специализация шаблона 1 для double, которая и выбирается.
 В третьем вызове нешаблонная функция подходит не точно, требуется преобразование от long к int. Есть одна точно подходящая конкретизация: шаблон 1 для long, она и выбирается.
 В четвертом вызове нешаблонная функция совсем не подходит, есть две точно подходящих конкретизации: шаблон 1 для const char* и шаблон 2 для char. Выбирается шаблон 2 как более специализированный и, соответственно, полная специализация шаблона 1 для const char* не рассматривается.
 В пятом вызове нешаблонная функция совсем не подходит, есть две точно подходящих конкретизации: шаблон 1 для U<int> и шаблон 3 для int. Выбирается шаблон 3 как более специализированный.
 Рассмотрим перегруженные функции и шаблоны:
 Нешаблонная функция будет выбрана только для аргументов типа int, int&, const int, const int&, для остальных целочисленных аргументов (long, short, unsigned int, etc.) будет выбрана шаблонная версия. В такой ситуации говорят, что шаблонная версия является жадной (greedy). Это не всегда является нужным поведением, например, часто желательно, чтобы первая функция выбиралась для всех целочисленных аргументов. Решить эту задачу можно несколькими способами. Можно добавить перегруженные функции для всех целочисленных типов, но это весьма утомительно. Другой вариант — использовать технику отключения шаблонов (template disabling). Для этого шаблон надо переписать в следующем виде:
 Теперь для целочисленных аргументов этот шаблон нельзя конкретизировать и в соответствии с принципом SFINAE он будет исключен при разрешении перегрузки и, таким образом, будет выбрана нешаблонная функция и выполнены необходимые неявные преобразования аргументов.
 Ну и, наконец, варианты с использованием условных инструкций и операторов, вообще без использования перегрузки:
 Описанные варианты требуют включения заголовочного файла <type_traits>.
 В данном разделе мы рассмотрим правила перегрузки в случаях когда параметры функций имеют «родственные» типы: сам тип, ссылка, ссылка на константу, rvalue ссылка.
 Для описания этих правил необходимо использовать так называемые категории аргументов. Для нашего уровня детализации достаточно использовать четыре категории:
 Обе константные категории часто можно рассматривать как единую категорию — константы.
 Рассмотрим теперь, допустимые категории аргументов для рассматриваемых типов параметров.
Пусть параметр имеет тип ссылки:
 В этом случае допустимой категорией аргументов будет только lvalue.
 Пусть параметр имеет тип rvalue-ссылки:
 В этом случае допустимой категорией аргументов будет только rvalue.
 Пусть параметр имеет тип ссылки на константу или сам тип:
 В этих случаях допустимы любые категории аргументов.
 Пусть функции перегружены следующим образом:
 В этом случае для lvalue будет выбрана первая функция (хотя вторая также допустима), для остальных категорий вторая.
 Пусть теперь функции перегружены следующим образом:
 Здесь для констант и rvalue будет выбрана вторая функция, а вот для lvalue выбор будет неоднозначный.
 Пусть функции перегружены следующим образом:
 Для любых аргументов выбор будет неоднозначный.
 Для нестатических функций-членов квалификатор const позволяет перегружать функции в зависимости от константности скрытого параметра this.
 Hеконстантные функции-члены можно вызывать для rvalue объекта, то есть тем самым можно модифицировать rvalue. Но передавать в функцию rvalue аргумент через ссылку на неконстанту нельзя.
 Возможность модифицировать rvalue объект может показаться несколько странной и даже бессмысленной. Но это не совсем так, иногда ее можно с пользой использовать. В данном примере демонстрируется известная идиома полной очистки объекта с помощью rvalue объекта и функции обмена состояниями. (Ну и не надо забывать, что вся семантика перемещения базируется на модификации rvalue объекта.) Но вообще модификация rvalue объекта может создать всякого рода проблемы. Для того, чтобы предотвратить это, у функций, которые возвращают объект по значению, тип возвращаемого значения объявляют константным. Подробнее об этом можно почитать у Герба Саттера [Sutter1].
 Одно из самых значительных нововведений C++11 является семантика перемещения. Для ее реализации был введен специальный тип — rvalue-ссылка. Rvalue-ссылки это разновидность обычных C++ ссылок, отличие состоит в правилах инициализации и правилах разрешения перегрузок функций, имеющих параметры типа rvalue-ссылка. Программист должен четко знать описанные ниже правила, иначе результат перегрузки может оказаться неожиданным для программиста, компилятор «молча» заменит перемещение на копирование и все преимущества перемещения будут утеряны.
 Пусть функции перегружены следующим образом:
 В этом случае первая функция будет выбрана для rvalue аргументов (хотя вторая также допустима), а вторая для остальных категорий.
 Пусть функции перегружены следующим образом:
 В этом случае вторая функция будет выбрана для lvalue и константных аргументов, а вот для rvalue аргументов выбор будет неоднозначным, то есть первая функция не будет выбрана.
 Пусть функции перегружены следующим образом:
 В этом случае первая функция будет выбрана для rvalue аргументов, вторая для lvalue аргументов, а для константных аргументов разрешение перегрузки завершится неудачей.
 Отметим, что четвертая категория — константные rvalue, — может стать актуальной при использовании функций, которые возвращают объект по значению, который объявлен константным. (Причины обсуждаются в предыдущем разделе.) В случае, если этот тип перемещаемый, то его нельзя объявлять константным, так как это ломает всю семантику перемещения.
 Еще одно нововведение С++11, связанное с rvalue-ссылками — это ссылочные квалификаторы для нестатических функций-членов. Они позволяют перегружать по категории (lvalue/rvalue) скрытого параметра this.
 Следует обратить внимание на один важный момент: именованная rvalue-ссылка сама по себе является lvalue. Это надо учитывать при определении функций, имеющих параметры типа rvalue-ссылка, такие параметры являются lvalue и, если они используются в качестве аргументов какого-то внутреннего вызова, то скорее всего потребуют использования преобразования std::move(), иначе при разрешении перегрузки версия с параметром типа rvalue-ссылкой не будет выбрана.
 В шаблоне
 тип параметра функции является не rvalue-ссылка, а так называемая универсальная ссылка (universal reference). Для таких шаблонов допустимы аргументы любой категории. Для lvalue аргументов тип x выводится как T&, для констант как const T&, для rvalue аргументов как T&&. Сам по себе параметр x является lvalue, поэтому если он используются в качестве аргумента какого-то внутреннего вызова к нему обычно применяется преобразование std::forward<T>(), которое в случае, когда тип параметра T&&, превращает этот параметр в rvalue. Шаблоны с универсальными ссылками являются жадными (greedy), то есть при разрешении перегрузки у них высокий приоритет. Как бороться с жадными шаблонами, рассмотрено в разделе 2.5. Подробнее про универсальные ссылки и тесно связанную с ними прямую передачу (perfect forwarding) см. [Meyers2].
 В C++ в ряде случаев компилятору достаточно знать, что то или иное имя является именем какого-то пользовательского типа (класса, структуры, объединения, перечисления), а полное объявление типа не нужно. В этом случае можно использовать неполное объявление (incomplete declaration), называемое еще упреждающим (forward declaration). Типы с неполным объявлением называются неполными. Механизм перегрузки работает и для неполных типов.
 В данном случае полное объявление класса X может быть недоступно, но разрешение перегрузки работает.
 При инициализации указателя на функцию также можно использовать перегруженные функции.
 Разрешение перегрузки работает даже проще, для успешной инициализации нужно точное совпадение параметров и возвращаемого значения. Правила относительно областей видимости (сокрытие, расширение) такие же, но вот ADL не работает.
 Преобразования типа также способны выбирать из перегруженных функций.
 Здесь также требуется точное совпадение параметров и возвращаемого значения и ADL не работает.
 Рассмотрим теперь случай, когда указатель на функцию определяется с помощью ключевого слова auto.
 Если для Foo есть единственный кандидат, то компиляция проходит без ошибок, тип pf выводится как указатель на имеющийся Foo. А вот если есть другие перегруженные функции с именем Foo, то будет ошибка, компилятор по одному имени не сможет определить тип и сделать выбор.
 Практически та же ситуация может возникнуть в шаблонах, когда функциональный тип выводят из типа аргумента (нешаблонного). В качестве примера можно привести инициализацию экземпляра конкретизации функционального шаблона std::function<>, а также практически любой алгоритм, имеющий параметр функционального типа, например std::sort(). Для решения этой проблемы надо использовать явное преобразование типа.
 Перегруженные функции-члены также можно использовать при инициализации указателей на функции-члены класса.
 С точки зрения программиста использование перегруженных функций и функций с параметрами по умолчанию может быть очень похожим.
 Перегруженные функции
  можно заменить на единственную функцию с параметром по умолчанию
 и в коде, использующем Foo(), это будет почти не заметно. Но с точки зрения компилятора разница будет большая и программист это увидит, если попробует взять адреса функций.
 В случае перегруженных функций этот код был бы корректным.
 Перегрузку и параметры по умолчанию можно смешивать в определенных пределах, компиляторы справляются с этой проблемой, но вряд ли это можно отнести к хорошему стилю кодирования.
 К перегрузке виртуальных функций надо относиться с осторожностью. Дело в том, что разрешение перегрузки выполняется на этапе компиляции, и, соответственно, используется статический тип переменной, для которой вызывается виртуальная функция. Это не очень хорошо согласуется с динамической природой виртуальных функций и может привести к неприятным неожиданностям («потерей» наследуемых функций базового класса, см. раздел 1.3). Подробнее ситуация описана в [Dewhurst]. Но относиться с осторожностью — это не значит не использовать совсем. Если мы проектируем полиморфную иерархию классов, в корне которой находится интерфейсный класс (абстрактный класс, у которого почти все функции-члены чисто виртуальные), все перегрузки сделаны в этом классе и доступ к производным классам осуществляется только через этот интерфейсный класс, то никаких неприятностей не будет. Подобная модель построения полиморфной иерархии классов используется весьма широко. В Приложении А мы покажем, как перегрузка виртуальных функций используется при реализации известного паттерна проектирования Visitor.
 Разрешение перегрузки происходит на этапе компиляции, поэтому не удивительно, что этот механизм активно используется в метапрограммировании — программировании кода, который выполняется на этапе компиляции. Метапрограммирование активно используется при написании шаблонов, в том числе и шаблонов стандартной библиотеки. Без его использования практически невозможно написать универсальные, гибкие и эффективные шаблоны.
 Как известно, итераторы делятся на пять категорий. Идентификатором категории служит пустой тип-метка, например std::input_iterator_tag. Этот тип доступен через внутренний тип (typedef) итератора — iterator_category. Если в шаблоне надо обеспечить разное поведение в зависимости от категории итератора, то надо написать перегруженные функции для каждого из этих типов-меток, поставить вызов в соответствующее место и передать в качестве аргумента экземпляр типа iterator_category, после чего компилятор выберет функцию, соответствующую категории итератора. Вот пример:
 Обратим внимание на использование ключевого слова typename. Оно необходимо для того, чтобы iterator_category трактовался как внутренний тип для Iter.
 В C++ с помощью шаблонов очень легко превратить целочисленную константу, известную на этапе компиляции, в тип. В стандартной библиотеке для этого есть специальный шаблон:
 При конкретизации этого шаблона для каждого целочисленного типа T и значения типа T, известного на стадии компиляции, получается уникальный тип. Чаще всего используются:
 Ну а там, где появляются разные типы, можно использовать перегрузку.
 Вот еще один прием, используемый в метапрограммировании. Рассмотрим выражение:
 Это выражение вычисляется во время компиляции. При этом expr не вычисляется, определяется только его тип. После этого выполняется разрешение перегрузки, но сама Foo не вызывается, определяется только возвращаемый тип и поэтому определение Foo не нужно. Таким образом перегрузка используется для отображения типа на числовое значение.
 В C++17 появилась инструкция if constexpr (), которая ощутимо упрощает метапрограммирование, делает его более привычным и удобным. Но огромное количество кода (в том числе в стандартной библиотеке) не использует эту инструкцию и вряд ли его станут переписывать.
 Перегрузка — это мощный инструмент, но пользоваться им надо продуманно и аккуратно. В перегрузке немало подводных камней, надо трезво оценить свои силы и не искать лишний раз приключений на свою голову.
 Не стоит использовать перегрузку только потому, что компилятор это позволяет. Увлечение перегрузкой может снизить читаемость кода, сделать его безликим. Во многих случаях лучше дать название, отражающее специфику операции.
 Старайтесь избегать использования перегруженных функций и шаблонов, требующих сложных и не до конца понятных алгоритмов разрешения перегрузки.
 Не надо объявлять одноименные функции во вложенных областях видимости — это не перегрузка.
 Пусть у нас две полиморфные иерархии классов в одной из которых базовый класс A, а в другой V и функция
 Переменные a и v могут фактически указывать на объект любого производного класса из соответствующей иерархии и необходимо, чтобы функция динамически обеспечила операцию, зависящую от фактического типа как a, так и v, то есть осуществила выбор из некоторой матрицы операций. Это и называется двойной диспетчеризацией. Виртуальные функции обеспечивают одинарную диспетчеризацию, перегрузка является статической операцией, поэтому реализация двойной диспетчеризации требует дополнительных усилий. Решение этой задачи предложено в паттерне Visitor — одном из паттернов Банды Четырех [GoF].
 Пусть у нас есть две полиморфных иерархии классов, первая базируется на интерфейсном классе IAcceptor и вторая на интерфейсном классе IVisitor.
 Интерфейсный класс IVisitor перегружает виртуальную функцию Visit() для каждого класса иерархии, базирующегося на IAcceptor. Переопределенные в производных классах виртуальные функции Visit() и образуют матрицу операций, из которой надо выбрать элемент.
 Виртуальная функция
 во всех производных классах переопределяется одинаково, тело состоит из одной инструкции:
 Так как в каждом классе this имеет разный тип, то осуществляется разрешение перегрузки и выбирается соответствующая версия Visit(). Ну а дальше работает стандартный механизм выбора виртуальной функции и выбирается Visit(), переопределенная для фактического типа visitor.
Ну и наконец
 Voila. Двойная диспетчеризация готова.
 Иногда возникает необходимость замены функций из стандартной библиотеки какими-то пользовательскими вариантами. Наиболее известный пример — это функция (точнее шаблон функции) обмена состояниями двух объектов.
 Эта функция используется достаточно широко, например, ее применяют многие алгоритмы стандартной библиотеки. Но стандартная реализация может оказаться для некоторых типов весьма неэффективной и тогда естественно возникает вопрос о ее замене на более оптимальный пользовательский вариант. Это становится возможным, когда std::swap() используется в шаблонах, которые компилируются каждый раз при конкретизации, и ключевую роль в данном случае будет играть механизм перегрузки. Для того, чтобы шаблоны при компиляции использовали не std::swap(), а другую функцию, специально определенную для класса, необходимо выполнить несколько шагов. Рассмотрим сначала случай обычного класса, не шаблона.
 1. Определить в классе функцию-член Swap() (имя не принципиально), реализующую обмен состояниями.
 Необходимо гарантировать, чтобы эта функция не выбрасывала исключения, в C++11 такие функции надо объявлять как noexcept.
 2. В том же пространстве имен, что и класс X (обычно в том же заголовочном файле, а иногда и в теле класса), определить свободную (не-член) функцию swap() следующим образом (имя и сигнатура принципиальны):
 После этого, благодаря ADL, эта функция сможет участвовать в разрешении перегрузки вместе с std::swap() и в этом случае будет выбрана как имеющая лучшее соответствие.
 3. Определить полную специализацию std::swap() для X
 Стандартом запрещено добавлять в пространство имен std функции, шаблоны или что-нибудь еще. Исключение составляют полные специализации шаблонов из std.
 Спрашивается, а зачем вообще нужен третий шаг? Ответ такой — он подстраховывает от некоторых ошибок. Рассмотрим случай, когда в пользовательском пространстве имен реализуется некоторый шаблон, который использует функцию обмена состояниями.
 Естественно рассчитывать, что если T определяет swap(), то будет использоваться эта функция обмена состояниями, иначе стандартная. Но в приведенном варианте при разрешении перегрузки std::swap() не будет рассматриваться, она будет скрыта, поэтому это совсем ошибочный вариант.
  
Пусть теперь обмен состояниями делается так:
 В этом варианте пользовательская swap() не будет рассматриваться и вот тут и придет на помощь полная специализация std::swap() — будет выбрана она. Но это тоже не вполне правильный вариант.
 А совсем правильный вариант такой:
 Этот вариант гарантирует вызов пользовательской функции обмена состояниями, если она определена. В противном случае будет вызвана полная специализация std::swap(), если она определена. В остальных случаях будет вызвана конкретизация общего шаблона std::swap(). В данном варианте полная специализация std::swap() уже не нужна.
 Но полная специализация поможет, если в стандартной библиотеке (то есть в пространстве имен std) по ошибке используется
 вместо правильного
 Скотт Мейерс [Meyers1] утверждает, что в стандартной библиотеке такую ошибку полностью исключить нельзя.
 Рассмотрим теперь случай, когда функцию обмена состояниями надо определить для шаблона класса.
 А вот специализацию std::swap() мы уже сделать не можем, для этого надо было бы добавить в пространство имен std шаблон функции, а это стандартом запрещено, так, что подстраховки уже не будет, ошибочный код может работать неправильно.
 С помощью ключевого слова friend определение swap() можно перенести внутрь шаблона:
 Определение становится более лаконичным, а функция-член Swap() при этом может быть закрытой или защищенной.
 
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования.: Пер. с англ. — СПб.: Питер, 2001.
[Dewhurst]
Дьюхэрст, Стефан К. Скользкие места C++. Как избежать проблем при проектировании и компиляции ваших программ.: Пер. с англ. — М.: ДМК Пресс, 2012.
[Meyers1]
Мэйерс, Скотт. Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ.: Пер. с англ. — М.: ДМК Пресс, 2014.
[Meyers2]
Мейерс, Скотт. Эффективный и современный C++: 42 рекомендации по использованию C++11 и C ++14.: Пер. с англ. — М.: ООО «И.Д. Вильямс», 2016.
[Sutter1]
Саттер, Герб. Решение сложных задач на C++.: Пер. с англ. — М: ООО «И.Д. Вильямс», 2015.
[Sutter2]
Саттер, Герб. Новые сложные задачи на C++.: Пер. с англ. — М: ООО «И.Д. Вильямс», 2015.
 Программист