Re: [boost] Interest in a clone_ptr class?

From: David Abrahams (dave_at_[hidden])
Date: 2006-07-04 17:25:37

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.

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com