Re: [boost] Interest in a clone_ptr class?

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-07-04 17:59:32

David Abrahams wrote:
> Thorsten Ottosen <thorsten.ottosen_at_[hidden]> writes:
> 
> 
>>Matt Calabrese wrote:
>>
>>>On 7/3/06, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
>>>
>>>
>>>>As long as C++ does not have move-semantics, the semantics of clone_ptr
>>>>seems to be far too expensive to be useful: std::vector<clone_ptr<T>>
>>>>will have to re-clone all objects on buffer expansion, whereas
>>>>boost::ptr_vector<T> will not.
>>>>
>>>
>>>
>>>Firstly, while it is true that it may be expensive to copy such objects for
>>>some users, it certainly isn't "far too expensive" for all users, as many
>>>programmers likely are simply not bound by the copy operations of the types
>>>they may be using with it -- an assumption either way made at the library
>>>level, in my opinion, is a mistake in design.
>>
>>Well, we usually prefer "as efficient as possible" for libraries.
> 
> 
> I don't know who "we" is supposed to refer to.  Your philosophy seems
> to be the same as the one you used to forbid copying of
> ptr_containers: if you think the user _might_ be unhappy with the
> cost, don't provide the capability through the usual interface.  This
> approach has no precedent in Boost or the STL.

Right, because neither Boost nor the STL has ever dealt with anything 
but value-semantics.

>>>If value semantics are desired for a given type, a programmer
>>>shouldn't have to jump through hoops using a type with reference
>>>semantics and explicit cloning in order to get the functionality
>>>they want -- this is refering to the types in general, not just
>>>with respect to them being stored inside of containers.
>>
>>If value semantics are desired, then why not provide them directly? 
>>Having polymorphic types with value semantics is fairly rare.

> Only because it's more work to implement than it should be.  I've had
> to do it several times.  And, just to point at one familiar example,
> see boost::function.

I fail to see the relevance of boost::function is this context. It's not 
exactly exposing any virtual functions in its interface.

-Thorsten