Соединяем Qt-сигнал с простой функцией и лямбда

[Vass]

Т.е вы предлагаете, под каждый набор параметров слота добавлять по новому конструктору?
Если говорить о C++11, то вместо указателя на функцию лучше использовать std::function
У Вашего класса нет поддержки ConnectionType, и мало того, он гаратировано будет криво работать с вызовом функций из другого потока.
Также стоит добавить, что в Qt5 описываемый функционал работает "из коробки" и гораздо лучше.

[kciray]

На счёт Qt5 — он не так давно вышел и я с ним ещё не освоился. Вполне возможно, что там уже есть такие функции. Что касается std::function — да, оно действительно было бы лучшим решением.
Про многопоточность и поддержку типа соединения — можно доработать, но смысла не вижу, если в Qt5 это будет из коробки. Я разработал сей класс, когда Qt 5 ещё не вышел… Думал, может кому полезен будет. Не все же ещё на Qt5 перешли

[Vass]

На счёт Qt5 — он не так давно вышел и я с ним ещё не освоился.

Тогда крайне рекомендую к прочтению: New Signal Slot Syntax in Qt 5

[Door]

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

А обычно ведь происходит наследование от классов Qt, что делает нас полноценными владельцами функционала и прописать Q_OBJECT не составляет никакого труда. В других случаях — то-ли из-за боязни «тяжёлого» QObject, то-ли из-за каких либо других причин, по крайней мере в моём случае — находился вариант обхождения без сигналов/слотов, причём, вполне скромный и не расточительный… да ещё если учесть C++11( ->куда же без Qt5 ) — проблема полностью отпадает.

[namespace]

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

Нет. Если честно, ни разу. Ни разу в жизни не приходилось. Если нужно ловить сигнал, то его нужно ловить слотом (иначе это есть нарушение архитектуры).

Экономия памяти? По-моему, если есть потребность ловить сигнал из вне sender'а, то скорее всего он и будет наследником QObject. Иначе, это опять же нарушение архитектуры.

Так что я больше склоняюсь к тому, что ваше решение — не больше, чем костыль.

П.С. Оберните код в `source`, a не `code`, пожалуйста.

[Vass]

Слишком горячо и не совсем верно, слоты сделаны такими какие они есть только именно потому, что не было красивого пути со свободным коннектом, и собственно новый синтаксис Qt5 как раз стирает это недоразумение, позволяя цеплять сигналы даже к простым функциям.

[namespace]

Перечитал пару статей на qt project и понял, что это именно так. Qt 5 — это очень хорошо в этом плане.

[Averrin]

Пишу на PyQt и не знал, что такая проблема вообще есть. Видел сигнатуру connect, там написано «callable». И лямбды, емнип, прекрасно обрабатываются.
И да, очень хочу PyQt5.

[nivs]

Именно. В PyQt4 я использовал, к примеру

self.connect(self.butVar5, QtCore.SIGNAL("clicked()"), lambda: self.fVar(5))

а когда понадобилось это же в С++ — так и не нашёл решения (опыта нет, считай только начал изучать). Так что спасибо автору за пост. Искал решение с lambda-функцией, но в QtCreator'е не завелось, упорства, видимо, не хватило. Либо пересоберу Qt 4 с поддержкой С++11, либо перейду на Qt 5.