From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-23 09:45:57
--- In boost_at_[hidden], Jesse Jones <jesjones_at_h...> wrote:
> >>>(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.
> >>
> >>Interesting idea, although it seems like the utility of the non-
copyable
> >>callback is pretty limited.
> >
> >There's no restriction of the copyability. If you want reference
> >counting, and you want to manage the risks of inter-thread
sharing, you
> >would write something like
> >
> > shared_ptr< function_ptr<void> > s(new_function_ptr(f));
> > ...
> > s();
>
> Sure, but if 99% of the time I'm wrapping function_ptr up in a
shared_ptr
> I'd begin to wonder why I couldn't just copy the damned callback
object.
The "damned callback object" could just be copied, since it would use
cloning. The reason for wrapping it in a shared_ptr would be solely
to reduce copy overhead, and thus it would be identical to many other
such uses of shared_ptr. I don't think you'd use this 99% of the
time (probably more like 15%, though we're both just pulling numbers
out of a hat), and when you did use it I would think it would be
fairly obvious why you did.
*shrug*
I'm *slightly* leaning towards cloning instead of ref-counting at
this point. In general it's safer, and as pointed out, when this
implementation becomes detrimental you can wrap it in a ref-counting
proxy (whether it be shared_ptr or some other proxy). Going the
other way, for example if it's deemed too dangerous for threading
use, is not really possible.
Bill Kempf