Re: [boost] New New Callbacks Uploaded

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-11-22 15:54:16

From: Kevlin Henney <kevlin_at_[hidden]>
> In message <20001122120939.62bd5d47.gregod_at_[hidden]>, Douglas Gregor
> <gregod_at_[hidden]> writes
> >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?
> 
> We can go a number of ways on this. We need to recognise that for non-
> const cases, unless we require physical const-ness for all function
> objects passed, there is absolutely no way that we can make an arbitrary
> function smart pointer for an arbitrary function object thread-safe and
> lightweight. This means that we have three choices:
> 
> (1) Impose this restriction.
> (2) Separate out the mutability aspect into a separate class, ie
> function_ptr and const_function_ptr. The former is not reference counted
> and the latter requires deep, physical const-ness but can be reference
> counted.
> (3) Not implement reference in the function_ptr at all.
> 
> IMHO, (3) is now the most reasonable option. If we wish to have
> reference counting of an object, then we can provide it using a smart
> pointer. The only problem with this is that most smart pointers,
> including shared_ptr, are restricted to the narrow view of supporting
> only operator* and operator-> wrt pointer-ness.
> 
> If operator() (for, say, 0..2 arguments) is supported (and I guess,
> while we're at it, operator->* as well, but that's a separate
> discussion), this problem goes away. Given that such classes are
> supposed to reflect pointer semantics, this does not seem entirely
> unreasonable.

I'm certainly amenable to these improvements to shared_ptr, but are they
truly necessary?  It seems that for a pointer or a shared_ptr to a
function or to a functor that (*f)() is a legitimate way to make a call.