Boost logo

Boost :

From: Nicolas Fleury (nfleury_at_[hidden])
Date: 2003-04-24 16:25:23

Douglas Gregor wrote:
> Yes, it would be very nice to have the ability to rely on the connection
> order. I wouldn't want it to be a preprocessor option (too messy), although I
> have considered a policy-based solution. The policy would dictate the
> underlying storage mechanism, and therefore the ordering semantics. I'm just
> leary of policy-based designs, because first we give a name to something
> ("signal") but we then let its semantics vary wildly without changing its
> syntax; in this case, the changes to the semantics are very subtle, and it
> would be very easy to forget that signal A follows connection order whereas
> signal B does not.
> I think if I were to go the policy-based route, I would want to introduce new
> names. say, publisher/subscriber for the complete unordered versions,
> delegates for connection-ordered versions, etc.

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. 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?

By the way, congratulations for your work on boost::signals and to all
people involved.



Boost list run by bdawes at, gregod at, cpdaniel at, john at