For resource managing in classes, do not think that move will always move. It will fallback to copy if the object is not moveable. Or if the operation throws an exception, it will fall back to copy as well, so always mark the move constructor as noexcept as we saw on the previous blog about move semantics. struct MyClass{ std::vector<int> m_data; ~MyClass() = default; }; Given the above class, consider the below lines: ...
When writing classic Object-Oriented Programming (OOP) in C++, we are taught to design our systems using polymorphism. We define a base class with virtual functions, inherit from it, and manipulate those objects using base class pointers. At runtime, the program dynamically selects the correct function execution based on the actual object type. This is known as dynamic (or runtime) dispatch. We will see below exactly what is happening behind the scenes. ...
Returning a moved big object will actually create extra overhead for the compiler, as a zero-cost operation is traded for a cheap move operation.
Ideally, we should never throw on the move Constructor of an object. If a move constructor throws an exception while a vector is resizing, the vector is in a “broken” state: half of the elements are in the new memory, and half are in the old memory. Move operations often modify the source object (leaving it empty or null), making it dangerous to undo the changes. Therefore, the compiler wants to avoid this risk and uses a copy rather than a movment. We want to avoid this, and the way to do this is to declare the move constructor as noexcept. Like this, we give the promise that we do not throw, and the compiler can safely use it. ...
Converting a base-class pointer to a derived-class pointer is downcasting. We should be careful when we do that in order to avoid UBs.