Comment by HarHarVeryFunny

Comment by HarHarVeryFunny 11 hours ago

Sure overload resolution happens first, but once the compiler has found the correct match then the way arguments are passed depends only on the function signature of that match (callee), and how the caller is passing.

An argument passed to a value parameter will be passed by copying, unless it's an rvalue (e.g. forced with std:move) where a move constructor has been defined for that type, in which case it will be moved. The callee has no say in this.

fluoridation 11 hours ago

>Sure overload resolution happens first, but once the compiler has found the correct match then the way arguments are passed depends only on the function signature of that match (callee), and how the caller is passing.

Yes, and std::move() works exactly the same. The compiler first determines whether to move or to copy, and then generates the call to the corresponding constructor or assignment operator. Just like how foo(x) doesn't tell you anything about whether a value is being copied, foo(std::move(x)) doesn't tell you anything about whether a value is being moved.

You might say "well, you need to look at all the signatures of foo() to tell if there's a copy", and to that I say, "yeah, and you need to look at what x is to tell if there's a move".

Reply View 4 replies

HarHarVeryFunny 10 hours ago

Not sure how this relates to your original claim, below, that I have been responding to?
> Just because you wrote at the call site that you want to pass a copy of your object doesn't mean that the callee will actually make a copy of it.

Reply View | 3 replies
- fluoridation 9 hours ago
  
  Meaning, just like move semantics, overload resolution can sometimes be surprising, and the compiler may not always do what you expected if you don't fully understand the types you're working with. std::move() is not special in this sense.
  
  Reply View | 2 replies
  
  HarHarVeryFunny 7 hours ago
  
  Ah, yes, unfortunately the language says that a value parameter of type T and an rvalue parameter of type T (T&&) are both equal priority "exact matches" to a call passing an rvalue argument, but at least if that was the only difference between two functions you'd get an ambiguous overload compilation error rather than it just selecting an unexpected one.
  A workaround for this, if you want an rvalue parameter to match an rvalue argument during overload resolution, is to make the alternate "value" (vs rvalue) overload a const reference argument vs a value one.
  So, if you have f(T&&) and f(T), and call f(std::move(t)) then you'll get an ambiguous overload compilation error, but if you instead had f(T&&) and f(const T&), then f(std::move(t)) will match the rvalue one as you may hope for.
  
  Reply View | 1 reply
  
  fluoridation 6 hours ago
  
  >So, if you have f(T&&) and f(T), and call f(std::move(t)) then you'll get an ambiguous overload compilation error [...]
  Okay, but that's not what I'm saying. I'm not talking about the program being invalid, I'm talking about the program being confusing to the programmer, which is what this article is about. Sure, in that case the program is ill-formed. What if you have f(const T &, double) and f(T, int)? If you call f(x, 0) you cause a copy, and if you call f(x, 0.0) you don't. A programmer who's not aware that the second overload exists will not realize this is happening, in the same way that he will not realize std::move() is not moving anything if they don't realize, for example, that the argument is const.
  
  Reply View | 0 replies