bool
instead of hana::bool_
? Because right now I always get errors from somewhere inside hana::eval_if
when I use it with a bool
(that should be a hana::bool_
) and two branches with different types (which there doesn't seem to be a very readable error message for either).
namespace
{
namespace hana = boost::hana;
using namespace hana::literals;
const auto mappy = hana::make_map(
hana::make_pair("foo"_s, 123),
hana::make_pair("bar"_s, 456)
);
typedef std::map<int, decltype(mappy)> BigMap;
BigMap myMap;
template <class T>
struct Struct
{
T value;
};
std::map<int, std::unique_ptr<Struct<BigMap::iterator>>> m;
}
std::unique_ptr::reset
is supposed to take another instance of std::unique_ptr
but that is unrelated to the adl issue. I managed to simplify it a little bit. This should probably be created as an issue on github. I don't know if hana::detail::swap
needs to be named swap
.#include <boost/hana.hpp>
#include <memory>
namespace
{
namespace hana = boost::hana;
const auto mappy = hana::make_map(
hana::make_pair(hana::int_c<0>, 123),
hana::make_pair(hana::int_c<1>, 456)
);
using Mappy = decltype(mappy);
}
int main()
{
std::unique_ptr<Mappy> uptr{};
auto* p = new Mappy();
uptr.reset(p);
}
@jplatte Since hana::bool_
can be implicitly converted to bool
, you could wrap the result in hana::bool_c<bool>
.
#include <boost/hana.hpp>
namespace hana = boost::hana;
template <typename T>
auto check_pred(T const& t)
{
static_assert(hana::IntegralConstant<T>::value,
"Predicate result must be an IntegralConstant.");
return t;
}
constexpr auto is_foo()
{
return true;
}
constexpr auto is_bar()
{
return hana::true_c;
}
int main()
{
check_pred(hana::bool_c<is_bar()>);
check_pred(hana::bool_c<is_foo()>);
}
I don't use hana::eval_if
too much myself though.
develop
and it will make it in the next release. Thanks for the bug report.
IntegralConstant
s actually do :-). However, I’ll provide a better error message in if_
and eval_if
when the two types do not have a common type and the condition is not a compile-time Logical
.
../include/boost/hana/eval_if.hpp:63:25: error: operands to ?: have different types 'std::__cxx11::basic_string<char>' and ‘int’
on GCC, and Clang is even better.
hana::bool_
.
hana::count_if(values, hana::compose(hana::trait<my_trait>, hana::typeid_)) == hana::size_c<1>
.
hana::count_if(hana::tuple_t<types...>, hana::trait<my_trait>) == hana::size_c<1>
as well, which seemed to have the same problem in the context of my library, but I couldn't reproduce the same error message with the simple constexpr example from the count_if
documentation.
==
was not hana::equal
, and instead the implicit conversion to the underlying integral type.
==
, you have to include boost/hana/equal.hpp
.
hana::equal
is quite involved and it’s not always useful (mostly in unit tests). The goal was mainly to reduce compile-times.
circular_permutation
n
s?
n
s (amounts of terms inside a product, for circular_permutation) in the application code I originally created this library for are probably <10, definitely <15.
-DALGEBRA_CXX14_DISABLE_OUTPUT
)
g++ -I. -Ihana/include -std=c++14 -Wall -Wextra -pedantic example.cpp
”x”_var = 3
instead of using var<X>(3)
operator””_s
is implemented. Or you could also use var(“x”_s) = 3
and piggyback on hana::operator””_s
.
TAG(X);
again.
_name_
struct, use Hana.
eval_if
, could always using an id / _ parameter help, so the compiler doesn't try to typecheck unused branches?
decltype(blah){}
which prevents anything in blah from being "used" which can end up discarding a lot of unnecessary symbol stuff.
guard
lazy might help, but you would have to try it out. In C++17, if constexpr
will make it faster, easier, etc..
eval_if
s, just to see if it helps.