Re: [boost] [hana] Review

Subject: Re: [boost] [hana] Review
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2015-06-28 13:36:40

On 2015-06-27 10:25, Louis Dionne wrote:
>> FWIW, the specific use case I was thinking of was being able to do
>> something like this for an arbitrary tuple t:
>>
>> boost::algorithm::join(hana::to<Array>(hana::transform(t, to_string)), "
>> ")
>>
>> because boost::algorithm::join is expecting a runtime Range rather than
>> a compile-time one.  Array seemed like the most likely candidate for
>> glueing these together.  Do you have any alternative suggestions for
>> such situations?
> 
> I don't know how generally this applies, but I would suggest the following
> for your precise use case:
> 
>     boost::algorithm::join(hana::unpack(t, [](auto&& ...x) {
>         return std::array<std::string, sizeof...(x)>{{
>             to_string(std::forward<decltype(x)>(x))...
>         }};
>     }), " ");
> 
> In addition, this will be lightning fast because unpacking a tuple is very
> cheap and you do not require any layer between your call to to_string and
> the creation of your array, so you minimize the number of functions that are
> instantiated.

Makes sense.  And I guess I can write a function converting to arrays
fairly easily if I want one.

>>> It is true that most other
>>> data structures have unspecified types, but this is similar to how
>> Fusion's
>>> vectors have numbered forms. I'm curious to know how the original code
>>> managed to pass Fusion vectors across interfaces? Did it make sure to
>> only
>>> use the non-numbered fusion::vector<...> form, or something else?
>>
>> Indeed, it only used the non-numbered versions.  There was one part of
>> the code implementing some generic optimization which returned a
>> fusion::vector of parameter choices, and then elsewhere this was being
>> used in a specific case where the number and type of parameters was
>> known, and the resulting parameter vector was just passed around as-is
>> rather than converting it to a more meaningful type.
> 
> Ok. Might this qualify as a borderline usage of Fusion's implementation
> details?

I don't think so.  I believe all Fusion sequences are assignable and
constructible from each other (when they have the same number of and
assignable elements), so even if a pass a vector2<double, double> to a
function
expecting a vector<double, double> it will work fine.

This mutual assignability is very useful in certain cases; for example
it makes it easy to use adapted structs in Boost.Spirit to store the
result of parsing.

John