Hacker News new | ask | show | jobs
by locknitpicker 162 days ago
> I thought "move doesn't move" was a fairly common C++ mantra at this point.

It is. The fact that std::move is just a cast and that move constructors are expected to transfer resources are basic intro to C++ topics, covered in intro to constructors.
1 comments
LexiMax 162 days ago
It's far too late to put the genie back in the bottle, but I am morbidly curious as to why the standards committee didn't choose an approach that made moves destructive.
link
jandrewrogers 162 days ago
It solves some rare edge cases where the destruction of the moved-from object must be deferred -- the memory is still live even if the object is semantically dead. Non-destructive moves separate those concerns.

There is a related concept of "relocatable" objects in C++ where the move is semantically destructive but the destructor is never called for the moved-from object.

C++ tries to accommodate a lot of rare cases that you really only see in low-level systems code. There are many features in C++ that seem fairly useless to most people (e.g. std::launder) but are indispensable when you come across the specific problem they were intended to solve.

link
LexiMax 162 days ago
As someone who has actually had to launder pointers before, I would characterize gremlins like std::launder as escape hatches to dig your way out of dilemmas specific to C++ that the language was responsible for burying you under in the first place.
link
tialaramex 162 days ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n13...

"There is significant desire among C++ programmers for what we call destructive move semantics [...]"

"In the end, we simply gave up on this as too much pain for not enough gain."

link
LexiMax 162 days ago
groan

> When dealing with class hierarchies, destructive move semantics becomes problematic. If you move the base first, then the source has a constructed derived part and a destructed base part. If you move the derived part first then the target has a constructed derived part and a not-yet-constructed base part. Neither option seems viable. Several solutions to this dilemma have been explored.

Add this to my "C++ chose the wrong kind of polymorphism to make first-class" tally.

link
locknitpicker 161 days ago
> Add this to my "C++ chose the wrong kind of polymorphism to make first-class" tally.

Is it really the "wrong kind of polymorphism" if it isn't causing any problem and it didn't prevented rolling out features such as semantic support for move constructors?

link
dataflow 162 days ago
What would you want to happen when an object that's on the stack is moved? Do you want its destructor to run, or not? If not, how exactly do you want that to no longer occur? And what do you want to happen if the stack object is moved in multiple places? How willing are you to pay a performance or UB penalty for these?
link
locknitpicker 161 days ago
> How willing are you to pay a performance or UB penalty for these?

OP wasn't even able to frame an actual problem. So why is this blend of vacuous criticism even entertained?

link