|
Boost : |
From: Beman Dawes (beman_at_[hidden])
Date: 2000-12-06 21:03:34
At 02:50 PM 12/5/2000 -0800, Karl Nelson wrote:
>... Trying to make a system which some how builds up to
>lifetime and multicast is too much work over starting the
>multicast system from scratch. Trying to meld all these ideas
>into one system is too much to chew.
>
>Build your system to be fast and efficient without trying to
>add the other baggage or somehow plan for some sore of massive
>expansion later. When done, look at the problem set which is not
>covered, build the best system for needed to cover those regions.
>Then define how those two systems should interact. They will be
>very stringent but likely workable.
>
>Sigc++ covers multicast, lifetime and even event queuing
>and trivially could do callbacks. It can be expanded to
>multithread but the cost goes up. Using with generic functors
>is just dangerous.
>
>The boost system is targeted at multithread, generic functors,
>and speedy callbacks. Expanding it to multicast, lifetime, or
>event queuing likely will give poor result.
As someone who doesn't understand the discussion, I'd like to hear if the
other participants agree with Karl's conclusion that two library components
are needed. One targeting "multithread[ing], generic functors, and speedy
callbacks". Another targeting "multicast, lifetime and even event queuing
and ... callbacks."
>On the surface these look like loads of overlap with both having
>adaptors, creation, and providing a way to call a single callback.
>But the points of the design are indeed vastly different.
If this is indeed the agreed rationale for boost eventually supplying two
components rather than one, please, please, save it away somewhere so we
don't have to try to reconstruct it later!!!
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk