Re: [boost] Interest in a "Heterogenous Container" system?

Subject: Re: [boost] Interest in a "Heterogenous Container" system?
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-28 19:55:59

On Mon, Jun 29, 2009 at 11:36 AM, Ross Levine <ross.levine_at_[hidden]> wrote:

> On Sun, Jun 28, 2009 at 5:10 PM, Christian Schladetsch <
> christian.schladetsch_at_[hidden]> wrote:
>
> > One initial issue that may break any interest is that instances put into
> > the
> > container must be of a type T that derives from heterogenous::base<T>.
> >
>
> So, how is this different from using a ptr_container and dynamic_cast?

The instances in a heterogenous::container are added to the container using
the correct allocator, and are duplicated using the correct (and same)
allocator.

   struct base {};
   struct derived : base {};

   typedef ptr_vector<base, heap_clone_alocator, custom_allocator<base> >
vec;
   vec v0;
   v0.push_back(new T(args));    // doesnt use the correct allocator
   vec v1 = v0;                    // clones are not created using the
containers allocator

as opposed to:

   typedef heterogenous::vector<custom_allocator> vec;
   vec v0;
   v0.push_back<T>(args); // uses correct allocator
    vec v1 = v0; // clones created using correct allocator, no custom
clone_allocator required

Of course, I have missed here that for this to work, T must derive from
base<T>.

There is a good case to be made for using std::vector<any> to do a similar
thing. It's much simpler for a start. However, boost::any uses the heap and
doesn't know about or use allocators.

I've made modifications to boost::any, giving it an allocator type. See
http://tinyurl.com/mxh9gm. This allows, for instance:

    typedef any<custom_allocator<char> > any_type;
    typedef std::vector<any_type, custom_allocator<any_type> > vec;
    vec v;
    v.push_back(T0(42));
    v.push_back(T1("foo"));

    vec v2 = v;

And this works - and T0 and T1 don't have to derive from anything.

However, it creates the instances to add on the stack, then copies them into
the container. v.push_back<type>(..args..) doesn't make a copy - it is
constructed in-place using the correct storage provided by the allocator.

This may be a pretty weak argument against a 'heterogenous container' based
on any rather than ptr_container.

Perhaps just making any<> take an allocator type argument would suffice for
this?

Regards,
Christian.