Re: [boost] Proposal: Polymorphic Value Objects

From: Edd Dawson (lists_at_[hidden])
Date: 2007-09-03 16:01:22

Mathias Gaunard wrote:
> I am proposing the addition of the following very simple utility in 
> Boost, and thus request a very informal and early review of the ideas 
> and design.
> 
> 
> Idea
> ----
> 
> The idea is to provide an utility that allows the manipulation of 
> dynamically typed objects, that may be of any derived type of a given 
> base type, as if it were a simple base object.
> This is quite similar to a smart pointer that does deep-copying, but 
> without any pointer or memory allocation exposed.
> 

[ 8< -- snip -- ]

> The motivation for this is that often usage of dynamic typing with 
> inheritance and inclusion polymorphism often means explicit memory 
> allocation and deallocation, and thus are often a source of unsafety.
> shared_ptr is one way to solve the problem, yet the shared object 
> doesn't behave as a normal C++ object: it has entity semantics (= 
> reference) instead of value semantics (= copying).
> 
> shared_ptr is highly regarded as being one of the most useful utilities 

[ 8< -- snip -- ]

> As a matter of fact, it appears that sharing is rarely needed, and makes 
> the program more difficult to understand. (sharing between threads also 
> cause a few issues). Indeed, the object is freed when it is no longer 
> used, but it's not always trivial to trace whether it's still used or 
> not. Sharing also means you can expect side-effects coming from anywhere.

I'm confused. Surely the whole point of shared_ptr is to relieve the programmer 
of the burden of worrying when its still used. And what side effects do you 
speak of?

> Pure value objects make the program more easy to understand by making it 
> more deterministic and thus to maintain.

How are programs made more deterministic?

> Design
> ------
> 
> To implement that utility, there is a need for a way to call the 
> appropriate copy constructor and move constructor for the right types, 
> even with type erasure.
> There is no standard way, however, to simply make constructors virtual, 
> so there is a need to do such a thing.
> 
> A few implementations of clone_ptr, a similar idea, that I have seen 
> tried to make this non-intrusive.
> This of course adds some overhead, mainly in size of the object, but it 
> has another downside: it requires to assume that the types of the 
> objects being inserted in it are their real types.
> 
> Thus, writing that kind of code:
> poly_obj<Base> b = poly_obj<Base>(Derived()).get();
> Would produce type splitting.

Actually, if you have the static type at the point of construction, you're set.

Here's one I just threw together: http://rafb.net/p/bIQgtl24.html

Edd