Большое время компиляции. Во-первых, компилятор осуществляет генерацию кода при каждом инстанциировании шаблона конкретным типом. Во-вторых, шаблоны для одних и тех же типов, инстанциируемые в разных участках программы, будут компилироваться заново. И, в-третьих, много времени тратится на компиляцию включаемых файлов: например, при каждом включении заголовочных файлов стандартной библиотеки все внутренние реализации шаблонов в этих файлах должны быть скомпилированы.
Склонность к разрастанию программного кода. Для каждого используемого типа будет сгенерирован отдельный код. Представим, к примеру, что мы используем шаблонную функцию с входным аргументом числом, тип которого задается параметром шаблона. Если мы будем вызывать эту функцию с аргументами различных типов, допустим, char, short, int, long, для каждого типа будет сгенерирована отдельная функция, несмотря на то что используемые типы эквивалентны и можно обойтись одним-единственным типом long. Аналогичная ситуация возникает при специализации шаблонов: даже если мы делаем частичную специализацию c целью изменить поведение одного-единственного метода, нам придется повторить весь код, используемый в общей специализации.
4.7.2. Ограничения шаблонов
В общем-то, рассмотренные недостатки не так уж значительны, и преимуществ у шаблонов значительно больше. Тем не менее, они имеют фундаментальное ограничение, вытекающие из их внутренней природы: шаблоны не создают предварительно откомпилированного кода. По большому счету шаблон представляет собой не сам код, а правила для генерации кода. Пока шаблон не инстанциирован, его код отсутствует; после инстанциирования последний генерируется только для тех методов и функций, которые были вызваны. Из указанного ограничения вытекают следующие выводы.
Интерфейс шаблона не может быть отделен от реализации. И объявление шаблона, и его реализация должны находиться в одной области видимости (модель включения). Таким образом, при изменениях в реализации шаблона все компоненты, которые его используют, должны быть перекомпилированы.
Шаблоны не могут поставляться в виде статических или динамических библиотек, они должны поставляться только в виде исходного кода. Никакие сторонние приложения (за исключением компиляторов C++, разумеется) не могут использовать функциональность, реализованную на базе шаблонов.
По вышеуказанным причинам,29
С помощью шаблонов невозможно реализовать интерфейсы API.
4.8. Итоги
Шаблоны обеспечивают параметрический полиморфизм, что позволяет писать обобщенный код, реализующий заданную функциональность без привязки к типам данных.
Инициатор для синхронных вызовов реализуется с помощью шаблонов функций, асинхронных с помощью шаблонов классов.
В реализации шаблона инициатора тип объекта вызова задается параметром. Поскольку разные типы объектов требуют различное число параметров и используют неодинаковый синтаксис, для сохранения единой реализации используется преобразование вызовов.
Функциям, реализующим алгоритмы, зачастую требуются различные операции над данными. Поскольку в обобщенном коде типы данных заранее не известны, для реализации операций используются предикаты.
В асинхронных вызовах для каждого типа аргумента приходится инстанциировать соответствующий инициатор. Использование универсального аргумента позволяет реализовать единый класс для любых типов аргументов, однако в некоторых случаях это может привести к падению производительности.
В стандартной библиотеке STL имеются мощные средства для организации вызовов, реализующие универсальный аргумент, вызов методов класса, перенаправление вызовов.
Шаблонам присущи недостатки, большинство из которых незначительны и не перевешивают их достоинств. Однако шаблоны не предполагают предварительно откомпилированного кода, и по этой причине не могут использоваться в интерфейсах API.
5. Распределение вызовов
5.1. Постановка задачи
Под распределением вызовов понимается техника, в которой при вызове единственной функции осуществляется выполнение множества вызовов через соответствующие аргументы.
Графически задача распределения вызовов показана на Рис. 21. Компонент, осуществляющий вызов, называется источником; аргументы вызова называются получателями; компонент, осуществляющий распределение вызовов, называется распределитель; код, запускающий вызовы, называется распределяющая функция. При необходимости дополнительно в вызов могут передаваться какие-либо данные.
5. Распределение вызовов
5.1. Постановка задачи
Под распределением вызовов понимается техника, в которой при вызове единственной функции осуществляется выполнение множества вызовов через соответствующие аргументы.
Графически задача распределения вызовов показана на Рис. 21. Компонент, осуществляющий вызов, называется источником; аргументы вызова называются получателями; компонент, осуществляющий распределение вызовов, называется распределитель; код, запускающий вызовы, называется распределяющая функция. При необходимости дополнительно в вызов могут передаваться какие-либо данные.
Распределитель может быть реализован в виде функции либо класса. Если распределитель реализован в виде функции, то он сам представляет собой распределяющую функцию. Если распределитель реализован в виде класса, то распределяющая функция представляет собой метод класса либо перегруженный оператор.
Рис. 21. Распределение вызовов
Как видим, постановка задачи звучит достаточно просто. Зачем же тогда ей посвящен отдельный раздел? Во-первых, распределение вызовов имеет важное прикладное значение: оно используется в самых различных приложениях, таких, как обработка команд, оповещение о событиях, синхронизация операций и др. Во-вторых, задача распределения вызовов совсем не такая простая, как это может показаться из формального описания. Для ее решения используются изощренные техники, призванные обеспечивать максимальную эффективность для самых различных требований.
Итак, рассмотрим, как реализуется распределение вызовов.
5.2. Статический набор получателей
5.2.1. Распределение в статическом наборе
Если типы и количество получателей известны на этапе компиляции и не планируется их изменение в процессе выполнения программы, то мы имеем статический набор получателей. В этом случае распределитель можно реализовать в виде шаблонной функции, которая в качестве входных аргументов будет принимать объекты вызова. Но поскольку типы объектов и их количество могут быть различными, логично в качестве входного параметра функции использовать пакет, задаваемый шаблоном.
Итак, нам необходимо выполнить вызов для каждого объекта, входящего в пакет. Для решения этой задачи используется техника рекурсивного развертывания пакета, суть которой заключается в следующем.
Объявляется функция, первым параметром которой выступает объект вызова, а вторым пакет. Когда на вход данной функции поступает пакет, первый объект из него извлекается, происходит вызов этого объекта, а затем функция рекурсивно вызывается вновь с пакетом, содержащим еще не извлеченные объекты. Когда в результате рекурсивных вызовов все объекты будут извлечены, будет вызвана функция, на вход которой будет передан пустой пакет. Данная функция завершает рекурсивное выполнение.
Реализация описанной техники приведена в Листинг 63.
Листинг 63. Распределяющая функция для статического набора получателейvoid Call() // (1)
{
}
template < typename First, typenameOthers>
void Call(First& first, Othersrest) // (2)
{
first(); // (3)
Call(rest); // (4)
}
template <typename CallObjects>
void Distribute(CallObjects objects) // (5)
{
Call(objects); // (6)
}
Графически развертывание пакета параметров для трех аргументов изображено на Рис. 22. Процесс начинается с вызова распределяющей функции, которая объявлена в строке 5. Здесь используется пакет параметров objects, который содержит объекты вызова. Внутри этой функции, в строке 6, происходит первый вызов рекурсивной функции, которой на вход передаются соответствующий аргумент в виде пакета.
Рекурсивная функция Call объявлена в строке 2. Эта функция принимает два аргумента: первый параметр из пакета first и пакет остальных параметров rest. При первом вызове пакет параметров из Distribute передается в эту функцию, и там происходит его распаковка: первый параметр извлекается и помещается в first, оставшаяся часть пакета записывается в rest. В строке 3 производится вызов, а пакет с оставшимися параметрами передается в рекурсивный вызов Call (строка 4).
Итак, на каждом шаге рекурсивного вызова из пакета извлекается очередной параметр, а размер исходного пакета уменьшается. Таким образом, в итоге все параметры будут извлечены, и пакет станет пустым. Эта ситуация обрабатывается путем объявления функции с пустым пакетом параметров, т. е. функции, которая на вход не принимает ни одного аргумента (строка 1). Тело этой функции пустое, в ней происходит возврат управления, и по цепочке рекурсивных вызовов управление возвращается в исходную точку в строке 6.