Matt Calabrese wrote:
On 7/3/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
If value semantics are desired, then why not provide them directly? Having polymorphic types with value semantics is fairly rare.
I'd say fairly rare simply because the tools to make it simple and efficient were never there.
Or because it is rarely needed.
non-dynamically allocated objects with value semantics. I know I keep repeating myself, but I'm not sure exactly what it is that you don't understand.
I think I understand perfectly what you're trying to do, but I fail to see the need for it. I have never had the need to treat these two types of objects the same way. Never.
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.
Simpler for users, not necessarily for the programmer of the library.
I don't agree with the statement that it is easier for users either.
Anyone who knows the STL knows how to use a given type in an STL container. Using a clone_ptr in an STL container can be done with the same code one would write with any other type, though with an optimized internal implementation entirely transparent to the user. All a programmer needs to learn is the interface of a clone_ptr and they get container optimizations without any extra work. Then, if they really need to optimize further, they can look at additional operations provided by the specializations.
You overlook that quite a few polymorphic types are not even clonable, hence you can't provide copy-semantics for them, but only make them moveable.
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.
Alright, then by what definition of efficient are you refering to?
I think the idea of specializing the entire container library is very bad, to say the least. For example, std::vector< std::vector< clone_ptr<T> > > will still behave like a super slow beast without move-semantics.
when such semantics are required. Keep in mind that this is not intended as a replacement for ptr_containers, I just offer it as a suggested replacement for a subset of usage of them which can potentially make working with generic code much easier for both library writers and users.
I fail to see the usage to be common enough to justify a rewrite of the all the containers. That is a *major* low-level task.
If you think you doing programmers a favor by muddling the distinction between value semantics and polymorphic semantics, I think you're wrong.
I appreciate your criticisms, but I still disagree entirely.
Ok, fair enough. -Thorsten