Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-22 15:58:26

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <20001122120939.62bd5d47.gregod_at_r...>, Douglas Gregor
> <gregod_at_r...> 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.
> 
> This means that if someone wants to share an object around without
> copying, they can do so explicitly in their declarations but
> transparently wrt usage. And if they wish to share across threads
> (assuming at least thread-safe reference counting), they can do so 
at
> their own risk, but at least visibly.
> 
> I don't think we need to pollute the function_ptr implementation 
with
> the subtleties of this optimisation. We can, with appropriate smart
> pointers, already do the job. Express independent ideas 
independently!
> :-)

This is swaying my opinion.

However, I still don't like the name "function_ptr" here ;).  It's 
not a pointer (I wouldn't even consider it a smart pointer) and it's 
not a function.  Just my own .02 on something no one else probably 
cares about :).

Bill Kempf