From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-04-24 16:57:33
On Thursday 24 April 2003 05:25 pm, Nicolas Fleury wrote:
> There's one advantage to the preprocessor option however. Suppose you
> have an event-driven framework based on signals. You might want the
> more optimized implementation, and therefore not condition-ordered, for
> most programs, but would like to make unit tests for this framework, and
> to ease their creation use the condition-ordered implementation. It
> would however be an incomplete unit test since it would test only with a
> specific order.
Given the subtle problems that can come from differences in slot ordering, I
think this option may give one a false sense of security. It looks right in
the unit test, but it's behavior is different in the real application. That
> If the performance is very similar for the
> connection-ordered solution, I guess this would not be an issue. Do you
> have an idea what would be the cost in performance for
> connection-ordered signals?
I don't know the cost off-hand, but I think it isn't too high. Actually, using
a list of slots and a mapping from group names to iterators into the list
could actually improve performance in many common cases but would give
order-of-connection slot ordering... I'll have to try that out.
> By the way, congratulations for your work on boost::signals and to all
> people involved.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk