this post was submitted on 16 Aug 2023
16 points (100.0% liked)
C++
1805 readers
2 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well, it's really interesting that this is a hack that works, but you're really fighting the compiler here.
This is making me all the happier I switched to Rust 😂
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.