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 is meant for shared ownership or making it easy to fix broken code), or use the boost pointer containers if you can't (which move semantics mostly render obsolete). You could alternatively use boost.any, adobe.poly, clone_ptr, or whatever is relevant.
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. As far as I can see, the only advantage of heterogeneous containers is when dealing with node-based containers. A heterogeneous node-based container would have the opportunity to store the object directly into the node, while a container of boost.any or anything like that would only have a pointer to the object in the node. I believe however a better approach to benefit from that would be to define a dynamically-sized object protocol and have containers extended to support it. (obviously, data structures that rely on the fact the size of all instances of the same type is the same couldn't do that)