Re: [boost] Heterogeneous Container Library (HCL) Feedback and Testing

Subject: Re: [boost] Heterogeneous Container Library (HCL) Feedback and Testing
From: James Armstrong (armstrhu_at_[hidden])
Date: 2015-06-08 12:12:12

Hey guys,

Thanks for the feedback and questions...

1. did you consider providing the same containers without asking for types?
>    In most of my usage of such containers I don't know which types
>    will get in in the end because the container is shared between different
>    "modules" all inserting data inside.
>   maybe a heterovector<> type that would take anything would be useful to
> others too?
>

This was the original concept.  There is the adapter class which allows
access to any container of type_erased datatypes such as boost::any or
boost::variant.  With this option, one does not need explicitly declare all
types that can be stored.

 2. did you consider other kinds of non-standard containers?
>    I think in the discussion you linked I posted examples of heterogeneous
> containers I use in production
>    that do not have equivalents in std. From memory:
>    a container of 1 value or none for each type, not more, the type(id)
> being the key to access the value.
>

With the adaptor class, any non-standard container can be used.  The other
classes are more or less created for individually for each container type.
There may be a clever way over completely generalize this, but I haven't
thought of a way yet.

 Same applies to boost::variant, and even to "classic OO" - it's just
>> general polymorphism considerations.
>>
>> For example:
>> hcl::vector<Types> v, z;
>> // ...
>> for_each(v, [&](auto &x)
>> {
>>      draw(x);
>>      // ...
>>      if(something(x))
>>          push_back(z, x);
>> });
>> // ...
>> for_each(z, [](auto &x))
>> {
>>      serialize(x);
>> });
>>
>
>
> Ok, I understand. I wish what I was told in this thread was synthesized and
> displayed in the introduction page or in documentation.
> Also, the for_each you presented, perhaps it should be part of this
> library's interface?
>

> Yes, of course it should be in library. I presumed that it was already
> there, but I didn't checked.
> And I think not just for_each - such kind of library should contain
> (several/many) algorithms + containers, not just containers.
>

I agree this would be a very useful feature.  I just finished adding it,
will work on implementing everything within <algorithm>.  I will try to
think of other algorithms that can be applied usefully to the whole
container, any other suggestions?

Have you considered to provide access to some kind of containers views that
> behave like standard containers
>

Yes, there is a method container() which returns a pointer to the
underlying container from which you can use any function designed for the
STL containers.  Now that you bring this up, having this makes pretty much
everything else redundant.  I think I will rename this to get<T,N=0> and
have the interface be as you suggested...much simpler and easier to
maintain.

hv.get<int,1>().push_back(5);

for (auto itr = hv.get<double>().begin(); itr != hv.get<double>().end()
++itr)
  cout << *itr << "\n";

-- 
James Armstrong