Well, it’s really interesting that this is a hack that works, but you’re really fighting the compiler here.
I don’t think that’s a fair take. Keep in mind that the blog post covers a very specific corner case: you want return value optimization but you don’t want a movable type. If you wanted the type to be movable, you just had to went ahead with the happy path and define the move constructor.
What this blog post illustrates is a clever observation over a consequence (possibly unintended) of the way the C++ standard specified this behavior: for RTO to kick in, a necessary and sufficient condition is to have the move constructor declared. Declared but not defined. Oh.
This is making me all the happier I switched to Rust 😂
Except that Rust is not specified in an international standard, so this sort of things can either be downplayed as implementation bugs or implementation-specific quirks.
True, though here the hack is incredibly unintuitive for the programmer. You have to declare the constructor, but then leave it unimplemented. Not to mention the compiler error that should catch this now only occurs at link time, and linking errors are even more cryptic to grok.
When they made RVO mandatory, they should’ve removed the constructor declaration requirement as well, instead of a half-ass solution like this.
As a final nail in the coffin, std::is_move_constructible<> suddenly returns true for this non-move-constructible type 😉
True, though here the hack is incredibly unintuitive for the programmer.
I don’t think this trick is anything other than trivia. The happy path to enable RVO is to provide a move constructor. There is nothing unintuitive about that.
This trivia item just points out that the way the C++ standard is specified, the definition isn’t actually required. That’s hardly relevant.
Not to mention the compiler error that should catch this now only occurs at link time, and linking errors are even more cryptic to grok.
There is nothing peculiar about handling missing definitions. Linkers only flag those if a symbol is actually missing.
When they made RVO mandatory, they should’ve removed the constructor declaration requirement as well, instead of a half-ass solution like this.
I don’t think that your observation makes sense, or is even appropriate to the topic. RVO requires a movable type, and the rule of 5 is a well established aspect of C++. RVO does not change anything in that regard.
I don’t think that’s a fair take. Keep in mind that the blog post covers a very specific corner case: you want return value optimization but you don’t want a movable type. If you wanted the type to be movable, you just had to went ahead with the happy path and define the move constructor.
What this blog post illustrates is a clever observation over a consequence (possibly unintended) of the way the C++ standard specified this behavior: for RTO to kick in, a necessary and sufficient condition is to have the move constructor declared. Declared but not defined. Oh.
Except that Rust is not specified in an international standard, so this sort of things can either be downplayed as implementation bugs or implementation-specific quirks.
True, though here the hack is incredibly unintuitive for the programmer. You have to declare the constructor, but then leave it unimplemented. Not to mention the compiler error that should catch this now only occurs at link time, and linking errors are even more cryptic to grok.
When they made RVO mandatory, they should’ve removed the constructor declaration requirement as well, instead of a half-ass solution like this.
As a final nail in the coffin, std::is_move_constructible<> suddenly returns true for this non-move-constructible type 😉
I don’t think this trick is anything other than trivia. The happy path to enable RVO is to provide a move constructor. There is nothing unintuitive about that.
This trivia item just points out that the way the C++ standard is specified, the definition isn’t actually required. That’s hardly relevant.
There is nothing peculiar about handling missing definitions. Linkers only flag those if a symbol is actually missing.
I don’t think that your observation makes sense, or is even appropriate to the topic. RVO requires a movable type, and the rule of 5 is a well established aspect of C++. RVO does not change anything in that regard.