Сигналы-слоты. boost vs. qt

https://code.google.com/p/ting/wiki/SignalSlotUsage :]

Это еще одна альтернатива?

Какие у нее есть преимущества по сравнению с двумя предыдущими кандидатами помимо того, что ее предложил человек с вождем на аватарке?

qt используют свой лисапед

потому-что кутя появилась тогда, когда в спп ещё даже ексепшенов не было, не то что буста с его е-шаблонами.

Не знаю, оно у меня в закладках в разделе «посмотреть когда будет совсем делать нечего».

Ок, тоже постараюсь глянуть.

Если интересно - могу потом свои мысли сюда скинуть.

Это понятно. Но ведь был переход на 5-ку, когда этот механизм пересматривался. Они от буста по каким-то причинам отказались?

Ну че уж там, давайте и http://libsigc.sourceforge.net/ в кучу, кто что скажет

Расскажи лучше зачем вообще нужны сигналы без GUI?

Я им ни одного достойного применения не вижу, кроме GUI. А отсюда следует что boost.signals(2) ненужны!

В чем плюсы сего творения?

Сейчас разговор немного не об этом. Но помимо гуйни сигналы позволяют создать простой и понятный механизм реагирования на раздражители.

А вот этого не знаю.

зачем вообще нужны сигналы

man sigaction как бы. или даже man signalfd

Не знаю.

Я узнал о этой штуке, так как на ней Gtkmm делает typesafe сигналы без препроцессора

https://developer.gnome.org/libsigc -tutorial/stable/ch02.html#id447321

Ну и собственно поддержка member functions тоже итд

Ок, возможно гляну.

Но ведь был переход на 5-ку, когда этот механизм пересматривался. Они от буста по каким-то причинам отказались?

а по каким причинам они должны были его использовать? boost signals хуже реализации в Qt5

Отлично, теперь хотелось бы услышать аргументацию.

Я пока что заметил лишь отсутствие проброса сигналов через очередь сообщений в бусте. Qt использую последние 5 лет, про буст вдумчиво читать начал только сегодня.

Я пока что заметил лишь отсутствие проброса сигналов через очередь сообщений в бусте

Дык в бусте же нету реализации очереди сообщений (говнокласс из boost::asio не в счет).

Еще реализация с прогорга http://www.prog.org.ru/topic_16829_0.html

Зачем Кьюту бустовская реализация, если своя вполне удобная и работоспособная? Тем более, в 5 версии добавили коннекты на шаблонах.

Отлично, теперь хотелось бы услышать аргументацию.

сходу:

connect( act, &QAction::triggered, []( bool c ) {} ); // OK
connect( act, &QAction::triggered, []() {} ); // OK

act.signal_triggered.connect( []( bool c ) {} ); // OK
sig.signal_triggered.connect( []() {} ); // FAIL

ну и boost signals банально многословнее и требует руками выписывать параметры шаблонам

А скорость? Вроде ж оно в Qt медленнее.

DirectConnection же заменяется на прямой вызов, не?

Я не в теме, потому и спрашиваю.

А скорость? Вроде ж оно в Qt медленнее.

в Qt скорость сигнал-слотов вполне достаточна для работы на всяких Symbian, так что ради скорости переходить на другие реализации им точно не было надобности

На сколько я помню, QueueConnection ставит в очередь сообщений, а DirectConnection заменяется на прямой вызов, так что, с ним оверхеда никакого.

Там есть небольшой оверхед на маршалинг аргументов в void*, пока вызов путешествует по кишочкам метаобъектной системы Qt.

Разве в пятерочке нету второго, более нового приплюснутого механизма сигналов-слотов?

Можешь здесь прочитать немного, правда рассматриваются старые версии Qt и boost.

http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf

А вообще boost::signal уже deprecated, рекомендуют boost::signal2, правда у него чуть больше оверхед при emit

boost signals хуже реализации в Qt5

С хрена ли? У типобезопасных Qt-шных сигналов нет возможности явно задавать тип функции отправителя и приёмника, как минимум. А задаваемые строками — адЪ и Израиль, достаточно ошибиться в одном символе с любой стороны, и начинается гадание по звёздам, а шо это у меня не вызывается, или не генерируется, и где именно? А про boost-овые Signals2 есть хорошая статья с описанием их внутренностей, и как они работают.

У типобезопасных Qt-шных сигналов нет возможности явно задавать тип функции отправителя и приёмника, как минимум.

но зачем? если сигнатура слота не позволяет принимать аргументы из сигнала, то будет ошибка при компиляции, что еще надо?

А задаваемые строками — адЪ и Израиль, достаточно ошибиться в одном символе с любой стороны, и начинается гадание по звёздам, а шо это у меня не вызывается, или не генерируется, и где именно?

ЕМНИП, Qt в таких случаях в stderr выведет сообщение, что и куда не приконнектилось

А про boost-овые Signals2 есть хорошая статья с описанием их внутренностей, и как они работают.

  boost::signals2::signal<void (int)> sig;

  boost::shared_ptr<TrackedHelloWorld> p(new TrackedHelloWorld());
  boost::signals2::signal<void (int)>::slot_type s(*p);
  s.track(p);
  sig.connect(s);

да ну нах такое счастье, и это еще без очередей и многотредовости

В Qt сигнал - это всего лишь функция, которую пишет за тебя MOC, в boost сигнал - это функциональный объект, в связи с этим размер класса прилично растет с каждым новым сигналом. Но в остальном бустовый вариант мне нравится больше... хотя нет, я сделал свой велосипед на C++11, не имеющий фатальных недостатков первых двух вариантов ;-)

но зачем?

Для своих, рукодельных сигналов/слотов, нопремер.

Для своих, рукодельных сигналов/слотов, нопремер.

в Qt5 можно связывать сигнал с произвольным методом или функцией, их можно считать «рукодельными»?

да ну нах такое счастье

typedef-ы запретили уже?

без очередей и многотредовости

В-третьих, в анализе упускаются места, связанные с многопоточностью. Многопоточность влияет только на правильную расстановку в нужных местах объектов блокировки. Данная задача решается в библиотеке так же, как и в любом другом коде.

в Qt5 можно связывать сигнал с произвольным методом или функцией

Если функция/метод перегружены? В boost::Signals2 это решается просто, а вот в Qt, где нет явного указания сигнатуры функций — я ХЗ, как это провернуть без заморочек.

typedef-ы запретили уже?

те же яйца

Многопоточность влияет только на правильную расстановку в нужных местах объектов блокировки. Данная задача решается в библиотеке так же, как и в любом другом коде

бла-бла-бла, а по факту - надо велосипедить там, где в Qt не надо

Любые асинхронные операции, да и общение между тредами лучше сделать через очередь сообщений, которая прозрачно достигается через сигналы/слоты.

Если функция/метод перегружены?

нет проблем, только что проверил

те же яйца

В конце концов, есть уже вполне поддерживаемый конпеляторами C++11, который может в auto и прочие decltype.

надо велосипедить там, где в Qt не надо

Нытьё такое нытьё. Де ты велосипеды увидел-то?

а вот в Qt, где нет явного указания сигнатуры функци

А это что тогда?

QObject::connect(_process, static_cast<void (QProcess::*)(int)>(&QProcess::finished), [&](int) {});

нет проблем, только что проверил

Дома буду, тоже посмотрю, что там наделали. Так, глядишь, и на Qt 5 перейти сподоблюсь.

Бывали у меня такие веселухи, приходилось делать заклинания типа такого:

        connect(this, &Connection::commandSent,
                device, static_cast<void (AbstractDevice::*)(const Command &)>(&AbstractDevice::send), Qt::QueuedConnection);

В конце концов, есть уже вполне поддерживаемый конпеляторами C++11, который может в auto и прочие decltype

прекрасно, перепиши:

  boost::signals2::signal<void (int)> sig;

  boost::shared_ptr<TrackedHelloWorld> p(new TrackedHelloWorld());
  boost::signals2::signal<void (int)>::slot_type s(*p);

на С++11

Нытьё такое нытьё. Де ты велосипеды увидел-то?

покажи как ты сделаешь аналог Qt::QueuedConnection, да и код выше - тоже велосипед, который в Qt не нужен

Кстати, для общения между тредами, можно использовать лямбда функции, которые возращают другую лямбду. Тогда отдаем в другой тред эту лямбду: там ее запускаем, она исполняется, потом лямбду с результатом заталкиваем в исходный тред и там уже она уже выступает в роли колбэка.

А это что тогда?

Ну... Это хорошо, тогда.

перепиши... на С++11

Не сейчас, а то лениво. Да и не помню я навскидку, насколько Signals2 совместимы со стандартной библиотекой C++11.

для общения между тредами, можно использовать лямбда функции, которые возращают другую лямбду

В следующих стандартах плюсов обещаются много интересного для многопоточности и асинхронности впилить. Будем посмотреть, попробовать.

boost.Signals2 потокобезопасные а boost.Signals нет

На практике такие сообщения часто теряются в логе