Re: New New Callbacks Uploaded

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 
components 
> are needed.  One targeting "multithread[ing], generic functors, and 
speedy 
> callbacks".  Another targeting "multicast, lifetime and even event 
queuing
> 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