Re: [boost] Interest in a clone_ptr class?

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-07-06 16:39:31

Matt Calabrese wrote:
> On 7/5/06, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:

>>I can't imagine what kind of generic code you're talking about.
> 
> 
> 
> The type of code generic code that I already posted an example of. For
> instance,
> you have a template parameterized by type which internally uses value-semantics
> with said type, perhaps even having a container of a parameterized type in
> the implementation. Then, in a given situation you wish to use that template
> in order to work with varying children of a specific polymorphic type. With
> a clone pointer type, all you have to do is instantiate the template with a
> clone_ptr of the desired type and everything works fine. Not only that, but
> it is also efficient at runtime, since even if, for example, an STL
> container of them is used in the implementation, the respecitve
> specialization is also automatically used.

The problem I have with that is that such "generic" code cannot assume 
anything about the stores type. It must be manipulation of the container 
itself.

Even for such tasks I can easily imagine problems depending on how you 
specify clone_ptr. (For example, does < compare the pointee=).

Performance-wise, even doing something like

container::value_type v = cont.back();
cont.push_back( v );

is going to be very efficient for vector<int>, but very costly for 
T=clone_ptr<U>. So the amount of generic algorithms you intend to write
at the container level is certainly not easy.

And consider sort() on a collection of clone_ptr<T>. This will be 
immensely expensive without move-semantics whereas ptr_vector<T>::sort() 
stays efficient.

And I'm still convinced that specializing the entire container library 
from std:: is a very bad idea, maintenance wise and header-wise. Your 
header for clone_ptr would be *huge*, because if you don't include all 
container specializations, one risk that the specialization is not 
picked up.

> If you not willing to accept that value-based programming and OO
> 
>>programming are different disciplines, we will never agree on this one.
>>Period.
>>
> 
> 
> Until you understand that object oriented programming is an entirely
> orthogonal issue from programming with value semantics or reference
> semantics, we will never agree on this one. 

I guess not.

> There is absolutely nothing
> about object oriented programming that logically restricts it
> to reference-based programming, nor has there ever been such a restriction.
> I'm not sure how you are coming to such a conclusion.

I have worked with C++, Java and C# for years, also on big projects, and 
object cloning have never been a major part of the code, although the 
code was OO all the way. Never. Once in a while you need to copy
the entire colelction of shapes or what-ever. But it's never the main 
application.

-Thorsten