Matt Calabrese wrote:
On 7/5/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> 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