Is the C++ && constructor downside temporary?
I looked through my own library and realized I had been adding && constructors to generic templates without considering performance impact. I even had a linter rule to encourage me to do it.
Trying it out I found dozens of class template combinations that had a huge performance penalty. I also unfortunately found a few rare cases where the && constructor added a gigantic advantage. The differences are reduced with optimization, but its unclear if this penalty will ever go away entirely. The compiler is default choosing the && in cases when the alternatives e.g. copy would let the compiler optimize away far more. Profiling let me remove the worst offenders, but required me to add specialized constructors in a few cases. But for stuff like small size optimized vector (data smaller than a pointer), it must be runtime determined which should be used, which seems impossible to solve.
Is this problem temporary while the heroic and long suffering compiler programmers fix it, or did the damned committee make another well intended mistake?
2 comments
[ 2.6 ms ] story [ 17.1 ms ] threadI will advice you to read Nicolai Josuttis' " C++ Move Semantics - The Complete Guide" [1] which describes in great detail all the tips and tricks around move semantics.
P.S.: For any C++ developer out there, in my humble opinion anything written by Nicolai Josuttis is a must-read!
[1] http://www.cppmove.com/
I still cant get around when the standard made mistakes though -_-'but I suspect most of it might be compiler fixable. Pity clang does not allow more inlining control, its been the fix for too many gcc clang perf differences that I've seen.