Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 2019 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 2019 02:04
    pthom commented #432
  • Jan 18 2019 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 2019 22:27
    ricejasonf commented #434
  • Jan 05 2019 06:22
    ricejasonf commented #330
  • Jan 03 2019 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 2019 00:33
    ricejasonf closed #434
  • Jan 02 2019 00:33
    ricejasonf commented #434
  • Jan 02 2019 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Are you sure I can't use hana::common in lieu of std::common_type? The libc++ version on my recently updated mac still has that bug.
that is std::common_type<void, void> does not compile
The suggested change to std::common_type_t was working for me on my linux box because I was using libstd++
Louis Dionne
@ldionne
@ricejasonf Well, you can use it if you want, but it won’t do what you’re looking for. hana::common<hana::tuple<X, Y>, hana::tuple<Y, Z>> is hana::tuple_tag instead of an error. Clearly not what you’re looking for.
It’s fairly easy to implement a sfinae-friendly std::common_type if you don’t need it to allow being specialized for user-defined types.
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
:D
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?