There are no performance critical sections with RVALUES - it's everywhere - it's not isolated. It's not like here is the skinned code on CPU using SSE2, and he

There are no performance critical sections with RVALUES - it's everywhere - it's not isolated. It's not like here is the skinned code on CPU using SSE2, and here is the video decoder, and here is the this and that. The same effect have the overloaded math operators. Yes they are inlined expanded in release (-O9 if you will), but usually not (unless explicitly specified) in debug. So once you start using them more and more, every even simple math operation becomes function call (in debug), to a point where I have seen 6x slowdown (in one of our heavily templated math libraries - that had many types of vectors - direction, position, normal, etc (depending on it's contents, but still all of them 3 or 4 dimensions), and many types of 4x4 and 3x4 matrices (diagonal, LU, identity, etc.). It required so much to type in the interface in the function, that it was heavy burden on the programmer. I much prefer simple float* or double* (or both), rather than some obscured DirectionVector3, or PositionalVector3, DiagonalMatrix44, and such. We are so much led to believe that if we give the compiler the best instructions it'll help us, that we forget that what helps the compiler in this case hurts us as programmers. It's the compiler that should be figuring out these things, not us. And if it can't, then we better find some compromise.