Boost logo

Boost :

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at