move() and forward() are terse enough.
Implement them as language features? Possibly. But it might encourage their over-use. I suspect that's why they're implemented as they are.
250ms fixed cost of compile time is pushing the boundaries of reasonable.
It's more than that; that's just all that was explicitly quantified in the blog post originally. There are also per-call costs and per-instantiation costs.
15% compile time improvement makes this sound much more reasonable. Maybe a future standard could provide canonical macro alternatives for these two functions!
move()andforward()are terse enough. Implement them as language features? Possibly. But it might encourage their over-use. I suspect that's why they're implemented as they are.I don't see the macros as worth it.
Plorkyeran 11 points · Sep 2020
The advantage of the macros is compile time and better debugger behavior, not terseness.
pork_spare_ribs 3 points · Sep 2020
Better debugging behaviour in unoptimised builds sounds reasonable. 250ms fixed cost of compile time is pushing the boundaries of reasonable.
evaned 5 points · Sep 2020
It's more than that; that's just all that was explicitly quantified in the blog post originally. There are also per-call costs and per-instantiation costs.
u/Minimonium linked these benchmarks showing a 16 second, 14%, speedup by making this switch in Boost.Hana.
pork_spare_ribs 2 points · Sep 2020
15% compile time improvement makes this sound much more reasonable. Maybe a future standard could provide canonical macro alternatives for these two functions!
atilaneves 1 points · Sep 2020
I get annoyed when compiling a file takes 250ms in total.