ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
ldionne on gh-pages
Update benchmarks to 490dbf6 fo… (compare)
#include<boost/hana.hpp>
namespace hana = boost::hana;
int main()
{
static_assert(hana::find_if(hana::make_tuple(
hana::make_tuple(),
hana::make_tuple(),
hana::make_tuple(hana::int_c<0>, hana::int_c<1>),
hana::make_tuple()), hana::length)
==
hana::just(hana::make_tuple(hana::int_c<0>, hana::int_c<1>)), "");
}
/usr/local/include/boost/hana/detail/index_if.hpp:56:50: error: implicit instantiation of undefined
template 'boost::hana::detail::index_if<const boost::hana::length_t &,
boost::hana::detail::pack<boost::hana::tuple<boost::hana::integral_constant<int, 0>,
boost::hana::integral_constant<int, 1> >, boost::hana::tuple<> >, boost::hana::when<true> >'
static constexpr std::size_t value = 1 + index_if<Pred, pack<Ts...>>::value;
int
from a predicate, but it should probably still work.
int
is a Logical
.
static_cast<bool>
s around.
I should probably have a sort prove it's not using the default predicate.
What do you mean?
Would using 'tuple_c' in all of that be okay?
It would, but I'd rather you leave it like it is, since tuple_c
might go at some point. Since it's already written with make_tuple
, there's little benefit to removing it.
tuple_c
and tuple_t
are really convenient and make for more concise, readable code, although I guess I can't see many practical use cases for tuple_c
. I did see it used sparingly in other tests, which is why I didn't completely avoid using it. I definitely hope you keep tuple_t
and range_c
though.
I wanted to make sure that the tests on functions with a default predicate would not accidentally be using the default predicate because of some substitution failure, though that is certainly not the case with the current implementations.
You wanted to make sure that hana::sort(sequence, pred)
wouldn't use hana::sort(sequence)
if the former was invalid? Indeed, that is not the case; it will trigger a hard compile-time error instead.
@ldionne tuple_c and tuple_t are really convenient and make for more concise, readable code, although I guess I can't see many practical use cases for tuple_c. I did see it used sparingly in other tests, which is why I didn't completely avoid using it. I definitely hope you keep tuple_t and range_c though. Is it a performance issue?
Sort of. It would be possible to have something much more performant by using a different representation for tuple_c
and tuple_t
than the representation of hana::tuple
. But I think it would be better to introduce a separate hana::types
sequence or something like that.
count_if
, but I was just exploring different solutions
decay
and do it the way filter
does.