Re: [boost] New New Callbacks Uploaded

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-11-22 13:07:42

If reference counting is used then shared_ptr vs. explicit should
be just an implementation detail.

From: Peter Dimov <pdimov_at_[hidden]>
> From: "Douglas Gregor" <gregod_at_[hidden]>
> 
> > 3) We have three different sets of semantics for callback copying -
> explicit reference counting (which your implementation uses), shared_ptr
> reference counting (which I use), and cloning (Peter Dimov's function_ptr).
> Cloning is safest (but inefficient), whereas shared_ptr is currently not
> thread-safe and explicit reference counting could easily be made safe. What
> is the goal of the Boost callback library regarding thread safety vs.
> efficiency?
> <
> 
> Note that, as Kevlin Henney already pointed out, there's more to
> thread-safety than the reference counting.
> 
> callback<void> c(F());
> callback<void> c2(c);
> 
> // thread 1
> 
> c();
> 
> // thread 2, at the same time
> 
> c2();
> 
> Even in a single thread, the cloning and counted callbacks are different.
> It's not only a thread-safety vs. efficiency tradeoff.
> 
> We'll have to decide which behavior we need. Is the efficient copy so
> important? Callbacks are rarely copied, in my opinion. However, a reference
> counted callback has the nice property that its copies are exactly
> equivalent even when the pointed-to function object has state; some STL
> algorithms require this.
> 
> Of course there's always the option of supplying both. :-)
> 
> > 4) Making callback an AdaptableBinaryFunction is a good idea...
> 
> Is it? I've never used the AdaptableBinaryFunction concept. Neither function
> pointers nor lambda/expression.hpp generated function objects are
> AdaptableBinaryFunctions.
> 
> The concept was useful back at the time when the STL was designed (no
> partial specialization) but we have traits and other techniques available
> now.
> 
> --
> Peter Dimov
> Multi Media Ltd.
> 
> 
> 
> 
>