Re: [boost] Interest in a clone_ptr class?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2006-07-05 18:30:17

On 7/5/06, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
>
> I think it's ok to say boost::function is a *not* a very common type.
> It's one of a kind.

What makes you say that? I've used such behavior before and Dave Abrahams
claims he's used it several times. Perhaps in your particular work you don't
need such behavior very often, but there is nothing logically wrong with it.

In OO programming, it is common to deep-clone a little here and there.
> It's not common to do it all the time.

No one is saying you should do it all the time. If you want reference
semantics you may use a shared_ptr or similar solution, and if you need
value semantics you use a clone_ptr or similar solution.

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

Without a clone pointer, you pretty much hit a wall, at least in terms of
simple solutions. One option is to manually create a type which works with
the polymorphic type internally and has value semantics (which is exactly
what clone_ptr would do automatically for you), with the down-side being
that you don't get optimized container implementations unless you also make
those yourself. Another solution may be to add a template parameter which
may be used as a way to specify that you wish to work with dynamically
allocated instances of the type and have value semantics, which forces
an unecessary burden on the coder of the template and is more complex than
simply instantiating the template with a clone_ptr type. Finally, even if
the user is able to alter the template in order to give it such
functionality as was just described, in order to have optimized code you
would have to use explicit template metaprogramming in order to
take advantage of ptr_containers -- using them only when such dynamic value
semantics are required. Even then, due to the differing interface of
ptr_containers from regular containers, you need to do quite a bit of
specialized internal coding to be sure that everything works consistently
between instantiations which use basic containers and those which use
ptr_containers. Keep in mind that you'd have to do all of this just to get
the same functionality and efficient code that you would get by using a
clone_ptr.

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

-- 
-Matt Calabrese