Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ std::move doesn't move anything: A deep dive into Value Categories

0xghost.dev

Post reply on HN
Print view View original

71–80 of 220 posts

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#71

Post by spot5010 »

secondcoming wrote: post #66
j1elo wrote: post #60

> [std::move silently copies const values, because] If something is const, you can’t move from it by definition. Whoever wrote that definition should have a thing or two to learn from Rust. Different language I know, but it proves that it wasn't needed to cause so much confussion and collectively so much time and performance lost. Also, who writes rules like that and ends the day satisfied with the result? It seems u…

What’s the problem? It makes perfect sense to me that a const object cannot be moved from, since it violates the constness. Since constness goes hand in hand with thread safety you really don’t want that violation.

Maybe a compiler error that a const object cannot be “moved”?

That would force the programmer to remove the std::move, making it clear that its a copy.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#73

Post by porise »

MORPHOICES wrote: post #21

[flagged]

Value categories actually just are confusing in a language as complicated as C++. I'm not willing to bet that even senior C++ developers are always going to be able to deduce the correct value category.

And worse, in typical C++ fashion, there is still little guaranteed as far as when std::move will actually cause a move. The implementation is still given a lot of leeway. I've been surprised before and you basically have no choice but to check the assembly and hope it continues to be compiled that way as minor changes make their way into the code base.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#74

Post by epx »

drob518 wrote: post #32

About 28 years ago, I figured out that I’m just not smart enough to use C++. There are so many foot guns and so much rampant complexity that I can’t keep it all straight. I crave simplicity and it always felt like C++ craved the opposite.

I understand the individual rationales of C++ things but I lost the faith on the whole thing.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#75

Post by drob518 »

benreesman wrote: post #56
drob518 wrote: post #32

About 28 years ago, I figured out that I’m just not smart enough to use C++. There are so many foot guns and so much rampant complexity that I can’t keep it all straight. I crave simplicity and it always felt like C++ craved the opposite.

Systems programming in the large is hard, owning the category for decades harder still. Even languages that have tried to fast-follow and disrupt C++ end up looking a lot like C++. There is an irreducible complexity.

I have no problem with systems programming issues. That complexity is essential complexity inherent in the problem itself, regardless of language. I have a problem with C++’s accidental complexity. I find C much more tractable. It certainly has a few of its own footguns, but it has much less accidental complexity.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#76

Post by cjfd »

zbentley wrote: post #68
benreesman wrote: post #56

Earlier quoted context omitted.

Systems programming in the large is hard, owning the category for decades harder still. Even languages that have tried to fast-follow and disrupt C++ end up looking a lot like C++. There is an irreducible complexity.

I hear this a lot, but I don’t really understand how this manifests in language complexity like the stuff in TFA in practice. Like, I can understand how systems programming requiring programmers to think about questions like “how can I proceed if allocation fails? How does this code work in an embedded context with no heap?” is hard and irreducible. But I can’t understand why a language’s choice to impose complex rul…

The difference is that in C one is supposed to do allocations and deallocations oneself. Then move semantics is just pointer assignment with, of course, the catch that one should make sure one does not do a double-free because ownership is implicit. In C++ ownership is indicated by types so one has to write more stuff to indicate the ownership.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#77

Post by j1elo »

pjmlp wrote: post #64
j1elo wrote: post #60

> [std::move silently copies const values, because] If something is const, you can’t move from it by definition. Whoever wrote that definition should have a thing or two to learn from Rust. Different language I know, but it proves that it wasn't needed to cause so much confussion and collectively so much time and performance lost. Also, who writes rules like that and ends the day satisfied with the result? It seems u…

There was no Rust in 2011.

The point is not a comparison with Rust per-se, but the fact that a better implementation of the idea was mathematically and/or technically possible; and the personal opinion that such huge footguns that the language accumulates over the years are maybe signals of having needed more thought to them before they were considered ready.

e.g. if something as simple of a inconspicuous std::move in the wrong place can break the whole assumption about move semantics, then make that impossible to do, or at least do not make it the default happy path, before you consider it production ready. What the heck, at the very least ensure it will become a compiler warning?

Hence the mention to Go and how they follow exactly this path of extending discussion as long as needed, even if it takes 10 years, until a reasonable solution is found with maybe small gaps, but never huge ones such as those explained in this article (plus tens of others in any other text about the language)

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#78

Post by drysine »

knorker wrote: post #65
drysine wrote: post #30

Earlier quoted context omitted.

>After moving a value, it needs to remain in a "valid but unspecified state". No, it doesn't. The standard library requires that for its classes, but not the language. "Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state."[0] [0] https://timsong-cpp.github.io/cppwp/n4950/lib.types.movedfro...

Ok, fair enough. So you're saying if you use the language to write UB, then you get UB? Seems kinda circular. Ok, you're not the same user who said it can be UB. But what does it then mean to same "sometimes it's UB" if the code is all on the user side? "Sometimes code is UB" goes for all user written code.

I mean the language doesn't dictate what post-condition your class has for move-ctor or move-assignment.

It could be

- "don't touch this object after move" (and it's UB if you do) or

- "after move the object is in valid but unspecified state" (and you can safely call only a method without precondition) or

- "after move the object is in certain state"

- or even crazy "make sure the object doesn't get destroyed after move" (it's UB if you call delete after move or the object was created on the stack and moved from).

But of course it's a good practice to mimic the standard library's contract, first of all for the sake of uniformity.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#79

Post by kaashif »

krior wrote: post #23
fooker wrote: post #7

Maybe std::make_movable would have been a slightly better name, but it's so much simpler to write std::move.

thanks to the incredible advances in terms of developer tooling over the last 50 years (i.e. tab-autocompletion) there should be no difference in writing those two.

There is a difference, lots of stuff starts with make_, so lots of possible completions.

Re: C++ std::move doesn't move anything: A deep dive into Value Categories

#80

Post by j1elo »

secondcoming wrote: post #66
j1elo wrote: post #60

> [std::move silently copies const values, because] If something is const, you can’t move from it by definition. Whoever wrote that definition should have a thing or two to learn from Rust. Different language I know, but it proves that it wasn't needed to cause so much confussion and collectively so much time and performance lost. Also, who writes rules like that and ends the day satisfied with the result? It seems u…

What’s the problem? It makes perfect sense to me that a const object cannot be moved from, since it violates the constness. Since constness goes hand in hand with thread safety you really don’t want that violation.

To be honest I agree that it makes sense, at least if we put our hats of puritanism on the conceptual and semantical way of seeing it.

But having std::move silently fall back to a copy constructor is not a good solution.

Post reply on HN