move-semantics | 易学教程

Are C++11 move semantics doing something new, or just making semantics clearer?

阅读更多关于 Are C++11 move semantics doing something new, or just making semantics clearer?

问题 I am basically trying to figure out, is the whole "move semantics" concept something brand new, or it is just making existing code simpler to implement? I am always interested in reducing the number of times I call copy/constructors but I usually pass objects through using reference (and possibly const) and ensure I always use initialiser lists. With this in mind (and having looked at the whole ugly && syntax) I wonder if it is worth adopting these principles or simply coding as I already do?

Move semantics and operator overloading

阅读更多关于 Move semantics and operator overloading

问题 This is related to this answer provided by Matthieu M. on how to utilize move semantics with the + operator overloading (in general, operators which don't re-assign directly back to the left param). He suggested implementing three distinct overloads: inline T operator+(T left, T const& right) { left += right; return left; } inline T operator+(T const& left, T right) { right += left; return right; } // commutative inline T operator+(T left, T&& right) { left += right; return left; } //

Does a default virtual destructor prevent compiler-generated move operations?

阅读更多关于 Does a default virtual destructor prevent compiler-generated move operations?

Inspired by the post Why does destructor disable generation of implicit move methods? , I was wondering if the same is true for the default virtual destructor, e.g. class WidgetBase // Base class of all widgets { public: virtual ~WidgetBase() = default; // ... }; As the class is intended to be a base class of a widget hierarchy I have to define its destructor virtual to avoid memory leaks and undefined behavior when working with base class pointers. On the other hand I don't want to prevent the compiler from automatically generating move operations. Does a default virtual destructor prevent

Why is passing by value (if a copy is needed) recommended in C++11 if a const reference only costs a single copy as well?

阅读更多关于 Why is passing by value (if a copy is needed) recommended in C++11 if a const reference only costs a single copy as well?

问题 I am trying to understand move semantics, rvalue references, std::move , etc. I have been trying to figure out, by searching through various questions on this site, why passing a const std::string &name + _name(name) is less recommended than a std::string name + _name(std::move(name)) if a copy is needed. If I understand correctly, the following requires a single copy (through the constructor) plus a move (from the temporary to the member): Dog::Dog(std::string name) : _name(std::move(name))

Efficiency of C++11 push_back() with std::move versus emplace_back() for already constructed objects

阅读更多关于 Efficiency of C++11 push_back() with std::move versus emplace_back() for already constructed objects

问题 In C++11 emplace_back() is generally preferred (in terms of efficiency) to push_back() as it allows in-place construction, but is this still the case when using push_back(std::move()) with an already-constructed object? For instance, is emplace_back() still preferred in cases like the following? std::string mystring("hello world"); std::vector<std::string> myvector; myvector.emplace_back(mystring); myvector.push_back(std::move(mystring)); // (of course assuming we don't care about using the

Const reference VS move semantics

阅读更多关于 Const reference VS move semantics

问题 I was wondering in which situations I still need to use const references in parameters since C++11. I don't fully understand move semantics but I think this is a legit question. This question is meant for only the situations where a const reference replaces a copy being made while it is only needed to "read" the value (e.g. usage of const member functions). Normally I would write a (member)function like this: #include <vector> template<class T> class Vector { std::vector<T> _impl; public:

Is std::move(*this) a good pattern?

阅读更多关于 Is std::move(*this) a good pattern?

In order to make this code with C++11 reference qualifiers work as expected I have to introduce a std::move(*this) that doesn't sound right. #include<iostream> struct A{ void gun() const&{std::cout << "gun const&" << std::endl;} void gun() &&{std::cout << "gun&&" << std::endl;} void fun() const&{gun();} void fun() &&{std::move(*this).gun();} // <-- is this correct? or is there a better option }; int main(){ A a; a.fun(); // prints gun const& A().fun(); // prints gun&& } Something doesn't sound right about it. Is the std::move necessary? Is this a recommended use for it? For the moment if I don

Why doesn't `std::stringstream::stringstream(std::string&&)` exist?

阅读更多关于 Why doesn't `std::stringstream::stringstream(std::string&&)` exist?

I was hoping stringstream has a constructor that steals its initial content from a string&& . Do such inter-species "move constructors" generally not exist in the STL? If not, why not? There's history, which is disappointing. But also a future that looks bright. When move semantics went into C++11, it was huge, controversial, and overwhelming. I wanted to be able to move strings into and out of stringstream . However the politics at the time demanded that the internal store did not have to be a basic_string<charT> . For example the internal store could be a vector . And there was no ability to

copy vs std::move for ints

阅读更多关于 copy vs std::move for ints

What's difference between default copy and std::move in that example? After move the object is there any dependence between new and old ones? int main () { int a = 100; std::cout<<&a<<std::endl; auto a_copy = a; // deduced as int std::cout<<&a_copy<<std::endl; auto a_move = std::move(a); // deduced as int std::cout<<&a_move<<std::endl; }; output: 0x7fffffffe094 0x7fffffffe098 0x7fffffffe09c In this example, there is no difference. We will end up with 3 int s with value 100. There could definitely be a difference with different types though. For instance, let's consider something like vector

How to use move semantics with std::string during function return? [duplicate]

阅读更多关于 How to use move semantics with std::string during function return? [duplicate]

This question already has answers here : C++11 rvalues and move semantics confusion (return statement) (6 answers) Possible Duplicate: C++11 rvalues and move semantics confusion What I think is correct is std::string GetLine() { std::string str; std::getline(std::cin, str); return std::move(str); } But at this link http://www.cprogramming.com/c++11/rvalue-references-and-move-semantics-in-c++11.html ( check the header part Returning an explicit rvalue-reference from a function) which is #1 google search hit for move semantics shows a similar function signature as int&& GetInt() { int x = 0; //