Re: New New Callbacks Uploaded

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