[Boost-users] signal slot flexibility

From: Frank Maddin (frankmad_at_[hidden])
Date: 2004-09-07 13:36:07

Hi,

 

I have some questions about signals.  

 

If I add a function to both Hello and World, from the "Hello World"
example, called alternate() and set up signals like so:

 

            boost::signal<void (Hello*) > sig_h;

            boost::signal< void (World*) > sig_w;

 

            sig_h.connect(boost::mem_fn(&Hello::alternate));  

            sig_w.connect(boost::mem_fn(&World::alternate));

 

I have to define two different signals since the object type is part of
the signal definition.  Is there an easy way to get a single signal to
call the alternate() function of both Hello and World?

 

I recently found this signal slot solution.
http://www.codeproject.com/cpp/ElmueSignalsandSlots.asp

There is an extra level of indirection here, in that you define a slot
that points to the function.  I'd be interested to see what people on
this forum think about this solution. If I understand things correctly,
this solution doesn't seem to fit into the categories listed in the
"Choice of Slot Definitions" docs.

 

Also a general signal slot question.  What are the main reasons why
developers don't use an inherited pure interface for every callback
type?  A signal would be a template class with a list of pointers to the
interface and some methods to operate on the list.  Not flexible enough?
Doesn't scale well to larger uses?  Time spent calling virtual
functions?  I saw this in the boost signal docs that might apply - "the
use of a large number of small adaptor classes containing virtual
functions has been found to cause an unacceptable increase in the size
of executables (polymorphic class types require more code than
non-polymorphic types)". 

 

Thanks

Frank