These are chat archives for boostorg/hana

11th
Feb 2016
Jason Rice
@ricejasonf
Feb 11 2016 17:47 UTC
#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?
Louis Dionne
@ldionne
Feb 11 2016 18:36 UTC
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.
Jason Rice
@ricejasonf
Feb 11 2016 18:40 UTC
ah.. I was mistaken, thinking short was 8bit
Louis Dionne
@ldionne
Feb 11 2016 18:41 UTC
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.
Jason Rice
@ricejasonf
Feb 11 2016 18:43 UTC
short is minimum 16bit
Louis Dionne
@ldionne
Feb 11 2016 18:44 UTC
Correct, cause it has to be able to represent 0 to 2^16 (see here)
Actually that’s unsigned short
Jason Rice
@ricejasonf
Feb 11 2016 20:58 UTC
  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
Louis Dionne
@ldionne
Feb 11 2016 21:00 UTC
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.
Jason Rice
@ricejasonf
Feb 11 2016 21:01 UTC
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
Louis Dionne
@ldionne
Feb 11 2016 21:03 UTC
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
Jason Rice
@ricejasonf
Feb 11 2016 21:03 UTC
:D
Louis Dionne
@ldionne
Feb 11 2016 21:04 UTC
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.
Jason Rice
@ricejasonf
Feb 11 2016 21:04 UTC
I would guess you could use detail::hash_table as well
let me know if there is anything I can do to help
Louis Dionne
@ldionne
Feb 11 2016 21:20 UTC
Yes, I’ll try to reuse detail::hash_table. I’ll let you know if I need help, thanks!
Jason Rice
@ricejasonf
Feb 11 2016 21:28 UTC
could you also give it a default constructor? :P
Louis Dionne
@ldionne
Feb 11 2016 21:39 UTC
I will
Jason Rice
@ricejasonf
Feb 11 2016 22:09 UTC
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
Louis Dionne
@ldionne
Feb 11 2016 22:10 UTC
So not the hash map, right?
Jason Rice
@ricejasonf
Feb 11 2016 22:10 UTC
no it uses the type
Louis Dionne
@ldionne
Feb 11 2016 22:11 UTC
What do you mean?
Jason Rice
@ricejasonf
Feb 11 2016 22:13 UTC
so its like the hash map except the keys are always types so it doesn't need 'buckets' with multiple values
Louis Dionne
@ldionne
Feb 11 2016 22:14 UTC
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?
Jason Rice
@ricejasonf
Feb 11 2016 22:15 UTC
yes that is the old map in that chart
yes
Louis Dionne
@ldionne
Feb 11 2016 22:15 UTC
Ok, good.
Jason Rice
@ricejasonf
Feb 11 2016 22:15 UTC
lol
Louis Dionne
@ldionne
Feb 11 2016 22:15 UTC
Apart from construction, lookup should be basically the same for both the hash-based map and your mpdef::map.
Jason Rice
@ricejasonf
Feb 11 2016 22:15 UTC
for the most part
Louis Dionne
@ldionne
Feb 11 2016 22:16 UTC
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?
Jason Rice
@ricejasonf
Feb 11 2016 22:17 UTC
like a tuple of run-time values?
Louis Dionne
@ldionne
Feb 11 2016 22:17 UTC
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.
Jason Rice
@ricejasonf
Feb 11 2016 22:18 UTC
is moving the values okay?
Louis Dionne
@ldionne
Feb 11 2016 22:19 UTC
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.
Jason Rice
@ricejasonf
Feb 11 2016 22:24 UTC
gears are turning :P
Louis Dionne
@ldionne
Feb 11 2016 22:25 UTC
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.