Boost logo

Boost :

Subject: Re: [boost] Heterogeneous Container Library (HCL) Feedback and Testing
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2015-06-05 08:02:47


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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk