Boost logo

Boost :

Subject: Re: [boost] Interest in a container which can hold multiple data types?
From: Thijs (M.A.) van den Berg (thijs_at_[hidden])
Date: 2015-05-05 02:26:12


> On 05 May 2015, at 05:54, James Armstrong <armstrhu_at_[hidden]> wrote:
>
> So, as it is currently implemented, it doesn't actually make use of
> boost::any or boost::variants. I used a deque<void*> to store addresses of
> the data, and deque<boost::core::typeinfo> to store the data types.
> Therefore, iterating through the container to get the data for datatype T
> simply involves iterating through the deque<boost::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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk