move-semantics

I have this piece of code: #include <iostream> #include <vector> using namespace std; class Foo{ public: Foo() noexcept {cout << "ctor" << endl;} Foo(const Foo&) noexcept {cout << "copy ctor" << endl;} Foo(Foo&&) noexcept {cout << "move ctor" << endl;} Foo& operator=(Foo&&) noexcept {cout << "move assn" << endl; return *this;} Foo& operator=(const Foo&) noexcept {cout << "copy assn" << endl; return *this;} ~Foo() noexcept {cout << "dtor" << endl;} }; int main() { Foo foo; vector<Foo> v; v.push_back(std::move(foo)); // comment the above 2 lines and replace by // vector<Foo> v{std::move(foo)}; }

This question already has answers here : On how to recognize Rvalue or Lvalue reference and if-it-has-a-name rule (3 answers) Closed 3 years ago . class MyClass { public: MyClass() { std::cout << "default constructor\n"; } MyClass(MyClass& a) { std::cout << "copy constructor\n"; } MyClass(MyClass&& b) { std::cout << "move constructor\n"; } }; void test(MyClass&& temp) { MyClass a(MyClass{}); // calls MOVE constructor as expected MyClass b(temp); // calls COPY constructor... not expected...? } int main() { test(MyClass{}); return 0; } For the above code, I expected both object creations in test

How can I distinguish a variable as a compiler-constructed string? For example, while the rvalue "Hello, World" is of type const char* . const char* in itself does not mean that a pointer can't be changed. A char* const pointer can't be changed, but that's not what's constructed by the compiler. Does this mean that, for any container that holds a const char* , the data should be copied by means other than C++'s move semantics? Is there any way to just move compiler-constructed strings and leave all other strings alone? For example, in the GCC 4.5.2, a method that returns the type int as

Is it safe to operate on object within arguments' list, when there is also std::move() invoked on that object ? void foo(int* raw, std::unique_ptr<int> u) { *raw = 456; } std::unique_ptr<int> p(new int(123)); foo(p.get(), std::move(p)); Will the `raw' pointer in foo() be valid if std::move(p) was evaluated as the first parameter ? No, it's NOT safe. the eval order of argument is not specified in standard. So your code can be run as: std::move(p) . call move constructor of std::unique_ptr<int> . p.get() (because of 2., this will be nullptr .) and pass this parameter. call foo . You have to do

This question already has answers here : Closed 6 years ago . I have read the below post which gives a very good insight into move semantics: Can someone please explain move semantics to me? but I am still fail to understand following things regarding move semantics - Does copy elision and RVO would still work for classes without move constructors? Even if our classes doesn't have move constructors, but STL containers has one. For operation like std::vector vt = CreateMyClassVector(); and to perform operations like sorting etc. Why can't STL internally leverage move semantics to improve such

I have read the below post which gives a very good insight into move semantics: Can someone please explain move semantics to me? but I am still fail to understand following things regarding move semantics - Does copy elision and RVO would still work for classes without move constructors? Even if our classes doesn't have move constructors, but STL containers has one. For operation like std::vector<MyClass> vt = CreateMyClassVector(); and to perform operations like sorting etc. Why can't STL internally leverage move semantics to improve such operations internally using operations like copy