move-semantics

问题 In C++11, "move semantics" was introduced, implemented via the two special members: move constructor and move assignment. Both of these operations leave the moved-from object constructed. Wouldn't it have been better to leave the source in a destructed state? Isn't the only thing you can do with a moved-from object is destruct it anyway? 回答1: In the "universe of move operations" there are four possibilities: target source is is left ----------------------------------------------------------

问题 I used to assume that a class' move constructors would be given priority over its copy constructors, but in the code below it seems that the copy constructor is chosen even though the object should be movable. Do you have any idea why below codes choose copy constructor when foo() returns vector<B> B ? #include <iostream> #include <vector> using namespace std; class B { public: int var_; B(int var) : var_(var) { cout << "I'm normal" << endl; } B(const B& other) { cout << "I'm copy constructor

问题 I'm trying to get the deep knowledge about how should I write my copy and move constructors and assignment operators. In Bjarne Stroustrup's "The C++ Programming Language - 2013" I see the following example of move constructor and move assignment: template<class T, class A> vector_base<T,A>::vector_base(vector_base&& a) : alloc{a.alloc}, elem{a.elem}, space{a.space}, last{a.space} { a.elem = a.space = a.last = nullptr; // no longer owns any memory } template<class T, class A> vector_base<T,A>

问题 I'm trying to get the deep knowledge about how should I write my copy and move constructors and assignment operators. In Bjarne Stroustrup's "The C++ Programming Language - 2013" I see the following example of move constructor and move assignment: template<class T, class A> vector_base<T,A>::vector_base(vector_base&& a) : alloc{a.alloc}, elem{a.elem}, space{a.space}, last{a.space} { a.elem = a.space = a.last = nullptr; // no longer owns any memory } template<class T, class A> vector_base<T,A>

问题 I have a C++ framework which I provide to my users, who should use a templated wrapper I wrote with their own implementation as the templated type. The wrapper acts as an RAII class and it holds a pointer to an implementation of the user's class. To make the user's code clean and neat (in my opinion) I provide a cast operator which converts my wrapper to the pointer it holds. This way (along with some other overloads) the user can use my wrapper as if it is a pointer (much like a shared_ptr).

问题 Please consider the following code: struct MyStruct { int iInteger; string strString; }; void MyFunc(vector<MyStruct>& vecStructs) { MyStruct NewStruct = { 8, "Hello" }; vecStructs.push_back(std::move(NewStruct)); } int main() { vector<MyStruct> vecStructs; MyFunc(vecStructs); } Why does this work? At the moment when MyFunc is called, the return address should be placed on the stack of the current thread. Now create the NewStruct object gets created, which should be placed on the stack as

问题 In the following C++11+ code which return statement construction should be preferred? #include <utility> struct Bar { }; struct Foo { Bar bar; Bar get() && { return std::move(bar); // 1 return bar; // 2 } }; 回答1: Well, since it's a r-value ref qualified member function, this is presumably about to expire. So it makes sense to move bar out, assuming Bar actually gains something from being moved. Since bar is a member, and not a local object/function parameter, the usual criteria for copy

问题 In the following examples from cpp reference: #include <iostream> #include <utility> #include <vector> #include <string> int main() { std::string str = "Hello"; std::vector<std::string> v; // uses the push_back(const T&) overload, which means // we'll incur the cost of copying str v.push_back(str); std::cout << "After copy, str is \"" << str << "\"\n"; // uses the rvalue reference push_back(T&&) overload, // which means no strings will be copied; instead, the // Contents of str will be moved

问题 The class Foo has an rvalue reference constructor that moves the contained vector of unique_ptr s so why does the following code give the following error, both with or without the std::move on the Foo() in main ? error C2280: 'std::unique_ptr<SomeThing,std::default_delete<_Ty>> &std::unique_ptr<_Ty,std::default_delete<_Ty>>::operator =(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function class Foo{ public: Foo(){ } Foo(Foo&& other) : m_bar(std:

问题 I'm catching a warning under Clang when testing a library under C++11. I've never come across the warning before and searching is not providing too much in the way of reading and research. The warning is shown below, and it appears to be related to multiple inheritance and a common base class. But I'm not clear on the details triggering the warning or what I should do to address it. My first question is, Is this a problem that needs to be addressed? Or is it a matter of efficiency alone? My