Boost logo

Boost :

From: Jesse Jones (jesjones_at_[hidden])
Date: 2000-11-23 03:07:25


>>>(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.
>>
>>Or perhaps the body copy semantics can be special cased more intelligently.
>>Maybe using some sort of traits mechanism. For example, it's pretty silly
>>to clone a functor wrapping a method call.
>
>I presume that the default would have to err on the side of safety.
>Although is no need to copy member or non-member function wrappers,
>there is an issue over the amount of specialisation involved to meet the
>expectations, eg pretty much all function object types in the standard
>and I guess many parts of the Lambda library. How much coupling do we
>want?

We could rig it so that the Lambda library didn't couple at all to the
callback class. All we have to do is stick some sort of thread trait
somewhere and let Lambda specialize it.

> I think that the amount of configuration involved would put me off
>this solution.

Yeah, I haven't thought about it in depth so I don't know how workable it
is, but it's worth considering...

>>>(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.

  -- Jesse


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk