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

Subject: Re: [boost] Interest in a "Heterogenous Container" system?
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-06-29 19:14:31

Christian Schladetsch wrote:
> * vector<variant<T0, .. Tn>, alloc<variant<T0,...Tn> > requires all
> types that could go into the container to be known at the point of
> declaration, which is contrary to the idea of having a generic
> heterogenous container. Adding an object to a vector<variant> also
> makes a copy and possibly an allocation that does not use the
> containers allocator [1]. map<variant<..>, variant<...> > could make
> sense but it would be a lot of work and difficult to maintain, as a
> variant<> with N types needs N*N comparison functions. 
> 
> * heterogenous::vector<> requires that a type T added to the
> container must derive at some point from heterogenous::common_base.
> This excludes adding builtin types, and means that you either have to
> change your existing class definitions to put them into such a
> container, or use a supplied heterogenous::adaptor<T> system.
> Allowing the addition of builtin types, and types not derived from
> common_base is certainly possible. However, I don't think that would
> be a benefit. In that case, you may's well use vector<any<> 

Deriving from a common ancestor base class is contrary to generic programming.  Knowing all your types ahead of time (at compile time) is not unreasonable, it is the common case for generic programming.  Saying it is contrary to your idea is like saying it is different from what you implemented.  That isn't exactly a strong argument for why people should use heterogenous::vector instead of vector<variant<> >.  

I can tell you people will not be happy to derive from your common base class.  This kind of design relegates it to being useful only to new classes that people write, and not to legacy classes that people use.  That hugely narrows the scope of where it can be useful.  It may be pretty particular to what you want to do and not generally useful in a context where people aren't so picky about which allocator they use and all types in an application tend to use the same one.

Regards,
Luke