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