NVRO being optional annoys me. I’m always debating whether I should std::move the return value just in case, but if the compiler performs NVRO (which it probably does), this may be a pessimization right? Ugh.
I think you should never std::move return values. Afaik every modern compiler does NRVO and manually moving prevents it. And on the offchance you need to use a compiler that optimizes less, that one copy most likely is the least of the performance concerns.
Afaik every modern compiler does NRVO and manually moving prevents it.
Yeah this is what bothers me. std::move could make things worse, but not if the alternative is a copy. But you’re probably right that any self-respecting compiler nowadays would do NRVO.
Well the test3 example FTA gives a case where NRVO would not happen because of the conditional return value. Are you suggesting that you need not std::move even in this case?
That’s fascinating.
NVRO being optional annoys me. I’m always debating whether I should
std::movethe return value just in case, but if the compiler performs NVRO (which it probably does), this may be a pessimization right? Ugh.I think you should never
std::movereturn values. Afaik every modern compiler does NRVO and manually moving prevents it. And on the offchance you need to use a compiler that optimizes less, that one copy most likely is the least of the performance concerns.Yeah this is what bothers me.
std::movecould make things worse, but not if the alternative is a copy. But you’re probably right that any self-respecting compiler nowadays would do NRVO.I think compiler move return value by default, so even without NRVO you should never move a return value when it’s a local non reference variable.
Well the
test3example FTA gives a case where NRVO would not happen because of the conditional return value. Are you suggesting that you need notstd::moveeven in this case?I would still say “no” since they are local objects and they are gonna be moved from implicitly anyway