«Стирание типа», где статическая информация типа устраняется с помощью динамически диспетчеризованных интерфейсов, широко используется в Boost. Библиотека сигналов для уменьшения количества кода, генерируемого с помощью шаблона. Каждый сигнал должен управлять списком слотов и связанных с ними соединений, а также<std::map>для отображения от групповых идентификаторов до связанных с ними соединений. Тем не менее, создание этой карты для каждого типа токенов и, возможно, в каждом блоке перевода (для некоторых популярных стратегий создания шаблонов) увеличивает время компиляции и пространство над головой.

Для борьбы с этим так называемым «шаблонным вздутием» мы используем Boost. Функция и повышение. Любые для хранения неизвестных типов и операций. Затем весь код для обработки списка слотов и отображения от идентификаторов слотов до соединений учитывается в классе<signal_base>, который имеет дело исключительно с объектами<any>и<function>, скрывая фактические реализации с использованием известной идиомы pimpl. Фактические<signalN>шаблоны классов имеют дело только с кодом, который будет меняться в зависимости от количества аргументов или который по своей сути зависит от шаблона (например, соединение).

Класс<connection>является центральным в поведении Роста. Библиотека сигналов. Это единственная сущность внутри Роста. Система сигналов, которая обладает знанием всех объектов, связанных заданной связью. Если говорить конкретно, то класс<connection>сам по себе является лишь тонкой оберткой<shared_ptr>к<basic_connection>объекту.

<connection>объекты хранятся всеми участниками системы Сигналов: каждый<trackable>объект содержит список<connection>объектов, описывающих все соединения, частью которых он является; аналогично, все сигналы содержат набор пар, определяющих слот. Пара состоит из объекта функции слота (обычно объекта Boost.Function) и объекта<connection>(который отключается при разрушении). Наконец, отображение от групп слотов к слотам основано на ключевом значении в<std::multimap>(сохраненные данные в<std::multimap>являются парой слотов).

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

Шаблон функции<visit_each>— это механизм обнаружения объектов, которые хранятся в другом объекте. Шаблон функции<visit_each>принимает три аргумента: объект для исследования, объект функции посетителя, который вызывается каждым подобъектом, и<int>. 0.

Третий параметр является лишь временным решением широко распространенного отсутствия надлежащего частичного упорядочивания шаблона функций. Основной шаблон функции<visit_each>определяет этот тип третьего параметра как<long>, тогда как любые пользовательские специализации должны указывать свой третий параметр как тип<int>. Таким образом, даже если сломанный компилятор не может определить порядок между, например, соответствием параметру<T>и параметру<A<T>>, он может определить, что преобразование из целого числа 0 в<int>лучше, чем преобразование в<long>. Таким образом, упорядочение, определяемое этим преобразованием, достигает частичного упорядочения шаблонов функций ограниченным, но успешным способом. Следующий пример иллюстрирует использование этой техники:

template<typename> class A {};
template<typename T> void foo(T, long);
template<typename T> void foo(A<T>, int);
A<T> at;
foo(at, 0);

В этом примере мы предполагаем, что наш компилятор не может сказать, что<A<T>>лучше, чем<T>, и поэтому предполагаем, что шаблоны функций не могут быть упорядочены на основе этого параметра. Тогда преобразование от 0 до<int>лучше, чем преобразование от 0 до<long>, и выбирается второй шаблон функции.