Since I use move semantics all the time, this is for me the most frustrating thing about C++ full stop. I really wish they'd fix this instead of adding all those compile-time features.

▲

motorest 4 days ago | parent | next [-]

> Since I use move semantics all the time (...)

Everyone who ever uses C++ uses move semantics all the time,including move elision. It's not an obscure feature.

> (...) this is for me the most frustrating thing about C++ full stop.

I've been using C++ for years and I have no idea what you could be possibly referring to. The hardest aspect of move semantics is basically the rule of 5. From that point, when you write a class you have the responsibility to specify how you want your class to be moved and how you want your moved-from class to look like, provided that you ensure you leave it in a valid state.

That's it.

What exactly do you believe needs fixing?

▲

catlifeonmars 5 days ago | parent | prev [-]

How would you fix this in C++?

▲

DLoupe 4 days ago | parent [-]

By adding syntax and semantics for destructible moves, meaning the moved object is removed from its scope (without calling its destructor.)

▲

motorest 4 days ago | parent [-]

I've worked with C++ for a number of years, with a few codebases that were >1M LoC. Never did I stumbled upon a situation where an object was moved and an existing symbol became a problem. I wonder what you are doing to get yourself in that situation.

▲

DLoupe 4 days ago | parent [-]

> I wonder what you are doing to get yourself in that situation.

The problem with the current move semantics is that, compared to e.g. Rust: 1) the compiler generates unnecessary code and 2) instead of just implementing class T you must implement a kind of optional<T>.

Which means, that after all those years of using smart pointers I find myself ditching them in favor of plain pointers like we did in the 90's.

▲

catlifeonmars 4 days ago | parent | next [-]

When you say you must, do you mean that it’s best practice, that or that this is UB or similar?

	▲	motorest 4 days ago \| parent [-]
		> When you say you must, do you mean that it’s best practice, that or that this is UB or similar? I'm not OP, but the only requirements that C++ imposed on moved-from objects is that they remain valid objects. Meaning, they can be safely destroyed or reused by reassigning or even moving other objects into them. I have no idea what OP could be possibly referring to.

▲

motorest 4 days ago | parent | prev [-]

> The problem with the current move semantics is that, compared to e.g. Rust: 1) the compiler generates unnecessary code and 2) instead of just implementing class T you must implement a kind of optional<T>.

I don't know what you mean by "compiler generates unnecessary code" or why you see that as a problem. I also have no idea what you mean by "a kind of optional". The only requirement on moved-from objects is that they must be left in a valid state. Why do you see that as a problem?

	▲	DLoupe 3 days ago \| parent [-]
		The compiler generates code for calling the destructor after the object was moved. This was problem #1. Regarding #2, take Resource Acquisition Is Initialization (RAII) as an example - in RAII, the existence of an object implies the existence of a resource. Now, if you want to be able to move, the object becomes "either the resource exists or it was moved out". As someone else noted in the comments, this affects not only the destructor. Methods cannot assume the existence of the resource, they have to check it first. Kind of like optional<MyResource>.