05.06.2015 12:20, Andrzej Krzemienski:
For example, It can be used as fast drop-in replacement for std::vector<boost::variant<Types...>> in case when order of elements (across different types) is not important. For instance CAD application may want to process all objects, like draw all of them or apply some filter or serialize. There is no need to pay cost of dynamic dispatch on each element.
A replacement for std::vector<boost::variant<Types...>> in order to get performance -- agreed. Not a "drop-in" one though, I think, because If I change the type, I need to go and change every place that is using it, right?
I agree, "drop-in" is wrong wording. I intended to say that there is great intersection of cases where both are applicable, but HCL is more efficient.
And if I am forced to restructure my code, why would I not just use:
struct variantvector { std::vector<T1> t1; std::vector<T2> t2; };
?
In other words, I am not questioning the idea of the optimization, but the usefulness of the library. My understanding (as of now) is that compared to a hand-crafted solution it offers (1) different names for the sub-containers, and (2) a function that returns the sum of sizes of individual containers.
List of element types can be a parameter to code, so a lot of code can be written in generic way. Adding new type of object (with same generic interface as others) into CAD application would not require to change every piece of code which processes or stores them 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); }); -- Evgeny Panasyuk