Message: 2
Date: Fri, 29 Jul 2005 14:08:32 +0200
From: "Ames Andreas" <[EMAIL PROTECTED]>
Subject: Re: [sigc] Proposal for standardization in C++ Library TR2
To: <libsigc-list@gnome.org>
Message-ID:
<[EMAIL PROTECTED]>
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.
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
