These are chat archives for boostorg/hana
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
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).
operator==, you should implement your own and then forward to
operator==as you wish). You should not use anything in
lengthwas no worse than manipulating it through the Path’s storage directly?
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).
structs in general, lol. But
tuples are even worse, because sometimes the optimizer has trouble seeing that they’re really just dumb
structs around by value, you’ll pay for it.
static_cast<Xs&&>better than using
std::forward(if you don't mind me asking)
std::forwardbecause 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_castafter measuring a large compile-time reduction. This was caused by the mere instantiations of the
std::forwardfunctions, and the fact that Hana uses forwarding a lot.
unpack_implhas a specialization for Iterables witha default