These are chat archives for boostorg/hana

1st
Dec 2015
Maik Klein
@MaikKlein
Dec 01 2015 04:32
How would you "rearrange" a tuple? For example
rearrange(hana::make_tuple(1,1.0f,1.0), hana::tuple_t<double,int,float>) == hana::make_tuple(1.0,1,1.0f);
I have a bit of trouble doing it in a reasonable efficient way because there is no index_of function, find_if seems to return only by copy and map is not ordered.
Jason Rice
@ricejasonf
Dec 01 2015 04:35
details::index_if :P
Maik Klein
@MaikKlein
Dec 01 2015 04:35
I guess I could filter it N times and then concat the result
Louis Dionne
@ldionne
Dec 01 2015 04:36
You could use the index_of function here.
Then you would
auto tuple = hana::make_tuple(1, 1.0f, 1.0);
auto types = hana::tuple_t<float, double, int>;
hana::sort(tuple, [](auto x, auto y) { 
    return hana::index_of(types, hana::decltype_(x)) < 
           hana::index_of(types, hana::decltype_(y)); 
});
Maik Klein
@MaikKlein
Dec 01 2015 04:43
Thanks, is there are reason why this index_offunction is not in hana?
Louis Dionne
@ldionne
Dec 01 2015 04:45
I guess one has to separate between core and non-core functionality. If I had to add every function that finds its use somewhere, the library would grow insanely huge.
There’s this, plus lack of time. Also, I’ll consider adding it if there’s a lot of people asking for it.
Maik Klein
@MaikKlein
Dec 01 2015 04:45
okay, makes sense
Maik Klein
@MaikKlein
Dec 01 2015 04:58

Why did you write

 auto size = decltype(hana::size(iterable)){};

instead of just

 auto size = hana::size(iterable));
Jason Rice
@ricejasonf
Dec 01 2015 05:03
it is in the second comment
to ensure it is not evaluated at run-time. I would think assigning it to a constexpr would do the trick though.
Maik Klein
@MaikKlein
Dec 01 2015 05:23
but this only applies to the drop_while right? Not the the first hana::size?
Louis Dionne
@ldionne
Dec 01 2015 05:26
Technically, it could be incur a non-trivial runtime cost to compute the size of an iterable. The cost is trivial for hana::tuple, but not necessarily for some user-defined container.
Jason Rice
@ricejasonf
Dec 01 2015 05:42
#include<boost/hana.hpp>

namespace hana = boost::hana;

auto rearrange = [](auto xs, auto spec) {
  auto type_map =  hana::unpack(
    hana::range_c<int, 0, hana::length(xs)>,
    [&](auto... i) {
      return hana::make_map(hana::make_pair(
        hana::decltype_(xs[i]), i)...);
    });
  return hana::unpack(spec,
    [&](auto... x) {
      return hana::make_tuple(xs[type_map[hana::decltype_(x)]]...);
    });
};

int main()
{
  BOOST_HANA_RUNTIME_ASSERT(
    rearrange(
      hana::make_tuple(1, 1.0f, 1.0),
      hana::tuple_t<double, int, float>)
    == hana::make_tuple(1.0, 1, 1.0f));
}
I'm guessing that no output means that it works.
Louis Dionne
@ldionne
Dec 01 2015 05:45
Lol, yes.
This is good. If map lookup was implemented efficiently (which it will once I find some time), this would be O(N) compile-time.
That’s optimal.
Jason Rice
@ricejasonf
Dec 01 2015 05:46
:D
Louis Dionne
@ldionne
Dec 01 2015 05:47
Although you should use perfect forwarding for xs. If xs is a temporary, you could move the values into the new tuple instead of making a copy. I guess that’s a detail. I’m out for now anyways, bye!
Jason Rice
@ricejasonf
Dec 01 2015 05:48
gnight
Maik Klein
@MaikKlein
Dec 01 2015 16:10
@ricejasonf that is a nice use case for range_c, thanks
Maik Klein
@MaikKlein
Dec 01 2015 16:22
btw is it possible to avoid template instantiations after every compilation?
using expensive  = expensive_type<T0,T1....TN-1>;

...
int main(){
//change occurs here but expensive didn't change, does it need to be instantiated again?
}
Maik Klein
@MaikKlein
Dec 01 2015 16:33
Seems like this could be "solved" with ccache?
Jason Rice
@ricejasonf
Dec 01 2015 17:48
It looks like ccache works with individual compiliation units.
I once thought that clang was prohibitively slower than gcc, but then I realized I made it with a debug build type. :P