Boost :

mathias.gaunard_at_[hidden]

----
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.
As code, it appears as such:
poly_obj<Base> b = Derived();
poly_obj<BaseBase> b2 = b; // b2 is a copy of b (Derived::Derived(const 
Derived&) was called), implicit upcasting
Motivation
----------
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 
in boost by neophytes because it allows easier and simpler programming, 
without the usual issues in regards with pointers people are used to.
However it might not always be the right solution, and I believe I have 
seen it being used even when sharing wasn't needed at all.
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.
Pure value objects make the program more easy to understand by making it 
more deterministic and thus to maintain.
Value semantics is what most of the standard library is built upon. And 
thus it makes more sense to use the standard containers with poly_obj 
than with shared_ptr, because this is kind of semantics they were 
designed for.
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.
(the get() member function returns a real C++ reference to the object)
I believe this is not really a good thing. And the only way to fix that 
is to make the virtuality of the constructors intrusive.
I thus came up with the following design:
class Foo
{
    ...
public:
     virtual void clone(void* p) const
     {
         return new(p) Foo(*this);
     }
     virtual std::pair<std::size_t, std::size_t> size_and_align() const
     {
         return std::make_pair(sizeof(Foo), 
boost::alignment_of<Foo>::value);
     }
};
(Of course, a 'mixin' can be used to not have to repeatly rewrite such 
code for every class)
It should be quite important to stabilize that interface, so remarks are 
welcome.
It is judged very important that the user should be able to define how 
the memory is allocated. Since virtual templates aren't possible, an 
allocator cannot be passed to the 'clone' member function.
The solution I came up with allows to clone the object on already 
initialized memory, and provides the necessary information to know what 
that memory should be like.
It is, however, still not really possible to use standard allocators, 
which need to know the type.
An additional member for moving might also be needed.
Code
----
Some initial code is available on the vault, in "Utilities".
http://www.boost-consulting.com/vault/index.php?direction=0&order=&directory=Utilities
Note that the tests are just here to show how it's to be used, and are 
not real tests at all.
No support for moving yet, and no support for using custom allocators 
either (since an allocator interface would have to be agreed upon, first).
operator= also needs a facility to compare types, and thus it uses RTTI. 
Since I've seen a few times people who complained about the usage of 
RTTI, there is also a hack to replace it.