Re: [boost] Interest in a clone_ptr class?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2006-07-06 18:12:58

On 7/6/06, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
>
> 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=).

No, it doesn't compare the pointee. You still work with the object through
indirection.

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? You have the same "problem" with any complex user-defined type. This is
not a special case for clone_ptrs. Lot's of types internally use dynamic
memory allocation or have otherwise complex copy operations -- this is
nothing new. So what happens with those complex user-defined types? Such
code still compiles, as it should, it works correctly, and it remains up to
the user to decide if it is fast enough for his given situation.
clone_ptr has all of the same characteristics as any relatively complex object
used in generic
code, only it also has the benefit of easily allowing for
specializations of generic code
which use instantiations of it, not to mention the fact that it allows one
to easily adapt polymorphic types to be able to be used in such generic code
to begin with.

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.

Like your other statements, "immensely expensive" is entirely relative to
the situation and you should not be assuming at the library level that no
one should ever do it. It logically makes sense, it's not slow for all
situations, and it makes generic code much easier to write.
Not only that, but once again, sorting a range of clone_ptrs is no
more inneficient than sorting a range
of any relatively complex type. What's more is, it's also entirely possible
for the clone_ptr library to specialize std::sort for standard container
iterators of clone_ptrs, therefore once again giving you just as efficient
code as ptr_containers, but with entirely generic code.

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.

At least we agree on this.

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

Right, it's not often that it is a major part of a given project,
though the fact that you say "major" does show that it does happen and has
even happened to you. Sure it's not needed for every single project, but
such is the case for most libraries. I've only found myself using variants
in a few projects, I've never used boost::any, I personally don't have a
need for uBLAS, and I don't use all of the algorithms in the standard
library. Just because a library or feature of a library isn't a central part
to many applications does not mean that it is not useful and it certainly
doesn't mean that it is not logically correct nor that its functionality
should be excluded.

-- 
-Matt Calabrese