Re: [boost] Interest in a clone_ptr class?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2006-07-05 04:41:21

On 7/4/06, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> 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