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