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