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

["Ames Andreas" <Andreas Ames comergo com>]

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