Re: [boost] Interest in a clone_ptr class?

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-07-03 18:09:42

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.

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

> But the big point here is that, apart from all of this, even without move
> semantics in the language, efficient containment can be accomplished very
> easily in the form of compliant STL containers, and I'd argue that it can be
> done in a simpler and more intuitive manner than what is provided by the
> current pointer containers and even be exactly as efficient! This can be
> done by just creating the clone_ptr template and then partially specializing
> the standard STL containers rather than working with ptr_container
> containers, as is explicitly allowable per 17.4.3.1 paragraph 1 of the
> standard. Specializations would be fully compliant to the standard, while
> also providing many of the ptr_container optimized operations on top of the
> standard operations. 

It is a lot more work to write an efficient/correct standard container 
library, than to write the pointer container library on top of the 
standard library. So I don't agree with "simpler" here.

> The benefit of this is that the user of the library is
> really only introduced to one new template, the clone_ptr template, and they
> can use that type with any STL container they wish, even with
> ::std::vector, and the implementation may avoid unecessary copies just like
> ptr_vector. The user doesn't even have to be aware of the additional member
> functions unless they need such functionality.

This is not a benefit. std::vector is designed for value semantics, 
boost::ptr_vector for polymorphic semantics. neither can easily replace 
the other.

> This also has several other benefits over the current ptr_containers,
> particularly with respect to writing generic code, as instantiating a vector
> of clone_ptrs can be done exactly as you would a vector of other types,
> making the optimization entirely transparent to the writer of the generic
> code. For instance, imagine a type template whose instantiations encapsulate
> an ::std::vector of a
> type which is specified through an argument of the encapsulating template.
> As an example:
> 
> template< typename Type >
> struct some_type
> {
>   ::std::vector< Type > container;
> };
> 
> Now, imagine that
> someone instantiating the template wishes to have the internal
> container contain
> "animals," where animal is an abstract base class and the user would be
> storing dynamic instances of cats, dogs, etc. which are derived from the
> animal type. This could be desired for some of the same reasons you may wish
> to have a container of variants, but with the restriction of used types
> being those which are any possible children of a specified type rather than
> types which must be individually explicitly specified when instantiating a
> variant. With the clone_ptr concept and the associated specializations, the
> person would merely instantiate the encapsulating some_type template with
> clone_ptr< animal >, and internally the optimized vector implementation
> would be used automatically without any explicit intervention on the part of
> the person using the template nor the person writing the template.
> 
> Without a clone pointer type of concept, it is much more difficult to make
> the code both generic and efficient. 

Depends on your definition of efficient.

> optimizations remain as implementation details
> rather than separate containers and any code already written does not have
> to be changed in order to take advantage of the optimizations.

If you think you doing programmers a favor by muddling the distinction 
between value semantics and polymorphic semantics, I think you're wrong.

-Thorsten