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
> > are needed. One targeting "multithread[ing], generic functors,
> > callbacks". Another targeting "multicast, lifetime and even
> > and ... callbacks."
> My experience as a user overlaps strongly with Karl's, and I tend
> the people that want the other design. My only question, before
> wholesale into the conclusion, is "can we have a few examples of
> applications for the non-reference-counted version, to justify the
> `optimization'?" Probably that's already been discussed; if so, I
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
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
> > >But the points of the design are indeed vastly different.
> > If this is indeed the agreed rationale for boost eventually
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk