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

211–220 of 220 posts

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

#211

Post by tsimionescu »

knorker wrote: post #70
tsimionescu wrote: post #34

Earlier quoted context omitted.

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.

No: https://godbolt.org/z/d7f6MWcb5 Look, the act of calling std::move and and calling a function taking an rvalue reference in no way invokes a move constructor or move assignment. It does not "move". It's still just a reference, albeit an rvalue reference. std::move and the function shape is about the type system, not moving. (Edit: amusingly, inside the callee it's an lvalue reference, even though the function sig…

Thanks for the godbolt link, it really helped me understand where my mistake was. I was treating r-value references in my mind as if they are "consuming" the value, but of course, as reference types, they are not.

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

#212

Post by tsimionescu »

charcircuit wrote: post #42
tsimionescu wrote: post #12

Earlier quoted context omitted.

It is absolutely knowable statically if ownership will be taken. It's not necessarily very easy to do so, but the decision is 100% up to the compiler, as part of overload resolution and optimization choices (like the NRVO analysis that the article mentions). Since ownership is an inherently static concept, it doesn't even make sense to think about "runtime ownership".

I don't understand the downvoted here. Either the compiler emits the code to call a move constructor or it doesn't.

People were very right to downvote me, as I was being fairly certain, but wrong.

The truth is that when you call a function which takes an r-value reference, it is NOT determined statically if the value you passed to the function is moved-from or not after the function call ends. This is ultimately similar to passing a value by non-const reference to a function - the function may or may not modify the value, so it may or may not be safe to use it the same way afterwards.

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

#213

Post by pjmlp »

gpm wrote: post #203
pjmlp wrote: post #202

Earlier quoted context omitted.

Provided everything is available in source code, there are no semantic changes on the boundary level, or standard library types being used on the library public API that changed across editions.

No. Not provided any of that. Must not matter really does mean "must not matter" here.

How do you link two crates together, each compiled with a distinct edition, whose public API is incompatible across editions?

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

#214

Post by tsimionescu »

ben-schaaf wrote: post #67
tsimionescu wrote: post #16

Earlier quoted context omitted.

Can you show an example of what you mean? My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it. Of course, `foo` can choose to further copy or move the data it receives, but it can't choose later on if it's copied or not. Now, if I give `foo` a pointer to myObj, it could of course choose to copy or move from it later and based…

No, it is not statically knowable if it is actually moved. void foo(Obj && arg) {} Does not move `arg`. It's fairly easy to write code that assumes `std::move` moves the value, but that can lead to bugs. For example: void some_function(std::vector &&); void some_function2(std::vector &&); void main() { std::vector a = { 1 }; some_function(std::move(a)); a.push_back(2); some_other_function(std::move(a)); } The expecta…

You're right, of course - I was completely messing up in my mind what r-value reference parameters actually do, and thinking that they need to be moved to, when the whole point is that they don't, they're just a reference.

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

#215

Post by charcircuit »

knorker wrote: post #209
charcircuit wrote: post #198

Earlier quoted context omitted.

What the callee does it out of scope. We are talking about a single assignment or construction of a variable. This has nothing to do with tracing execution. It happens at one place, and you can look at the place to see if it is using a copy or move contructor.

When talking C++ move semantics it's easy to talk past each other. So I'm not sure what your claim is. Another commenter said that one can tell if something is moved or not without looking at the body of the callee. Is that what you're saying? Because you can't. I apologize if you're making a different claim, but I'm not clear on what that is. Anyway, for my point, here's an example where neither copy nor move happen…

Calling a function that takes a rref will never use a move constructor to create the parameter. We can statically know that both of your foo functions will not use a move constructor when constructing p.

>By changing only the callee we can cause a move

This move is for constructing t. p still is not constructed with a move constructor.

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

#216

Post by knorker »

charcircuit wrote: post #215
knorker wrote: post #209

Earlier quoted context omitted.

When talking C++ move semantics it's easy to talk past each other. So I'm not sure what your claim is. Another commenter said that one can tell if something is moved or not without looking at the body of the callee. Is that what you're saying? Because you can't. I apologize if you're making a different claim, but I'm not clear on what that is. Anyway, for my point, here's an example where neither copy nor move happen…

Calling a function that takes a rref will never use a move constructor to create the parameter. We can statically know that both of your foo functions will not use a move constructor when constructing p. >By changing only the callee we can cause a move This move is for constructing t. p still is not constructed with a move constructor.

p in the callee is not constructed at all. It's a reference.

> Calling a function that takes a rref will never use a move constructor to create the paramete

This is what I mean by talking past each other. This is literally what I said.

Well, I wouldn't say the parameter is "created", since I'd say that's an imprecise term in this context.

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

#217

Post by knorker »

charcircuit wrote: post #197
masklinn wrote: post #180

Earlier quoted context omitted.

> That is the whole argument No, it is not. > Let me quote the other person: "My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it." Yes. `foo`. > It is saying that for "auto pp = std::move(p);" we will know if it uses the move assign constructor or the copy assign constructor. `pp` is not `foo`. That `pp` uses a move construct…

Taking a step back I think the issue is that your foo takes an rvalue reference. Which is not the case we are talking about which is whether a move or copy constructor is used when constructing the parameter of foo.

What do you mean by "move or copy constructor is used when constructing the parameter of foo"?

Nothing is constructed at call time. Check out this example, which compiles just fine, even though Foo is neither copy nor move constructible/assignable: https://godbolt.org/z/Wj57o773d

"&&" is just a type system feature, resolving function polymorphism matching rvalue reference and not lvalue reference. It's not a thing that causes a move.

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

#218

Post by gpm »

pjmlp wrote: post #213
gpm wrote: post #203

Earlier quoted context omitted.

No. Not provided any of that. Must not matter really does mean "must not matter" here.

How do you link two crates together, each compiled with a distinct edition, whose public API is incompatible across editions?

There is no such thing as "crates whose public API is incompatible across editions".

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

#219

Post by juliangmp »

teraro wrote: post #59
juliangmp wrote: post #35

Earlier quoted context omitted.

Most sensible Compiler flags aren't enabled by default... I keep a list of arguments for gcc to make things better, but even then you'll also wanna use a static analysis tool like clang-tidy

Would you mind sharing your list?

Sure, I put quickly put them into a small markdown file. At my job we have a cmake interface target that handles these (along with some version checks and project specific stuff), but I can't publish that of course. I might put these into a cmake file at some point, not sure.

https://codeberg.org/JulianGmp/sane-args-cpp

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

#220

Post by zbentley »

HarHarVeryFunny wrote: post #85
zbentley wrote: post #62

Earlier quoted context omitted.

What does processor but width have to do with the likelihood of allocation failures?

I think what he means is that on a 64-bit system you have a massive virtual address space (typically only 48-bit, but that's still 256TB), and since malloc allocates from virtual address space, not limited by physical memory, it is unlikely you will get a malloc failure (unless you are trying to allocate more than 256TB per process, maybe due to a memory leak).

That's not true as generally as you might expect.

Folks might be using mmap with MAP_POPULATE; they might have overcommit turned off; they might be operating in an rlimit/cgroup (like most container runtimes/orchestrators configure) that limits memory; they might be on a system which doesn't have virtual memory (plenty such systems exist in 64-bit architectures); they might be using calloc on an OS that zeros pessimistically/early; and so on.

Post reply on HN