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

Subject: Re: [boost] Heterogeneous Container Library (HCL) Feedback and Testing
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2015-06-05 08:28:51

2015-06-05 14:02 GMT+02:00 Evgeny Panasyuk <evgeny.panasyuk_at_[hidden]>:

> 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);
> });

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?

Regards,
&rzej