#include<boost/hana.hpp>
namespace hana = boost::hana;
int main() {
static_assert(hana::is_embedded<unsigned char, unsigned short>{},
"This works");
static_assert(hana::is_embedded<unsigned short, unsigned char>{},
"This explodes");
}
unsigned short
can’t be converted to unsigned char
without loss.
sizeof(short) >= sizeof(char)
is the only thing mandated.
unsigned short
namespace types_detail = boost::hana::types_detail;
template<std::size_t i, typename... T>
struct nth_type
{
using Indexer = types_detail::indexer<std::make_index_sequence<sizeof...(T)>, T...>;
using type = typename decltype(types_detail::get_elt<i>(Indexer{}))::type;
};
Iterable
s :P
hana::at_c<i>(hana::experimental::types<T…>{})
?
nth_type
into its own detail/
header.
hana::xp::types
. It unpacks to type
s though, so I made my own.
decltype(hana::arg<1>(t...))
is fast enough
Hashable
concept right now. I’ve added documentation, unit tests and I’m trying to see what’s the desired behaviour generally. I really want your/our hash table map to get into the library in time for Boost 1.61
detail::hash_table
as well
detail::hash_table
. I’ll let you know if I need help, thanks!
hana::map
in develop
btw
hana::map
and asking whether it was the one with the hash table. But it’s the current hana::map
in develop using linear search, right?
mpdef::map
is the type-only map, correct?
mpdef::map
.
hana::append(hana::make_tuple(x, y, z), w)
is actually costly.
auto tuple = hana::make_tuple(x, y, z);
auto tuple2 = hana::append(std::move(tuple), w); // moves x, y, and z, which is expensive
auto tuple = hana::make_tuple(x, y, z); // here, reserve more storage on the stack
auto tuple2 = hana::append(std::move(tuple), w); // reuses the same storage as `tuple`, and in-place constructs w into that storage
std::vector::reserve
before pushing back a bunch of elements in the vector
std::aligned_storage
and computing the offsets of the members within that storage at compile-time.
new
at the right place in that storage.