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

[Aaron Griffin <aaronmgriffin gmail com>]

On 7/29/05, Ames Andreas <Andreas Ames comergo com> wrote:
> 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've also got some other (unrelated) points to ask about:
> 
> 1) Boost's signal.connect documentation states explicitly that
>    connecting a slot during the emission of the same signal doesn't
>    guarantee either whether the slot is called for the first time
>    during the current emission or during the next emission to follow
>    (which is, IMHO, better than trying to guarantee the call during
>    the current emission).  I didn't find any assertions of this kind
>    for the disconnect.  How will it be handled?
> 
> 2) Similarly I found some statements about recursive signal emission
>    in Boost's docs.  Unfortunately I haven't understood how they are
>    managed (like whether the recursive emission is postponed to after
>    the end of the current emission, or whether the recursive emission
>    is interspersed into the current one).  Furthermore I don't
>    understand the relation of connects and disconnects to recursive
>    emissions.  Would you be so kind to explain me how it (should) work
>    (now and in the standard)?
> 
> 3) I think its clear that connect/disconnect during emission and
>    recursive emission together with the promise of future versions
>    being able to be used in a multithreaded setting (Boost FAQ 2) can
>    easily become a meal that is hard to digest for the user (and I'm
>    certainly not the first one to recognise this;-), especially asthe
>    user currently doesn't seem to be able whether a signal is emitting
>    at a given point in time.  I see two possible extreme positions
>    here:
> 
>    a) Anal retentive:  connect during emission is guaranteed to only
>       invoke the slot *after* the current emission, disconnect during
>       emission is guaranteed to never call the slot again (when
>       disconnect returns) and recursive emission is not allowed.
>       Unfortunately these would impose serious limitations on the
>       user.
> 
>    b) Liberal:  no guarantees about connect/disconnect during emission
>       and recursive emission allowed.  This can make it very hard for
>       the user to know when a given slot is guaranteed to be never
>       called again (i.e. to be able to delete an instance a method of
>       which was used as a callback).
> 
>    What will be the strategy for the standard in this regard?
> 
> 4) Given all the things above but also more generally, I found myself
>    wishing several times, that there would be a means in the signal
>    interface to connect a slot for at most one emission, i.e. the
>    signal disconnects the slot automatically after it was called once.
>    Would you consider this to be a useful convenience?
> 
> 
> TIA,
> 
> aa
> 
> --
> Andreas Ames | Programmer | Comergo GmbH |
> Voice:  +49 69 7505 3213 | andreas . ames AT comergo . com

Hey, I'm just a random subscriber here... 

as for the naming... source/sink would be nicely generic... event
source and event sink... *shrug*, just my 2 cents