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-29 20:59:47

On Tue, Jun 30, 2009 at 11:14 AM, Simonson, Lucanus J <
lucanus.j.simonson_at_[hidden]> wrote:

> [snip] 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.

Sure, but as much as we'd perhaps like to forget about it, it is true that
C++ supports OO style as well as generic programming, especially in GUIs and
other object hierarchies. In these cases, you either cannot know or don't
want to know all the types that may be used ahead of time. This is the basic
premise of loose coupling.

> 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<> >.

What I implemented came from discussions with Thorsten about how to deal
with cloning in ptr_containers. To solve that, I ended up with a system that
I saw may be of general interest and could possibly stand orthogonally to
ptr_container.

Using variant<> instead is certainly possible, but you could then also argue
that ptr_container is pointless over a vector<variant>. But the truth is
that a ptr_container is much more flexible than a vector<variant>. Given
that heterogenous is based largely on ptr_container, the same is true there.
Even so, I can't see how associative containers can work with variant<>, and
it also doesn't provide a means to have a custom clone operation.

> I can tell you people will not be happy to derive from your common base
> class.

I understand and empathise with that position. That is why, in my initial
email, I stated:

   "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>."

However, I do not see any possible way to provide correct cloning of types,
given just a base pointer, without having this constraint. That said, the
system allows you to your own base, rather than heterogenous::common_base.

        template <class Derived, class Base = common_base>
        struct base

But even here, currently common_base is needed at the bottom somewhere.
Perhaps this too could be conceptualised, rather than using a fixed abstract
base class supplied by the library.

> 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.

Christian> 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.

The idea of heterogenous::adaptor<T> is to make a 'heterogenous type' from
an existing type T which you cannot modify.

>  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.

Perhaps you are right and this is too specific. Even so, isn't there a
general need for a heterogenous containers (both sequence- and
associative-types) that have proper value semantics, can be cloned
correctly, use a single allocator, and uses emplace construction for object
insertion?

There are some interesting properties of real heterogenous containers that I
think you may find surprising.

> Regards,
> Luke

Cheers,
Christian