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

Пользователи, не удовлетворенные выбором определения слота, могут заменить тип функции слота по умолчанию альтернативой, которая отвечает их конкретным потребностям.

Пользователи должны иметь точный контроль над подключением сигналов к слотам и их возможным отключением. Подход, принятый Boost. Сигналы должны возвращать объект<connection>, который позволяет подключать / отключать запрос, ручное отключение и автоматическое отключение в режиме уничтожения. Некоторые другие возможные интерфейсы включают:

Интерфейс Combiner был выбран для имитации вызова алгоритма в стандартной библиотеке C++. Считается, что, рассматривая результаты вызова слота как просто последовательность значений, доступных с помощью итераторов ввода, интерфейс комбинатора будет наиболее естественным для опытного программиста C++. Конкурирующий дизайн интерфейса обычно требовал, чтобы комбинаторы были построены в соответствии с интерфейсом, который будет настроен для (и ограничен) библиотеки сигналов. Хотя эти интерфейсы, как правило, обеспечивают более простую реализацию сигналов и усилителей; библиотеки слотов, комбинаторы, к сожалению, не могут быть повторно использованы (либо в других сигналах и усилителях; библиотеки слотов или в других общих алгоритмах), и кривая обучения немного покручена, чтобы изучить конкретный интерфейс комбинатора.

Формулировка Сигналов комбайнов основана на комбинаторе, использующем «тяговый» режим связи, вместо более сложного «толкающего» механизма. С механизмом «вытягивания» состояние комбинатора может храниться на стеке и в счетчике программы, потому что всякий раз, когда требуются новые данные (т.е. вызов следующего слота для извлечения его обратного значения), существует простой интерфейс для извлечения этих данных немедленно и без возвращения из кода комбинатора. Сравните это с механизмом «толчка», где комбинатор должен сохранять все состояние в классе, потому что для каждого сигнала, называемого комбинатором, будут использоваться процедуры комбинатора. Сравните, например, комбинатор, который возвращает максимальный элемент от вызова слотов. Если максимальный элемент когда-либо превышает 100, больше слотов не будет.

struct pull_max {
  typedef int result_type;
  template<typename InputIterator>
  result_type operator()(InputIterator first,
                         InputIterator last)
  {
    if (first == last)
      throw std::runtime_error("Empty!");
    int max_value = *first++;
    while(first != last && *first <= 100) {
      if (*first > max_value)
        max_value = *first;
      ++first;
    }
    return max_value;
  }
};

struct push_max {
  typedef int result_type;
  push_max() : max_value(), got_first(false) {}
  // returns false when we want to stop
  bool operator()(int result) {
    if (result > 100)
      return false;
    if (!got_first) {
      got_first = true;
      max_value = result;
      return true;
    }
    if (result > max_value)
      max_value = result;
    return true;
  }
  int get_value() const 
  { 
    if (!got_first)
      throw std::runtime_error("Empty!");
    return max_value; 
  }
private:
  int  max_value; 
  bool got_first;
};

В этих примерах следует отметить несколько моментов. Версия «pull» является многоразовым функциональным объектом, который основан на последовательности итератора ввода с целым числом<value_type>и очень прост в дизайне. Модель «push», с другой стороны, опирается на интерфейс, специфичный для абонента, и обычно не используется повторно. Это также требует дополнительных значений состояния, чтобы определить, например, были ли получены какие-либо элементы. Хотя качество кода и простота использования, как правило, субъективны, модель «вытягивания» явно короче и более многоразовая и часто будет рассматриваться как более простая в написании и понимании, даже вне контекста библиотеки сигналов и усилителей.

Стоимость интерфейса комбинатора «pull» оплачивается при реализации самой библиотеки Сигналов. Чтобы правильно обрабатывать отключения слотов во время вызовов (например, когда вызывается оператор отсчета), необходимо построить итератор, чтобы пропустить отключенные слоты. Кроме того, итератор должен нести с собой набор аргументов для передачи в каждый слот (хотя достаточно ссылки на структуру, содержащую эти аргументы), и должен кэшировать результат вызова слота, чтобы множественные ссылки не приводили к нескольким вызовам. Это, по-видимому, требует большой степени накладных расходов, хотя, если рассматривать весь процесс вызова слотов, можно увидеть, что накладные расходы почти эквивалентны таковым в модели «толчка», но мы перевернули структуры управления, чтобы сделать комплекс итерации и отсчета (вместо того, чтобы делать комбинаторный комплекс определения состояния).

Повышаю. Сигналы поддерживают синтаксис соединения с формой<sig.connect(slot)>, но был предложен более краткий синтаксис<sig += slot>(и использовался другими сигналами и усилителями; реализациями слотов). Существует несколько причин, по которым этот синтаксис был отклонен:

Класс 80 является основным пользовательским интерфейсом для автоматического управления временем жизни соединения, и его дизайн напрямую влияет на пользователей. Больше всего выделяются две проблемы: странное поведение копирования<trackable>и ограничение, требующее от пользователей исходить из<trackable>для создания типов, которые могут участвовать в автоматическом управлении соединением.