On 05 May 2015, at 05:54, James Armstrong wrote:

So, as it is currently implemented, it doesn't actually make use of boost::any or boost::variants. I used a deque to store addresses of the data, and dequeboost::core::typeinfo to store the data types. Therefore, iterating through the container to get the data for datatype T simply involves iterating through the dequeboost::core::typeinfo until a type match is found, then casting the void* to a T* for the corresponding index.

There are definitely different ways to take the idea, and maybe there is use for multiple types of heterogeneous containers. The way this container is setup has the advantage (depending on your viewpoint) that you do not have to explicit declare what data types the container will store up front. This could be useful in some context where, for instance, you are pulling information from a database where you don't quite know up front whether certain fields will be numeric or character data until you've queried the db. This container can allow you to pop in whatever data-type the result is, without having to explicitly list out every possibility up front.

Yes that's nice. There are pros and cons of being explicit vs flexible, so there are use cases for both versions. Most of the times you know the types you'll use in your code, and being explicit make things more safe and faster. Eg if I were to apply a "rotate" operation to all shaped in the example then the compile would eliminate rotate calls to all circles because that operator was empty. I'm not sure if you can get that level of efficiency with type erasure. I tested it against an old school container of base classes and static casting to derived, and that was much slower.