boostorg/hana

Your standard library for metaprogramming

Louis Dionne

@ldionne

I would just write my own if I were you, perhaps?

Jason Rice

@ricejasonf

ahh I see. I'll look into that or maybe dip into boost/type_traits idk

or abandon mac altogether :P

one problem after another Undefined symbols for architecture x86_64

Louis Dionne

@ldionne

Installing your own libc++ is very easy. Take a look at .travis.yml if you want to see how to do it in a local directory.

Maik Klein

@MaikKlein

I have almost completely replaced my mpl with hana and everything worked out really well so far :)

Louis Dionne

@ldionne

@MaikKlein That’s really cool!

Maik Klein

@MaikKlein

what is the equivalent version of hana for std::get<Type>(some_tuple);?

I saw that there is find_if but I don't think it returns a reference

Maik Klein

@MaikKlein

My workaround was to transform the tuple with ref, filter the tuple to the type that I want and return the value with hana::front

Louis Dionne

@ldionne

@MaikKlein If you want to index a sequence by keys other than indices, use a hana::set or a hana::map.

Then, std::get<Type>(tuple) will be map[hana::type_c<Type>].

Maik Klein

@MaikKlein

is there a way to convert between a hana::tuple and std::tuple?

A library that I use outputs pairs and tuples and I want to unpack them with hana::unpack

Louis Dionne

@ldionne

You can use std::tuple with Hana’s algorithms by including <boost/hana/ext/std/tuple.hpp>, and std::pair by including <boost/hana/ext/std/pair.hpp>. See the documentation section on external adapters.

Otherwise, if you truly need to convert to/from std::tuple, hana::to<hana::ext::std::tuple_tag>(some_hana_tuple) will do the trick. The other way around, hana::to<hana::tuple_tag>(some_std_tuple) should also work.

Maik Klein

@MaikKlein

Hh damn I missed that part of the docs, thanks that is exactly what I need.

Louis Dionne

@ldionne

No problem.

Maik Klein

@MaikKlein

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

details::index_if :P

Maik Klein

@MaikKlein

I guess I could filter it N times and then concat the result

Louis Dionne

@ldionne

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

Thanks, is there are reason why this index_offunction is not in hana?

Louis Dionne

@ldionne

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

okay, makes sense

Maik Klein

@MaikKlein

Why did you write

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

instead of just

 auto size = hana::size(iterable));

Jason Rice

@ricejasonf

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

but this only applies to the drop_while right? Not the the first hana::size?

Louis Dionne

@ldionne

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

#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

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

Louis Dionne

@ldionne

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

gnight

Maik Klein

@MaikKlein

@ricejasonf that is a nice use case for range_c, thanks

Maik Klein

@MaikKlein

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

Seems like this could be "solved" with ccache?

Jason Rice

@ricejasonf

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

Jason Rice

@ricejasonf

So I've been trying to warm up to generating several permutations of arbitrarily structured 'messages' based on several tests applied to a spec. I decided to play around with making different implementations of the following psuedo code (from wikipedia :P):

function is_prime(n : integer)
    if n ≤ 1
        return false
    else if n ≤ 3
        return true
    else if n mod 2 = 0 or n mod 3 = 0
        return false
    let i ← 5
    while i×i ≤ n
        if n mod i = 0 or n mod (i + 2) = 0
            return false
        i ← i + 6
    return true

here is my first attempt with a bunch of nested if_s

#include<boost/hana.hpp>

namespace hana = boost::hana;

constexpr auto if_ = hana::if_;
template<int c>
constexpr auto int_c = hana::int_c<c>;
template<bool c>
constexpr auto bool_c = hana::bool_c<c>;

auto primality_test = [](auto n)
{
  return
    if_(n <= int_c<1>, hana::nothing,
      if_(n <= int_c<3>, hana::just(n),
        if_(n % int_c<2> == int_c<0> || n % int_c<3> == int_c<0>, hana::nothing,
          if_(hana::is_just(hana::while_(
            [&](auto just_i) {
              return hana::maybe(bool_c<false>,
                [&](auto i) {
                  return bool_c<i * i <= n>;
                }, just_i);
            },
            hana::just(int_c<5>),
            [&](auto just_i) {
              return hana::maybe(hana::nothing,
                [&](auto i) {
                  return if_(n % i == int_c<0> || n % (i + int_c<2>) == int_c<0>, hana::nothing,
                    hana::just(i + int_c<6>));
                }, just_i);
            })), hana::just(n), hana::nothing)))); //practically lisp!
};

int main()
{
  static_assert(decltype(primality_test(int_c<1009>)){} == hana::just(int_c<1009>), "");
  static_assert(decltype(primality_test(int_c<1010>)){} == hana::nothing, "");
}

Jason Rice

@ricejasonf

In my second go, I am working on chaining these conditions instead of nesting. I was going to try to avoid using while_, but it doesn't seem there is any other way without generating all of the possible i values up front in a range or something.

Is while_ the best choice here?

Where communities thrive

People

Repo info

Activity