On 7/4/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
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.
Again, calling such an operation "super slow" and "a beast" is entirely premature and is up to the user to decide. Copying vectors or lists is always potentially a costly operation, regardless of whether or not it is a container of dynamically allocated elements -- this is not some special case. Further more, if a user decides that a vector of vectors of clone_ptrs is too costly for their given situation, they can do similar to what they would do with ptr_containers, only instead of making a ptr_container of ptr_containers, they make it a container of clone_ptrs of containers of clone_ptrs. Again, with this you can get the same performance as a ptr_container. Aside from all of this, the example you are giving -- resizing beyond the capacity of the vector, is generally a non-issue anyway as people who are concerned about speed here most-likely wouldn't be optimizing a resize-beyond-capacity operation, but rather they would not resize beyond the capacity, just like they would avoid it with any other type in times where they are concerned about speed. In cases where having a constant capacity is not feasible, they would use a deque instead, again, just like they would with other types. Short of all of that, they can go further and have a container of clone_ptrs of containers and get the same overall functionality that they would with a ptr_container of ptr_containers. No new problems, no new performance issues, no new containers. Optimization is fine, and again, all of this allows for just as efficient code as ptr_containers, but the difference here is that the syntax for doing so is consistent with the rest of the language and is much easier to use in order to produce efficient generic code, and it doesn't require the user to learn additional container types. To me it seems win-win for almost all uses, having very few down-sides. -- -Matt Calabrese