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
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
