Пространство имен<boost::signals>было заменено на<boost::signals2>, чтобы избежать конфликта с первоначальным Boost. Реализация сигналов, а также макрос «сигналов» Qt. Весь рост. Классы Signals2 находятся внутри пространства имен<boost::signals2>, в отличие от оригинального Boost. Сигналы, которые имеют некоторые классы в пространстве имен<boost>в дополнение к своему собственному пространству имен<boost::signals>.

Файлы заголовков Boost.Signals2 содержатся в подкаталоге<boost/signals2/>вместо подкаталога<boost/signals>, используемого исходным Boost. Сигналы. Кроме того, все заголовки, за исключением удобного заголовка<boost/signals2.hpp>, находятся внутри подкаталога<boost/signals2/>, в отличие от оригинального Boost. Сигналы, которые сохраняют несколько заголовков в родительском<boost/>каталоге в дополнение к его собственному<boost/signals/>подкаталогу.

Например, класс<signal>теперь находится в пространстве имен<boost::signals2>вместо пространства имен<boost>, а файл заголовка теперь находится в<boost/signals2/signal.hpp>вместо<boost/signal.hpp>.

При переносе для обработки этих изменений должны потребоваться только тривиальные изменения в директивах<#include>и квалификациях пространства имен. Кроме того, новое пространство имен и место заголовка для Boost. Сигналы2 позволяют ему сосуществовать в одной программе с оригинальным Boost. Библиотека сигналов и портирование могут выполняться по частям.

Автоматическое управление соединением теперь достигается за счет использования<shared_ptr>/<weak_ptr>и<signals2::slot::track>(), как описано вучебнике. Старый (безопасный) рост. Схема автоматического управления подключением по-прежнему поддерживается через класс<boost::signals2::trackable>.

Если вы не собираетесь делать свою программу многопоточной, самый простой путь переноса - это просто заменить использование<boost::signals::trackable>в качестве базового класса<boost::signals2::trackable>. Boost.Signals2 использует тот же механизм<boost::visit_each>для обнаружения<trackable>объектов, что и исходный Boost. Библиотека сигналов.

Поддержка постконструкторов (и предеструкторов) на объектах, управляемых<shared_ptr>, была добавлена с<deconstruct>заводской функцией. Это было мотивировано важностью<shared_ptr>для новой схемы отслеживания соединений и невозможностью получить<shared_ptr>объект в его конструкторе.<deconstruct>описано вучебнике

. Использование<deconstruct>никоим образом не требуется, оно предоставляется только в надежде, что оно может быть полезным. Вы можете использовать его, если вы портируете код, где класс создает соединения со своими собственными функциями-членами в своем конструкторе, и вы также хотите использовать новую схему автоматического управления соединением. Затем вы можете переместить создание соединения от конструктора к функции<adl_postconstruct>, где ссылка на владение<shared_ptr>доступна для перехода к<signals2::slot::track>. Функция<deconstruct>будет использоваться для создания объектов класса и запуска связанных с ними функций<adl_postconstruct>. Вы можете использовать<deconstruct>, сделав конструкторов класса частными и объявив<deconstruct_access>другом.

Класс<signals2::slot>принимает новый параметр шаблона<Signature>, используется в качестве функционального объекта и имеет некоторые дополнительные функции для поддержки нового Boost. Система автоматического управления подключением Signals2.

Изменения в классе слотов, как правило, не должны вызывать каких-либо трудностей с переносом, особенно если вы используете класс совместимости<boost::signals2::trackable>, упомянутый выше. Если вы преобразуете свой код для использования новой схемы автоматического управления подключением, вам нужно будет использовать некоторые из новых функций слота, как описано в учебнике

Класс<optional_last_value>заменил<last_value>в качестве комбинатора по умолчанию для сигналов.

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

Если вы переносите сигналы, которые имеют<void>тип возврата в своей подписи, и они используют комбинатор по умолчанию, не требуется никаких изменений. Если вы используете комбинатор по умолчанию с непустым типом возврата и заботитесь о значении, возвращенном из вызова сигнала, вам придется учитывать, что<optional_last_value>возвращает<boost::optional>вместо простого значения. Один простой способ справиться с этим — использовать<boost::optional::operator*()>для доступа к значению, завернутому внутри возвращенного<boost::optional>.

Кроме того, вы можете сделать порт, указав параметр шаблона<Combiner>для вашего<signals2::signal>, чтобы быть<signals2::last_value>.

Класс<signals2::signal>имеет дополнительный типдеф<signals2::signal::extended_slot_type>и новые<signals2::signal::connect_extended>() методы. Они позволяют подключать слоты, которые принимают дополнительный аргумент<signals2::connection>, предоставляя им безопасный доступ к их соединению сигнал / слот, когда они вызываются. Существует также новый<ExtendedSlotFunction>шаблонный параметр для определения базового типа функции слота для новых расширенных слотов.

Эти дополнения не должны иметь никакого влияния на портирование, если вы также не преобразуете свою программу из одной потоковой программы в многопоточную. В этом случае, если у вас есть слоты, которые нуждаются в доступе к их<signals2::connection>сигналу, вызывающему их (например, для блокировки или отключения их соединения), вы можете соединить слоты с<signals2::signal::connect_extended>(). Это также требует добавления дополнительного аргумента подключения к слоту. Более подробная информация о том, как и почему использовать расширенные слоты, доступна в учебнике

Класс<signals2::signal>имеет новый<Mutex>шаблонный параметр для указания типа mutex, используемого внутри сигнала и его соединений.

Параметр шаблона<Mutex>может быть оставлен на его значение по умолчанию<boost::signals2::mutex>и не должен иметь большого влияния на портирование. Однако, если у вас есть однопоточная программа и вы беспокоитесь о накладных расходах на производительность от ненужной блокировки mutex, вы можете использовать другой mutex для своих сигналов, таких как<dummy_mutex>. См.учебникдля получения дополнительной информации о<Mutex>параметре.

Метод<signal::combiner()>, который ранее возвращал ссылку на комбинатор сигнала, был заменен<signals2::signal::combiner>(который теперь возвращает комбинатор по значению) и<signals2::signal::set_combiner>

Во время переноса должно быть легко заменить использование старой функции возврата ссылок<signal::combiner()>новыми функциями «по стоимости»<signals2::signal::combiner>и<signals2::signal::set_combiner>. Тем не менее, вам нужно будет проверить каждый вызов метода<combiner>в вашем коде, чтобы определить, была ли ваша логика программы нарушена измененным типом возврата.

Соединения больше не имеют<block()>и<unblock()>способов. Блокировка соединений теперь осуществляется путем создания<shared_connection_block>объектов, которые обеспечивают блокировку в стиле RAII.

Если у вас уже есть рост. Сигналы кода, которые блокируют, например:

  namespace bs = boost::signals;
  bs::connection my_connection;
  //...
  my_connection.block();
  do_something();
  my_connection.unblock();
 

, затем версия портируется на Boost. Сигналы2 будут выглядеть так:

  namespace bs2 = boost::signals2;
  bs2::connection my_connection;
  //...
  {
    bs2::shared_connection_block blocker(my_connection);
    do_something();
  } // blocker goes out of scope here and releases its block on my_connection