Stewart, Robert wrote
Yes, containers of shared_ptrs would work, but they add overhead that isn't always wanted. Then use containers of unique_ptr, like you should (shared_ptr
"like you should" is a rather strong statement.
If you want a container of pointers with the container owning the pointees, in order to use inclusion polymorphism for example, then a container of unique_ptr is the standard solution, while a container of shared_ptr is not only overkill since it adds a lot of useless overhead, it also gives the wrong semantics. A container of clone_ptr is a more elegant solution if you can't use move semantics, since it actually has the right ones. You may want to implement it using COW however since non move-aware containers can do a lot of spurious copies.
All of those schemes mean that the container interface is in terms of those wrapper types rather than raw pointers. They will work, but they complicate the code using the elements. I'm not suggesting that is onerous, but the interface isn't as simple.
How are smart pointers, smart references or smart objects (whatever you want to call them) any more difficult to use than pointers or objects?
The heterogeneous containers, being implemented as class templates, need only be defined in terms of operations supported by its parameterizing types. This merely looks like a container of Adobe.Poly.
I've never used anything from the Adobe library. You may be right, but why shouldn't Boost provide a clean solution for itself?
Adobe.Poly is a generic type erasure tool, that can implement any type erasure for a given interface given as a parameter. boost::function, boost::any, and a few others from boost are simply special cases of Adobe.Poly (function with a callable interface, any with an empty interface). Boost could have something similar to Adobe.Poly (and I believe it eventually will -- the real issue is how to specify the interface), but this should be completely separate from the very idea of a container, since coupling the two has less advantages than making them separate and is actually harder to design, write and maintain.