LINUX.ORG.RU

Что плохого в сигнало-слотах?


0

0

Читаю "QT Профессиональное программирование на C++" Шлее. Там так вкусно рассказывается про сигнало-слоты, что непонятно как вообще все без них обходятся. Однако обходятся. И вроде бы не любят. В связи с этим два вопроса: собственно сабж и как обходятся без сигнало-слотов в других гуях (в том же gtk например)?

★★★★★
Ответ на: комментарий от PayableOnDeath

а если быть совсем точным, то им может быть любой callable

val-amart ★★★★★
()
Ответ на: комментарий от jtootf

таки да, и пока из треда я понял, что все недостатки модели сигналов в Qt на самом деле проистекают из костылей крестов. Мне кажется естественным, что рядом с ними любой развитый динамический язык, как-то лисп, тикль или питон, с биндингом что к Qt, что к Gtk, что к Tk очень удобен в использовании.

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

>таки да, и пока из треда я понял, что все недостатки модели сигналов в Qt на самом деле проистекают из костылей крестов

увы, вместо сравнения того, что сравнивать действительно имело смысл, мы скатились ко взаимному забрасыванию фекалиями :(

кстати, слотом в PyQt может быть любой callable - а сигналом?

jtootf ★★★★★
()
Ответ на: комментарий от val-amart

>все недостатки модели сигналов в Qt на самом деле проистекают из костылей крестов

кстати говоря, это не так. что и удивительно

libsigc++, libevent лишены большей части недостатков Qt; статически типизированную библиотечку событий, способную использовать в качестве источника/приёмника любой callable я в своё время писал (с помощью boost.bind, boost.function, boost.tuple. boost.mpl, boost.type_traits и boost.typeof) - получается замысловато, но вполне работоспособно

часть бед Qt в смысле событий проистекает из использования MOC (те же шаблоны, например), но большая часть, как по мне,- чистой воды legacy. слишком много кода завязано на существующую модель

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>чистой воды legacy. слишком много кода завязано на существующую модель

После перехода qt3->qt4 звучит не убедительно.

KblCb ★★★★★
() автор топика
Ответ на: комментарий от jtootf

а может они просто не захотели писать что-то вроде вот этого:

template <template <class> class _P, class R, class A1, class A2, class T1, class T2>
boost::tuple< typename if_< is_base_of<IPlaceholder, T1>, _P<A1>, A1 >::type, typename if_< is_base_of<IPlaceholder, T2>, _P<A2>, A2 >::type > DepDeduce(R (*) (A1, A2), T1 t1, T2 t2)
{
    typedef typename if_< is_base_of<IPlaceholder, T1>, _P<A1>, A1 >::type _arg1;
    typedef typename if_< is_base_of<IPlaceholder, T2>, _P<A2>, A2 >::type _arg2;

    return boost::make_tuple(
        TemplArg< is_base_of<IPlaceholder, T1>::value >::template Do<_arg1>(t1),
        TemplArg< is_base_of<IPlaceholder, T2>::value >::template Do<_arg2>(t2));
};

jtootf ★★★★★
()
Ответ на: комментарий от KblCb

>После перехода qt3->qt4 звучит не убедительно.

а что действительно существенного они поменяли при переходе? отказались от MOC? от модели контроля памяти? от модели сигналов/слотов? от собственной реализации STD/STL?

вроде нет, ничего столь кардинального они не сделали. и не сделают

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

Замечу лишь, что основная "фекалия" в этом треде - это твой код, в котором ты, в отличие от предшествующего ему трепа, наглядно продемонстрировал смысл понятия "быдлокодер". Остальную твою аналитику и "срывание покровов" я не читал, извини, мне достаточно главного. В любом случае, будет приятно обсудить с тобой что-нибудь еще. Без обид и большое спасибо за наводку на Tcl/Tk.

mannaz
()
Ответ на: комментарий от mannaz

>основная "фекалия" в этом треде - это твой код

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

>мне достаточно главного

чего тебе достаточно я уже понял, можно не уточнять

>большое спасибо за наводку на Tcl/Tk

не за что

jtootf ★★★★★
()
Ответ на: комментарий от mannaz

да, и вот ещё что. ты сутки рожал недоделанное решение собственной задачи, проявил незнание как event-driven, так и многопоточной обработки (ни однопоточной реализации, ни thread-safe многопоточной от тебя нет), не сделал ни одного существенного замечания по поводу моего кода (хотя было за что), не решился получить задание от меня и вместо обсуждения изошёлся в отмазку "я д'Артаньян, а у вас быдлокод"

научись хотя бы сливаться достойно, что ли

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

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

"Недоделанное решение" было в моей голове уже когда я формулировал задание. А код я тебе, кажется, приводил. Я писал его без Qt, поэтому он скомпилируется успешно, если добавить в начале #include <QtDebug>, а в конце - #include "main.moc". Запускай и дрочи.

mannaz
()
Ответ на: комментарий от jtootf

> ...проявил незнание как event-driven... Ты просто прочитал слово "поток" и испытал какие-то непонятные мне переживания, а также ощутил острую потребность проповедовать евангелие об event-driven "несведущим".

> ...ни thread-safe многопоточной...

Если бы ты не увлекся так сильно п**дежом, чтением между строк и фантазированием, ты бы заметил, что приведенный мною код как раз-таки thread-safe.

> научись хотя бы сливаться достойно

Все, что я пока увидел - это как Tcl со всеми его thread::send'ами сливает Qt по части взаимодействия двух параллельных event loop'ов по всем статьям, а значит твое утверждение, что на систему событий Tcl нужно равняться и молиться - полная фигня. Или ты лямбда-дрочерством решил меня удивить?

mannaz
()
Ответ на: комментарий от val-amart

>> кстати, слотом в PyQt может быть любой callable - а сигналом?
> тоже.

???
Не надо из объявлять в __pyqtSignals__ ???

kitov ★★★
()
Ответ на: комментарий от kitov

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

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.