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

91–100 of 220 posts

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

#91

Post by ziml77 »

spot5010 wrote: post #71
secondcoming wrote: post #66

Earlier quoted context omitted.

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.

It's weird that they made a mistake of allowing this after having so many years to learn from their mistake about copies already being non-obvious (by that I mean that references and copies look identical at the call sites)

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

#92

Post by HarHarVeryFunny »

shmerl wrote: post #2

I always understood move as moving ownership, so it's not a misnomer. > std::move is like putting a sign on your object “I’m done with this, you can take its stuff.” Which exactly is moving ownership.

Well, no, because CAN take isn't the same as WILL take.

Changing something to an rvalue means it'll now match a move constructor, but there is no guarantee a move constructor will be used, even if defined, because you've got classes like std::vector that are picky and are explicitly looking for a noexcept move constructor.

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

#95

Post by vlovich123 »

tsimionescu wrote: post #34
masklinn wrote: post #19

Earlier quoted context omitted.

> Can you show an example of what you mean? void foo(std::unique_ptr && p) { std::random_device rdev {}; auto dist = std::uniform_int_distribution (0, 1); if (dist(rdev)) { auto pp = std::move(p); } }

This is exactly what I meant as irrelevant. If I call `foo(std::move(my_unique_ptr))`, I know for sure, statically, that my_unique_ptr was moved from, as part of the function call process, and I can no longer access it. Whether `foo` chooses to further move from it is irrelevant.

aside from what others wrote, it’s also non local - whether std::move even does anything is dependent on the signature of foo - if foo takes it by const& you may think you’ve transferred ownership when it hasn’t actually happened.

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

#96

Post by [deleted] »

dbcpp wrote: post #90
Fiveplus wrote: post #38

Earlier quoted context omitted.

The reason performance-noexcept-move-constructor is not enabled by default is likely because blindly applying noexcept is dangerous if the underlying logic isn't actually exception-free. If you let clang-tidy slap noexcept on a move constructor that does end up throwing (perhaps because it calls into a legacy member or allocates memory internally), the runtime behavior changes from caught exception to std::terminate(…

I would argue performance-noexcept-move-constructor should always be on. Move constructors should almost always be noexcept since they typically just move pointers around and don't do allocations normally.

[deleted]

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

#97

Post by usrnm »

rurban wrote: post #18

Should have be called give(). But naming things correctly is hard, and the C++ committee is known to do a lot of things incorrectly

The name predates the standardisation. The committee did not come with the whole thing themselves, rather they adopted and expanded already existing library implementations. You could move in C++, with this exact name, long before C++11.

See, for example, this implementation https://stlab.adobe.com/group__move__related.html

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

#98

Post by mackeye »

j1elo wrote: post #87
pjmlp wrote: post #82

Earlier quoted context omitted.

It took 13 years to get C++11, actually. Go's discussion is interesting, given how much programming language design history, and flaws of existing languages, they ignore to this day.

A bit more if we consider the "bugfixing" release that was C++14 :) But yeah it makes sense, given how that was the jumpstart of the whole modernization of the language. I believe it was a big undertake that required the time it took. Still years have passed and footguns keep accumulating... it wouldn't hurt to have a mechanism to optionally drop the old cruft from the language. Otherwise everything stacks on top in…

a member of the c++ committee (herb sutter) is writing an compiler for an alternative c++ syntax [0], to c++, with the intent to restrict some semantics of the language for less UB, surprises, etc. i think less implementation-defined behavior is incredibly important; rvo vs std::move, dynamic function call optimization, i wish i didn't have to search asm to check for...

[0]: https://github.com/hsutter/cppfront

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

#99

Post by drysine »

ghosty141 wrote: post #63
andyjohnson0 wrote: post #39

> This code works. It compiles. It runs. But depending on how you’ve implemented your types, it might be performing thousands of expensive copy operations instead of cheap moves without you realizing it. I've spent the last two decades in the .net platform. But for a decade or so before that I was a C++/Unix dev. I remember old style "C with classes" C++ as being fairly small and elegant, and approximately as easy to…

> So, what are the forces that have determined the current state of C++? I'm very confident that the main driving factors are: 1. "performance" (not wanting to do more allocations than necessary) 2. abi compatibility 3. adding features without caring how well they integrate Example for 1: "emplace", you normally have "append" but emplace directly constructs the object in the container instead of having to be construc…

>Example for 1: ...breaks when using pairs

No, it doesn't. But sometimes you want to construct pair's elements in-place too and that's what piecewise_construct is for.

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

#100

Post by pjmlp »

j1elo wrote: post #87
pjmlp wrote: post #82

Earlier quoted context omitted.

It took 13 years to get C++11, actually. Go's discussion is interesting, given how much programming language design history, and flaws of existing languages, they ignore to this day.

A bit more if we consider the "bugfixing" release that was C++14 :) But yeah it makes sense, given how that was the jumpstart of the whole modernization of the language. I believe it was a big undertake that required the time it took. Still years have passed and footguns keep accumulating... it wouldn't hurt to have a mechanism to optionally drop the old cruft from the language. Otherwise everything stacks on top in…

While I share the sentiment, compare C#14 with C# 1.0, Java 25 with Java 1.0, Python 3.14 with Python 1.0.

While C++ might be worse, when you have 300+ doing proposals every three years, others aren't safer from similar churn, even if on smaller volume, and trying to keep backwards compatibility going.

And we all know what happened in Python.

Also Rust editions contrary to what many think, only cover a specific set of language evolution scenarios, it isn't anything goes, nor there is support for binary libraries.

As for a better C++, contrary to C, where it is business as usual, there are actually people trying to sort things out on WG21, even if isn't as well as we would like to.

"Making C++ Safe, Healthy, and Efficient - CppCon 2025"

https://youtu.be/p52mNWsh-qs?si=AEs1dtr6_iknzATv

Post reply on HN