Re: [sigc] Proposal for standardization in C++ Library TR2 - slot groups

[Edward Diener <eldiener earthlink net>]

> Message: 2
> Date: Fri, 29 Jul 2005 14:08:32 +0200
> From: "Ames Andreas" <Andreas Ames comergo com>
> Subject: Re: [sigc] Proposal for standardization in C++ Library TR2
> To: <libsigc-list gnome org>
> Message-ID:
> 	<E2E0AAD80B459A448015599C384AE9B5D3D546 tndefr-ws00020 tenovis corp lan>
> 	
> Content-Type: text/plain;	charset="iso-8859-1"
>
> Hello,
>
> Douglas Gregor wrote:
>
>  
>
> > On Jul 26, 2005, at 6:37 AM, Murray Cumming wrote:
> >    
> >
> > > Personally, I don't see anything in the boost::bind API that I
> > > dislike, though the "disconnecting all signals of a certain group"
> > > on that page is a little odd.
> > >      
> > Everything that concerns "named slot groups" should be removed from
> > the Boost.Signals API and should not make it into the
> > proposal. Named slot groups have caused a *huge* amount of pain on
> > the implementation side, and have caused Boost.Signals to be much
> > less efficient than it should be.
> >    
>
> does this mean, that the Standard proposal will contain no possibility
> to impose a prioritising on the calling sequence of slots (besides the
> sequence of signal.connect calls)?
>
> IMHO that would be unfortunate, because I think this is one of the
> advantages of Boost.Signals over libsigc++, to have a well defined
> means to do exactly that.  One possible application is for library
> writers to be able to prioritise internal slots over user defined ones
> (which means at least to have two groups of slots).  OTOH, I have no
> real use for signal.disconnect(group_type) (and also
> signal.disconnect(slot)).  Would dropping just these diconnect methods
> help mitigating the implementational woes you described above (I
> haven't yet looked at the implementation, sorry).
I would like to second the notion that some means needs to be provided 
for the ordering of slots for a particular signal. I have found slot 
groups to be a good idea although I understand that efficiency suffers. 
As far as the "*huge* amount of pain on the implementation side" is 
concerned, good implementations often can not avoid being complicated if 
they provide advanced functionality and I do not think difficulty, 
unless this means an unrealistic design, should ever be a factor in 
providing needed functionality.

My suggestion runs along these lines. Keep slot groups, but if a slot 
group is never specified for any of the slots for a particular signal 
there should be a way of maintaining efficiency by not having to map 
slot groups to their slots, and therefore just cycling through each slot 
to be called directly without having to cycle through a mapping of slot 
groups to signals. I believe, although I do not know for sure, that the 
inefficiency occurs mapping slot groups to slots and having to step 
through a map of slot groups to slots in order to call the slots in the 
correct order when a signal occurs. Surely there should be a way, for 
any given signal, of keeping slots in a simple container if no slot 
groups have been specified, while reverting to the mapping of slot 
groups to slots only if the end-user decides to specify a slot group 
with the slot. In this way, for any given signal, those end-users who do 
not use slot groups will not be penalized by any inefficiency while 
those who do will, but will accept it because of the knowledge that slot 
groups slow down the signals library efficiency.