These are chat archives for boostorg/hana

23rd
Nov 2015
Jason Rice
@ricejasonf
Nov 23 2015 19:35
I was only using for_each and equal, but I ended up not needing them outside of my Path class. Just as an exercise though, I tried implementing Iterable and length, and then just unpack. In both cases, as well as accessing storage directly, the compiled release target was identical (just by looking at the size). I also implemented equal. What is the recommended approach for having the operator==? Should I just implement it in my class? I suspect you wouldn't suggest specializing detail::comparable_operators.
Jason Rice
@ricejasonf
Nov 23 2015 19:49
I forgot. I will end up needing to make it Foldable
to serialize it
Louis Dionne
@ldionne
Nov 23 2015 19:50
Just as an exercise though, I tried implementing Iterable and length, and then just unpack. In both cases, as well as accessing storage directly, the compiled release target was identical (just by looking at the size).
What do you mean?
To get operator==, you should implement your own and then forward to hana::equal (or implement operator== as you wish). You should not use anything in detail.
Jason Rice
@ricejasonf
Nov 23 2015 19:53
mean by what? the fact they were the same?
I just like the fact that enhancing it didn't cause any code bloat
Louis Dionne
@ldionne
Nov 23 2015 19:56
Sorry, I’m wondering the code gen of what was affected? Do you mean that manipulating your Path class through Hana’s unpack and length was no worse than manipulating it through the Path’s storage directly?
Jason Rice
@ricejasonf
Nov 23 2015 19:57
yes
Louis Dionne
@ldionne
Nov 23 2015 19:58
Oh, well that’s pleasing to hear!
It means the compiler is doing its job properly.
Jason Rice
@ricejasonf
Nov 23 2015 20:00
Yeah, every time I make my own wrapper for something it typically adds to the target. I'm probably doing something wrong, but it has made me trigger shy as far as making wrappers go.
Louis Dionne
@ldionne
Nov 23 2015 20:06
Right. Hana’s dispatching system (e.g. when you write your own unpack_impl) is really only a compiler frontend abstraction. It’s all inline template functions and universal references, and it would be very surprising if the optimizer couldn’t see through it. That being said, the actual implementation of your Path class may very well cause bloat to be generated, because heterogeneous objects do not seem to play very nicely with the optimizer (when they are large).
Jason Rice
@ricejasonf
Nov 23 2015 20:10
forgive me, but what do you mean by 'heterogenous objects'? like a class containing members or just tuples in general?
Louis Dionne
@ldionne
Nov 23 2015 20:11
Ok, that was an horrible language abuse. I meant structs in general, lol. But tuples are even worse, because sometimes the optimizer has trouble seeing that they’re really just dumb structs.
Basically, what I’m saying is that if you pass huge damn structs around by value, you’ll pay for it.
But with Hana, it’s very easy to generate insanely large ones via tuples.
Jason Rice
@ricejasonf
Nov 23 2015 20:13
ah. I probably just need to be more strict with forwarding. btw Is static_cast<Xs&&> better than using std::forward (if you don't mind me asking)
Louis Dionne
@ldionne
Nov 23 2015 20:15
I don’t mind at all. You should use std::forward because it makes the intent clear. However, since Hana is a core library whose compile-time performance is of utmost importance, I decided to start using static_cast after measuring a large compile-time reduction. This was caused by the mere instantiations of the std::forward functions, and the fact that Hana uses forwarding a lot.
See 540f665e5132d75bbf6eda704638622727c0c01c
Eh, I guess I mean boostorg/hana@540f665. I thought it would link automatically.
Jason Rice
@ricejasonf
Nov 23 2015 20:19
That looks like a pretty big difference.
I'm making a library but I don't know if I would call it a core library
Louis Dionne
@ldionne
Nov 23 2015 20:21
Honestly, you probably won’t see a difference. I would be surprised if you needed to use forwarding as much as Hana does. The reason why Hana forwards so much is mostly because of the wrappers around methods, i.e. the xxx_impl.
In all cases, that’s definitely not the first place where I would try to get a compile-time improvement.
This is a pretty tiny optimization, overall.
Jason Rice
@ricejasonf
Nov 23 2015 20:23
Right. I've actually pretty much ignored compile-times so far.
Louis Dionne
@ldionne
Nov 23 2015 20:24
It’s the good approach. If you notice problematic compile-times, then try to optimize.
Jason Rice
@ricejasonf
Nov 23 2015 20:28
Is it recommended to specialize on concepts? I don't remember if I saw this somewhere in the manual before.
like the way unpack_impl has a specialization for Iterables witha default length_impl
Louis Dionne
@ldionne
Nov 23 2015 20:31
In general, no. I think it’s only required for Sequence.
Jason Rice
@ricejasonf
Nov 23 2015 20:31
ah, k