These are chat archives for boostorg/hana

4th
Mar 2016
Louis Dionne
@ldionne
Mar 04 2016 00:16

@ricejasonf

It kind of looks like map inserts improved too. Is that right?

I did not do any changes to insert, so it shouldn't have improved. But the benchmark for insert is actually broken, since the size of the map in which we're inserting changes. So the improvement you notice should be the improvement of creating the map before we insert in it.

About the whole conversation you guys had on March 1: LMFAO. I am incredibly surprised and pleased by these preliminary results, and I think we should investigate further. I mean, if D turns out to be worse than C++ for compile-time speed, there's a huge problem because the language was apparently designed (in part) to be good for metaprogramming. And D evangelists keep throwing shit at C++ for the compile-times, so that better be based off some real data!

Not that I want a war with D, far from that. But I think this data might point out places where D could improve.
Joshua T. Fisher
@playmer
Mar 04 2016 00:43
Dude, don't make Bright come in here and whoop us.
Louis Dionne
@ldionne
Mar 04 2016 00:45
lol
@ricejasonf Regarding constexpr lambdas, I’ve no idea if Clang trunk supports them, but I’d say no for now. But they’re going to be in C++17 for sure.
And I’ve written a paper to allow lambdas in unevaluated contexts. I’m waiting for the end of the Jacksonville meeting to post it on std-proposal. I’m hoping that it can get in C++17 too at Oulu.
Jason Rice
@ricejasonf
Mar 04 2016 00:50
cool
Jason Rice
@ricejasonf
Mar 04 2016 00:56
I just pulled clang's git master last night and it does not appear to support constexpr lambdas
clambda.cpp:5:16: error: constexpr function's return type '(lambda at clambda.cpp:6:10)' is not a literal
      type
@ldionne any luck with that builtin?
Louis Dionne
@ldionne
Mar 04 2016 01:00
No luck yet. The patch is still under review, but I think the reviewers have other things on their hands.
I also implemented a builting for slicing parameter packs, but I won’t push it for review until the first one is in.
Jason Rice
@ricejasonf
Mar 04 2016 01:01
is it still named nth_element
Louis Dionne
@ldionne
Mar 04 2016 01:01
It’s almost trivial to implement builtins in Clang :p.
No, it got changed to __type_pack_element.
Jason Rice
@ricejasonf
Mar 04 2016 01:03
I was playing with AST matchers. It seems incredibly difficult to get all locations of the use of a type's name.
Louis Dionne
@ldionne
Mar 04 2016 01:11
That, I don’t know!
But writing builtins is a walk in the park. I could never have figured it out myself, but David Majnemer implemented the __make_integer_seq builtin and all I had to do was walk in his footsteps.
Maik Klein
@MaikKlein
Mar 04 2016 01:27
Yeah I was also very surprised lol. I was mostly working for some "toy" example before . This gave me some incentive to do some actual benchmarks.
The fastest way is actually generating strings at compile time because I can avoid recursion that way.
But generating strings is a huge memory hog.
Maik Klein
@MaikKlein
Mar 04 2016 01:32
btw if you are mostly unfamiliar with D, I recently wrote a blog post about the differences in C++ and D. https://maikklein.github.io/2016/03/03/CppAndD/
It's not quite finished yet and my markdown generator seems to be broken :(
Maik Klein
@MaikKlein
Mar 04 2016 01:43
If you are crazy enough to read this and spot some obvious mistake, please let me know
Jason Rice
@ricejasonf
Mar 04 2016 03:01
@MaikKlein I don't know if this is a compiler hack per se, but I made a simple show_if function that is useful for dumping information about a type when a condition is met. https://github.com/ricejasonf/nbdl/blob/master/src/mpdef/ShowIf.hpp
Maik Klein
@MaikKlein
Mar 04 2016 11:35
@ricejasonf No 100% sure what it does, but it seems to force an error when you want to show it right? Not saying its not useful but in D you can give really nice static assert messages because of this. I have the string hack somewhere in my c++ codebase
found it somewhere on reddit
Maik Klein
@MaikKlein
Mar 04 2016 11:43
For example in D you could have function that requires types to be in a specific order. If the user fails you can give him a better error message like static assert(inOrder, "Your input was" ~ YourTypes.stringof ~ " but it requires the types to be in the following order" ~ Types.stringof);
Also in D you can print your types at compile time this is useful for example if you have some recursive metafunction that fails to compile. You can print every recursion at compile time until it really fails, so you know exactly where and why it fails. Not sure if something similar is possible in C++.
Louis Dionne
@ldionne
Mar 04 2016 17:04
I think it’s possible to generate a warning with some useful information at each step of a metafunction. However, it’s definitely nothing but a hack.
Jason Rice
@ricejasonf
Mar 04 2016 17:58
how?
Louis Dionne
@ldionne
Mar 04 2016 18:00
Something like this.
There was also a technique for counting the number of template instantiations at some point. The trick was to generate a warning with the name of the current metafunction when the metafunction is instantiated. Then, you run the compiler and count the number of warnings to know how many times the metafunction was instantiated. I could be wrong, but I think the trick is due to Steven Watanabe.
Jason Rice
@ricejasonf
Mar 04 2016 18:06
Having something like an equality assertion that outputs some information as to why they weren't equal would be very useful.
I would use that show_if and put the two types in separate files, format them, then open them both in vimdiff. It was very tedious.
Louis Dionne
@ldionne
Mar 04 2016 18:08
Something like BOOST_HANA_ASSERT_EQUAL(x, y)?
Jason Rice
@ricejasonf
Mar 04 2016 18:09
what? really!?
oh
yes
lol.. I thought you were referring to an existing feature. :P
Louis Dionne
@ldionne
Mar 04 2016 18:22
No, an hypothetical one. What kind of output would you be looking to have? Something like x and y are not equal. x’s type is … and y’s type is …?
Jason Rice
@ricejasonf
Mar 04 2016 19:30
Yeah, I was actually thinking about something like that, but didn't envision it being as pretty printed. Is that possible?
each type being on it's own line would be cool too
Louis Dionne
@ldionne
Mar 04 2016 19:35
Actually, I don’t think it’s possible to have such a pretty output. In order to have the types show up, we’d need to trigger an error where both the message and the types show up.

The following might work

template <typename T, typename U>
void assert_equal(T const& t, U const& u) {
    BOOST_HANA_CONSTANT_CHECK(hana::equal(t, u));
}

Basically, if both are not equal you'd see a static_assert inside the asser_equal function, and that would give you the type of each argument (probably).