The move constructor that you have to declare, even though you don't want anyone to actually call it - The Old New Thing
https://devblogs.microsoft.com/oldnewthing/20230612-00/?p=108329Open linkView original on discuss.tchncs.dehttps://devblogs.microsoft.com/oldnewthing/20230612-00/?p=108329Open linkView original on discuss.tchncs.de
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?