Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-08 09:53:42

--- In boost_at_[hidden], "David Abrahams" <abrahams_at_m...> wrote:
> 
> ----- Original Message -----
> From: "Beman Dawes" <beman_at_e...>
> >
> > 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."
> 
> My experience as a user overlaps strongly with Karl's, and I tend 
to believe
> the people that want the other design. My only question, before 
buying
> wholesale into the conclusion, is "can we have a few examples of 
real-world
> applications for the non-reference-counted version, to justify the
> `optimization'?" Probably that's already been discussed; if so, I 
missed it.

Check out the implementation for the Win32 Boost Thread Library in 
the file archives.  This specifically was what raised the current 
round of discussion on this topic.  Sigc++ style "callbacks" are not 
appropriate here for several reasons:

1)  Multi-cast bloats the concept when single-cast is all that's 
needed.
2)  Lifetime management also bloats the code with little or no 
benefit in this case.
3)  Lifetime management also requires intrusive code into the 
function object wrapped making impossible to wrap generalized 
function objects, which is fine for many things, but not for the 
general concept needed by threads.

The thread example is only one such real world example, though it's 
the easiest for me to point out here.

> >  >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!!!
> 
> Don't worry, egroups saves all our messages ;-)

It should be in the documentation of the concept(s), however.

Bill Kempf