Re: [boost] New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-22 15:00:29

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.

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!
:-)

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________