rvalue implicit move tracking?
Using g++ (4.6.2) is there any way to turn on compiler flags to tell what uses implicit move instead of traditional copy/assign?
Recently I've been playing around with selectively adding explicit copy/assign methods to classes that can really use them. Unfortunately I'm seeing a net overall performance hit in the code with turning on c++11 support, even with these explicit operators defined.
I'm also wondering since we did such a good job at RVO if the move semantics may be hurting us potentially.
Not to mention we've used a fair bit of explicit temporaries in the code to help with readability of the mathematical formulae.
Recently I've been playing around with selectively adding explicit copy/assign methods to classes that can really use them. Unfortunately I'm seeing a net overall performance hit in the code with turning on c++11 support, even with these explicit operators defined.
I'm also wondering since we did such a good job at RVO if the move semantics may be hurting us potentially.
Not to mention we've used a fair bit of explicit temporaries in the code to help with readability of the mathematical formulae.
Last edited on
| implicit move instead of traditional copy/assign? |
| I've been playing around with selectively adding explicit copy/assign methods to classes that can really use them. |
| since we did such a good job at RVO if the move semantics may be hurting us potentially |
frankly I'm curious to see how much the std collections change with move stuff.
I did find a bug with how I implemented one of the explicit declaration, fixed it and did see an improvement.
It seems valgrind is my only friend here, keeping track of total allocations and deallocations.
I need to read up on how collections now handle std::move. I might be able to tweak some more with explicit std::move declarations.
I did find a bug with how I implemented one of the explicit declaration, fixed it and did see an improvement.
It seems valgrind is my only friend here, keeping track of total allocations and deallocations.
I need to read up on how collections now handle std::move. I might be able to tweak some more with explicit std::move declarations.
Can you explain? |
He's referring to the new std::move semantics introduced in C++11. The basic idea is that when a temporary is about to go out of scope you can basically 'rip its guts out', as Scott Meyers puts it, and give its state to another instance of the same type -- no one will know the difference.
Now there are very specific rules and conditions when the compiler is allowed to do this. It looks like the OP wants to know when the compiler is actually applying this optimization.
RVO? There's that move thing again. |
RVO is return value optimization. It's an optimization applied by the compiler to avoid an extra copy when a function/method returns something by value.
Having said all this, why doesn't cplusplus.com have a reference for std::move yet? The search isn't turning anything up :(
Topic archived. No new replies allowed.