The center for all discussion and news regarding C++.
To me it's not really excitement so much as "oh god how do i make this ridiculous language do the correct thing".
I'm way more scared of rogue implicit copy constructors. I wonder if cppfront has any plan to fix problems like implicit copy and pessimising move.
In Rust, making something copyable is always explicit. I like that a lot.
Copy has a very different meaning between the two languages. In rust the equivalent of a c++ copy is a clone() call for anything non trivial
...which is also explicit.
@BatmanAoD @Miaou It is just what you are used to.
In C++ everything is a copy. Sometimes the compiler optimizes it away. clang-tidy may help. Having a clone() is very C-like.
That's a common idiom but the default behaviour is still implicit copy, which, with VLAs and no smart pointers, makes things arguably worse than in c++
I thought that was obvious as I mentioned a function call, but yes indeed
Cpp should have done ref by default and had & for copy, but here we are.
Cpp should have done ref by default and had & for copy, but here we are.
That would defeat the goal of making it backwards-compatible with C.
To me it’s not really excitement so much as “oh god how do i make this ridiculous language do the correct thing”.
I think this all comes down to having the right mental model.
In this case, I think it helps to know that:
The zany behavior is that if you set up your function to push for a move (i.e., force a local variable to be treated as a temporary), the language ceases to be able to apply its optimization.
That's basically it. No real mystery.
The parts that seem likely to cause this confusion (which I shared when I first started using C++11) are:
std::move isn't a compiler intrinsic and doesn't force a move operation; it's just a function that returns an r-value reference. So it makes it harder, not easier, for the compiler to "see through" and optimize away, even in the case where "as if" rule should make that legal.I wonder if the language could be updated so these extra std::move invocations actually become harmless? return std::move is something that I see used quite a bit.
@QuadriLiteral @lysdexic We've been looking at a paper just recently in Kona, where the author proposed to not penalize "unfortunate" uses of std::move. I think this is user friendly and you might imagine what I've been voting for.
That sounds great!
I wonder if the language could be updated so these extra std::move invocations actually become harmless? return std::move is something that I see used quite a bit.
These std::move invocations are harmless, as they only cast objects to their rvalue reference.
The destructive bit takes place in the type they are assigned to, as it invokes either a move constructor or a move assignment operator, and calling those implies that the object you just passed to std::move will be invalidated after the call and should not be used subsequently.
@lysdexic @QuadriLiteral Eh, no. Really. Changing the value category disables RVO
RVO
I recommend you read the thread.
@lysdexic I did.
It doesn't look like it, otherwise you'd be aware that the whole point of this submission is that casting return values with std::move disables RVO.
@lysdexic You claimed otherwise:
"
These std::move invocations are harmless, as they only cast objects to their rvalue reference.
"
If you were right, we wouldn't have the motivation to look at this in EWG.
If you were right, we wouldn’t have the motivation to look at this in EWG.
I am right. Not benefiting from RVO does not mean you're harming anyone.
Again, I recommend you read the submission and also the discussion.
I mean harmless in a way that using std::move on the return type doesn't prevent RVO?