#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");
}
Is that right?
Yes;
unsigned short can’t be converted to unsigned char without loss.
This whole embedding thing is convoluted and far from usual C++, and perhaps I should have designed it differently. However, several things are based on this and the general behaviour of cross-type comparisons, so I couldn’t easily change it without doing major changes to the library. I think simplifying this should be a long term goal for a Hana v2.
ah.. I was mistaken, thinking short was 8bit
I think
sizeof(short) >= sizeof(char) is the only thing mandated.
Oh, actually no. The standard only mandates ranges that must be representable with those types.
short is minimum 16bit
Correct, cause it has to be able to represent 0 to 2^16 (see here)
Actually that’s
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;
};
something like that would be cool for those struggling to implement their own
Iterables :P
Why not use
hana::at_c<i>(hana::experimental::types<T…>{})?
Regardless, it would probably be a good idea to extract
nth_type into its own detail/ header.
I'm just playing around, but I did start out using
hana::xp::types. It unpacks to types though, so I made my own.
for my use case
decltype(hana::arg<1>(t...)) is fast enough
Ok. Btw, I’m working on the
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
:D
Once the map is done, I think we should do the same for set. It should be a smaller job since the hard part (figuring out compile-time hash tables) you already did.
I would guess you could use
detail::hash_table as well
let me know if there is anything I can do to help
Yes, I’ll try to reuse
detail::hash_table. I’ll let you know if I need help, thanks!
could you also give it a default constructor? :P
I will
I made a specialized map for strictly compile-time, default constructible keys, using type comparison. http://fullstackblog.com/hbench/
that is the
hana::map in develop btw
So not the hash map, right?
no it uses the type
What do you mean?
so its like the hash map except the keys are always types so it doesn't need 'buckets' with multiple values
Oh, right. I was speaking of
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?
Your
mpdef::map is the type-only map, correct?
yes that is the old map in that chart
yes
Ok, good.
lol
Apart from construction, lookup should be basically the same for both the hash-based map and your
mpdef::map.
for the most part
Hey I have one interesting challenge for you: How would you append to a tuple without having to copy the whole content of the tuple into a new one, with the new element at the end?
like a tuple of run-time values?
You’d have to somehow already have some storage allocated on the stack and then use that storage when appending.
Yeah, imagine a tuple of some type that would be expensive to move, so that
hana::append(hana::make_tuple(x, y, z), w) is actually costly.
is moving the values okay?
Ideally we wouldn’t have to:
auto tuple = hana::make_tuple(x, y, z);
auto tuple2 = hana::append(std::move(tuple), w); // moves x, y, and z, which is expensive
So we’d need to somehow pre allocate storage when creating the tuple:
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
I might have a solution, and I’m preparing a series of articles in which I’ll explore something similar to this. But I just wanted to throw the problem at you so it idles in the back of your head.
Conceptually, this is similar to calling
std::vector::reserve before pushing back a bunch of elements in the vector
But we don’t have anything similar for tuples.
gears are turning :P
lol
hint: It’s possible to implement tuple using
std::aligned_storage and computing the offsets of the members within that storage at compile-time.
To construct the members, you use in-place
new at the right place in that storage.