| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
I would undestand what is the advantage to use signal/slots if you have virtual methods for event handler ? Regards, Jefferson. -- [ signature omitted ]
On Tuesday 11 March 2008, Jefferson Costa wrote: > I would undestand what is the advantage to use signal/slots if you have > virtual methods for event handler ? In a non-signal-slot environment (eg. Java) try to use the same (unchanged) button class to trigger different responses. It won't work. Now, after you have written about two dozen lines of code spread over two new classes to do this, compare it with those two simple lines: connect(button1,SIGNAL(clicked()),this,SLOT(action1())); connect(button2,SIGNAL(clicked()),this,SLOT(action2())); ...and now decide which one is more convenient for the programmer. ;-) The right answer (and applying it to your programming) earns you a few more hours of spare time. Have fun with your winnings! Konrad
Attachment:
Attachment:
pgp3MjCgn4xKR.pgp
Description: PGP signature
Message 3 in thread
On tirsdag den 11. Marts 2008, Jefferson Costa wrote:
> I would undestand what is the advantage to use signal/slots if you have
> virtual methods for event handler ?
There are several differences between these two, and some are quite subtle.
The biggest difference is actually a conceptual one: An event is something
that must go to the particular object, and this usually implements a
one-to-one information stream. Signals and slots are completely open for as
many connections to/from any object, and implement a many-to-many information
stream.
Another big difference is that you can get information about slots and signals
in the QMetaObject. You can't do that with events. This means you can do
dynamic method invocation on slots, and that is not (at least easily)
available on events, which are just virtual functions.
Event handlers are implemented using the standard object oriented methodology,
whereas the signals and slots implement a visitor pattern.
Event handlers have a common paradigm for arguments: There is only one, a
pointer to a single object that has a clear rule for when it is deleted.
You could almost implement one of these using the other. I just don't see the
point of doing so.
So, this really isn't a question of the advantage of one over the other, but
more a question of which of the two is more appropriate for the problem at
hand.
I hope this helps your understanding.
Sincerely,
Bo Thorsen.
--
[ signature omitted ]
Message 4 in thread
Ok. Very interesting. And i see a third way to do that: The Auto-Connect,
like voi on_<object>_<signal>();
So, there is three ways to implement it. Is there others ?
Regars,
Jefferson.
Em Tue, 11 Mar 2008 11:11:46 -0300, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx>
escreveu:
> On tirsdag den 11. Marts 2008, Jefferson Costa wrote:
>> I would undestand what is the advantage to use signal/slots if you have
>> virtual methods for event handler ?
>
> There are several differences between these two, and some are quite
> subtle.
>
> The biggest difference is actually a conceptual one: An event is
> something
> that must go to the particular object, and this usually implements a
> one-to-one information stream. Signals and slots are completely open for
> as
> many connections to/from any object, and implement a many-to-many
> information
> stream.
>
> Another big difference is that you can get information about slots and
> signals
> in the QMetaObject. You can't do that with events. This means you can do
> dynamic method invocation on slots, and that is not (at least easily)
> available on events, which are just virtual functions.
>
> Event handlers are implemented using the standard object oriented
> methodology,
> whereas the signals and slots implement a visitor pattern.
>
> Event handlers have a common paradigm for arguments: There is only one, a
> pointer to a single object that has a clear rule for when it is deleted.
>
> You could almost implement one of these using the other. I just don't
> see the
> point of doing so.
>
> So, this really isn't a question of the advantage of one over the other,
> but
> more a question of which of the two is more appropriate for the problem
> at
> hand.
>
> I hope this helps your understanding.
>
> Sincerely,
>
> Bo Thorsen.
>
--
[ signature omitted ]
Message 5 in thread
The auto connect is just a shortcut to set up an automatic connection. It's
still signals and slots.
Bo.
On tirsdag den 11. Marts 2008, Jefferson Costa wrote:
> Ok. Very interesting. And i see a third way to do that: The Auto-Connect,
> like voi on_<object>_<signal>();
> So, there is three ways to implement it. Is there others ?
>
> Regars,
> Jefferson.
>
> Em Tue, 11 Mar 2008 11:11:46 -0300, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx>
>
> escreveu:
> > On tirsdag den 11. Marts 2008, Jefferson Costa wrote:
> >> I would undestand what is the advantage to use signal/slots if you have
> >> virtual methods for event handler ?
> >
> > There are several differences between these two, and some are quite
> > subtle.
> >
> > The biggest difference is actually a conceptual one: An event is
> > something
> > that must go to the particular object, and this usually implements a
> > one-to-one information stream. Signals and slots are completely open for
> > as
> > many connections to/from any object, and implement a many-to-many
> > information
> > stream.
> >
> > Another big difference is that you can get information about slots and
> > signals
> > in the QMetaObject. You can't do that with events. This means you can do
> > dynamic method invocation on slots, and that is not (at least easily)
> > available on events, which are just virtual functions.
> >
> > Event handlers are implemented using the standard object oriented
> > methodology,
> > whereas the signals and slots implement a visitor pattern.
> >
> > Event handlers have a common paradigm for arguments: There is only one, a
> > pointer to a single object that has a clear rule for when it is deleted.
> >
> > You could almost implement one of these using the other. I just don't
> > see the
> > point of doing so.
> >
> > So, this really isn't a question of the advantage of one over the other,
> > but
> > more a question of which of the two is more appropriate for the problem
> > at
> > hand.
> >
> > I hope this helps your understanding.
> >
> > Sincerely,
> >
> > Bo Thorsen.
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 6 in thread
On Tuesday 11 March 2008 02:19:35 Jefferson Costa wrote:
> I would undestand what is the advantage to use signal/slots if you have
> virtual methods for event handler ?
One of the advantages is that the signal slot mechanism does not need compile
time type. You could store that information in a text file, xml file,
database, whatever and connect it lateron.
It only needs a QObject, so anywhere in your code you could do something like:
connect(parent(), SIGNAL(somesignal), this, SLOT(someslot)).
This is not possible with virtual functions, unless they're all present on
QObject in the first place.
Also, it allows using plugins, as in the designer, exposing these signals and
slots and be used from the designer. You can write your own plugins, with
their own signal and slot signatures
foo(int, int, int, double, MyType, YourType)
I'd like to see you do that with virtual functions when you cannot even
concieve of MyType and YourType.
Bottom line is that when using virtual functions you always need to know the
actual interface (this usually means header files). Using signals and slots
you don't. This allows for some very generic programming, and also as a
little bonus, less #includes which can save significantly on compilation
time.
HIH and Happy coding,
Eric
>
> Regards,
> Jefferson.
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 7 in thread
Jefferson Costa wrote:
> I would undestand what is the advantage to use signal/slots if you have
> virtual methods for event handler ?
With virtual methods you can react to your own widgets events; if you want
to react to *some other* widget's events, then you have to use either
signal/slot or perhaps an eventFilter.
Signal/slot provides an infrastructure how to (relatively) comfortably plug
widgets together and use signal/slots as the glue. The donät need to know
about the being glued together.
HTH
Christoph
--
[ signature omitted ]