Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-07 11:14:22

--- In boost_at_[hidden], Beman Dawes <beman_at_e...> wrote:
> 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
> are needed. One targeting "multithread[ing], generic functors, and
> callbacks". Another targeting "multicast, lifetime and even event
> and ... callbacks."

Well, the two components are radically different, though related.
The smaller concept is what's currently needed by Boost. Down the
road I'd expect some people would find a need for the larger concept,
though it's definately geared towards GUI applications and so may not
be applicable to everyone's needs. I trust in Karl's experience and
expertise when he says (and explains why) that the larger concept
would be hindered by implementing it on top of the smaller concept.
So I'd agree that the two are definately seperate, but the question
of whether or not Boost needs both depends on what Boost users feel
they need. Personally, I'd like to see both, but we at least need
the smaller version.

Bill Kempf

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