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