Boost logo

Boost :

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 -
> >reference counting (which your implementation uses), shared_ptr
> >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
> const cases, unless we require physical const-ness for all function
> objects passed, there is absolutely no way that we can make an
> function smart pointer for an arbitrary function object thread-safe
> 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
> and the latter requires deep, physical const-ness but can be
> 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
> pointer. The only problem with this is that most smart pointers,
> including shared_ptr, are restricted to the narrow view of
> 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
> their own risk, but at least visibly.
> I don't think we need to pollute the function_ptr implementation
> the subtleties of this optimisation. We can, with appropriate smart
> pointers, already do the job. Express independent ideas
> :-)

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at