Hacker News: sprocketz

New comment by sprocketz in "Move in C++ without a std:move"

sprocketz — Wed, 02 Sep 2026 14:51:43 +0000

My little trick is to think of them as "oh, I accidentally made an lvalue from an actual rvalue here because a name was introduced, so I need to cast (i.e move() or forward()) back to an rvalue again", that's why i have them as macros: MOVE_CAST and FORWARD_CAST defined as static_cast (also avoids blowing up compile times). I never think in terms of "moving this object".

New comment by sprocketz in "Move in C++ without a std:move"

sprocketz — Wed, 02 Sep 2026 13:42:45 +0000

I figured any half decent compiler already do plenty of flow and liveness analysis on everything for register allocation, dead code elimination and what not.

Maybe it's the guaranteed elision that makes it a problem, like you can't fail the analysis, but then maybe you go the rust route - fail to compile and urge the programmer to rewrite their code so it accepts it.

Make it opt in with [[must_elide]] so old code still works I guess.

New comment by sprocketz in "Move in C++ without a std:move"

sprocketz — Wed, 02 Sep 2026 13:06:56 +0000

And the most important idea: destructive moves. Since C++ doesn't track lifetimes it has to leave the object in a "valid state" after a move and the destructor still runs which has to have a check if it should do something or not.

New comment by sprocketz in "Move in C++ without a std:move"

sprocketz — Wed, 02 Sep 2026 13:01:10 +0000

What is that makes NVRO so much more difficult to implement? Why couldn't they mandate that just like RVO? Do compilers literally just special case a simple return statement of a direct construction or something?