move-assignment-operator

Move constructor vs. Move assignment

阅读更多关于 Move constructor vs. Move assignment

问题 As an extension to This question, i am trying to get my move assignment correct. I have the following code: // copy assignment operator LinkedList<T>& operator= (LinkedList<T> other) noexcept { swap(*this, other); return *this; } // move assignment operator LinkedList<T>& operator= (LinkedList<T>&& other) noexcept { swap(*this, other); return *this; } But when i try to use it, my code fails to compile. First some code: LinkedList<int> generateLinkedList() { LinkedList<int> List; List.add(123)

Move Constructor & Move Assignment

阅读更多关于 Move Constructor & Move Assignment

问题 I have been reading the book "The C++ programing language 4th edition" by Bjarne Stroustrup (The creator of c++) and have been learning about move constructors and move assignments. In the book for the class vector (see 1 for header below) he shows how to implement the move constructor (see 2 below) and says the move assignment is implemented in a similar manner but doesn't show how. I have implemented the move assignment myself (see 3 below) and everything seems to be working fine, however,

Is move assignment via destruct+move construct safe?

阅读更多关于 Is move assignment via destruct+move construct safe?

问题 Here's a very easy way to define move assignment for most any class with a move constructor: class Foo { public: Foo(Foo&& foo); // you still have to write this one Foo& operator=(Foo&& foo) { if (this != &foo) { // avoid destructing the only copy this->~Foo(); // call your own destructor new (this) Foo(std::move(foo)); // call move constructor via placement new } return *this; } // ... }; Is this sequence of calling your own destructor followed by placement new on the this pointer safe in

What is the rationale for self-assignment-unsafe move assignment operators in the standard library?

阅读更多关于 What is the rationale for self-assignment-unsafe move assignment operators in the standard library?

问题 The standard library policy about move assignment is that the implementation is allowed to assume that self-assignment will never happen; this seems to me a really bad idea, given that: the "regular" ("copy") assignment contract in C++ has always been regarded as safe against self-assignment; now we have yet another incoherent corner case of C++ to remember and to explain - and a subtly dangerous one, too; I think we all agree that what is needed in C++ is not more hidden traps; it

C++ move assignment to uninitialized object?

阅读更多关于 C++ move assignment to uninitialized object?

问题 As follow up to: Double free of child object after using the copy constructor I followed the rule of 5 as suggested. But now it seems like the move assignment is happening on an uninitialized object (to object id 0)? I expected it to move from object 3 to object 2. I have created the following (minimum?) example which seems to trigger my issue: #include <stdio.h> #include <stdint.h> class A { public: A() { myCtr = ++ctr; printf("class A default Constructor - object id: %u\n", myCtr); } A

Questions about the move assignment operator

阅读更多关于 Questions about the move assignment operator

问题 Imagine the following class that manages a resource (my question is only about the move assignment operator): struct A { std::size_t s; int* p; A(std::size_t s) : s(s), p(new int[s]){} ~A(){delete [] p;} A(A const& other) : s(other.s), p(new int[other.s]) {std::copy(other.p, other.p + s, this->p);} A(A&& other) : s(other.s), p(other.p) {other.s = 0; other.p = nullptr;} A& operator=(A const& other) {A temp = other; std::swap(*this, temp); return *this;} // Move assignment operator #1 A&

Allocator propagation policies in your new modern C++ containers

阅读更多关于 Allocator propagation policies in your new modern C++ containers

问题 What is the reason for having these traits in a container (https://en.cppreference.com/w/cpp/memory/allocator_traits) propagate_on_container_copy_assignment Alloc::propagate_on_container_copy_assignment if present, otherwise std::false_type propagate_on_container_move_assignment Alloc::propagate_on_container_move_assignment if present, otherwise std::false_type propagate_on_container_swap Alloc::propagate_on_container_swap if present, otherwise std::false_type is_always_equal(since C++17)

Is move assignment via destruct+move construct safe?

阅读更多关于 Is move assignment via destruct+move construct safe?

Here's a very easy way to define move assignment for most any class with a move constructor: class Foo { public: Foo(Foo&& foo); // you still have to write this one Foo& operator=(Foo&& foo) { if (this != &foo) { // avoid destructing the only copy this->~Foo(); // call your own destructor new (this) Foo(std::move(foo)); // call move constructor via placement new } return *this; } // ... }; Is this sequence of calling your own destructor followed by placement new on the this pointer safe in standard C++11? Only if you never, ever derive a type from this class. If you do, this will turn the

Does it make sense to reuse destructor logic by using std::swap in a move assignment operator?

阅读更多关于 Does it make sense to reuse destructor logic by using std::swap in a move assignment operator?

问题 Consider the following: class Example : boost::noncopyable { HANDLE hExample; public: Example() { hExample = InitializeHandle(); } ~Example() { if (hExample == INVALID_HANDLE_VALUE) { return; } FreeHandle(hExample); } Example(Example && other) : hExample(other.hExample) { other.hExample = INVALID_HANDLE_VALUE; } Example& operator=(Example &&other) { std::swap(hExample, other.hExample); //? return *this; } }; My thinking here is that the destructor will be running on "other" shortly, and as

What is the rationale for self-assignment-unsafe move assignment operators in the standard library?

阅读更多关于 What is the rationale for self-assignment-unsafe move assignment operators in the standard library?

The standard library policy about move assignment is that the implementation is allowed to assume that self-assignment will never happen ; this seems to me a really bad idea, given that: the "regular" ("copy") assignment contract in C++ has always been regarded as safe against self-assignment; now we have yet another incoherent corner case of C++ to remember and to explain - and a subtly dangerous one, too; I think we all agree that what is needed in C++ is not more hidden traps; it complicates algorithms - anything in the remove_if family need to take care of this corner case; it would be