Exceptional GitLab maintenance is scheduled for June 24, 2025. The service will be unavailable between 8:00 am and 9:30 am. Please do not work on the platform until an announcement indicates that maintenance is complete.
# [Getting started in C++](./) - [Operators](/notebooks/3-Operators/0-main.ipynb) - [Affectation operator and the canonical form of a class](/notebooks/3-Operators/4-CanonicalForm.ipynb)
%% Cell type:markdown id: tags:
<h1>Table of contents<spanclass="tocSkip"></span></h1>
<divclass="toc"><ulclass="toc-item"><li><span><ahref="#Affectation-operator"data-toc-modified-id="Affectation-operator-1">Affectation operator</a></span><ulclass="toc-item"><li><span><ahref="#Default-behaviour-(for-a-simple-case)"data-toc-modified-id="Default-behaviour-(for-a-simple-case)-1.1">Default behaviour (for a simple case)</a></span></li><li><span><ahref="#The-pointer-case"data-toc-modified-id="The-pointer-case-1.2">The pointer case</a></span></li><li><span><ahref="#Uncopyable-class"data-toc-modified-id="Uncopyable-class-1.3">Uncopyable class</a></span></li><li><span><ahref="#Copy-constructor"data-toc-modified-id="Copy-constructor-1.4">Copy constructor</a></span></li><li><span><ahref="#The-dangers-of-copy-constructions...-and-how-I-avoid-them"data-toc-modified-id="The-dangers-of-copy-constructions...-and-how-I-avoid-them-1.5">The dangers of copy constructions... and how I avoid them</a></span></li></ul></li><li><span><ahref="#Canonical-form-of-a-class"data-toc-modified-id="Canonical-form-of-a-class-2">Canonical form of a class</a></span><ulclass="toc-item"><li><span><ahref="#[Advanced]-The-true-canonical-class"data-toc-modified-id="[Advanced]-The-true-canonical-class-2.1">[Advanced] The true canonical class</a></span></li></ul></li></ul></div>
%% Cell type:markdown id: tags:
## Affectation operator
We have not yet addressed one of the most natural operator: the one that might be used to allocate a value to an object.
So end of the story? Not exactly... Let's write the same and store the values in a dynamic array instead (of course you shouldn't do that in a real case: `std::vector` or `std::array` would avoid the hassle below!):
// Dynamic allocation here just to be able to make our point due to the explicit call of destructor with `delete`
Vector2* v1 = new Vector2(3., 5., 7.);
Vector2* v2 = new Vector2(-4., -16., 0.);
v2 = v1; // Kernel crash?
v2 = v1;
std::cout << "Copy done" << std::endl;
delete v1;
std::cout << "v1 deleted" << std::endl;
// delete v2; // Uncommenting this line leads to a kernel crash...
}
```
%% Cell type:markdown id: tags:
At the time of this writing, this makes the kernel crash... In a more advanced environment ([Wandbox](https://wandbox.org) for instance) the reason appears more clearly:
%% Cell type:markdown id: tags:
```txt
** Error in `./prog.exe': double free or corruption (fasttop): 0x0000000001532da0 **
```
So what's the deal? The default operator copies all the data attributes from `v1` to `v2`... which here amounts only to the `array_` pointer. But it really copies that: the pointer itself, _not_ the data pointed by this pointer. So in fine v1 and v2 points to the same area of memory, and the issue is that we attempt to free the same memory twice.
One way to solve this is not to use a dynamic array - for instance you would be cool with a `std::vector`. But we can do so properly by hand as well (in practice don't - stick with `std::vector`!):
%% Cell type:code id: tags:
``` C++17
#include <iostream>
class Vector3
{
public:
Vector3(double x, double y, double z);
~Vector3();
// Then again the Xeus-cling issue with out of class operator definition.
Vector3& operator=(const Vector3& rhs)
{
// Array already initialized in constructor; just change its content.
for (auto i = 0ul; i < 3ul; ++i)
array_[i] = rhs.array_[i];
return *this; // The (logical) return value for such a method.
In fact when I said by default an affectation operator is made available for the class, I was overly simplifying the issue. Let's consider for instance a class with a reference data attribute:
%% Cell type:code id: tags:
``` C++17
class ClassWithRef
{
public:
ClassWithRef(int& index);
private:
int& index_;
};
```
%% Cell type:code id: tags:
``` C++17
ClassWithRef::ClassWithRef(int& index)
: index_(index)
{ }
```
%% Cell type:code id: tags:
``` C++17
{
int a = 5;
ClassWithRef obj(a);
}
```
%% Cell type:code id: tags:
``` C++17
{
int a = 5;
int b = 7;
ClassWithRef obj1(a);
ClassWithRef obj2(b);
obj2 = obj1; // COMPILATION ERROR
}
```
%% Cell type:markdown id: tags:
A class with a reference can't be copied: the reference is to be set at construction, and be left unchanged later. So a copy is out of the question, hence the compilation error.
The same is true as well for a class with an uncopyable data attribute: the class is then automatically uncopyable as well.
%% Cell type:markdown id: tags:
### Copy constructor
Please notice however that it is still possible to allocate a new object which would be a copy of another one with a **copy constructor**. The syntax is given below:
%% Cell type:code id: tags:
``` C++17
class ClassWithRef2
{
public:
ClassWithRef2(int& index);
ClassWithRef2(const ClassWithRef2& ) = default;
private:
int& index_;
};
```
%% Cell type:code id: tags:
``` C++17
ClassWithRef2::ClassWithRef2(int& index)
: index_(index)
{ }
```
%% Cell type:code id: tags:
``` C++17
{
int a = 5;
ClassWithRef2 obj1(a);
ClassWithRef2 obj2(obj1); // ok
ClassWithRef2 obj3 {obj1}; // ok
}
```
%% Cell type:markdown id: tags:
There are effectively two ways to copy an object:
* With an affectation operator.
* With a copy constructor.
It is NOT the same underlying method which is called under the hood, you might have a different behaviour depending on which one is called or not!
%% Cell type:markdown id: tags:
### The dangers of copy constructions... and how I avoid them
Copy construction may in fact be quite dangerous:
* As we've just seen, affectation and construction may differ in implementation, which is not a good thing. There are ways to define one in function of the other (see for instance item 11 of \cite{Meyers2005}) but they aren't that trivial.
* Depending on somewhat complicated rules that have evolved with standard versions, some might or might not be defined implicitly.
* More importantly, affectation operators may be a nightmare to maintain. Imagine you have a class for which you overload manually the affectation operator and/or the copy constructor. If later you add a new data attribute, you have to make sure not to forget to add it in both implementations; if you forget once you will enter the real of undefined behaviour... and good luck for you to find the origin of the bug!
To avoid that I took the extreme rule to (almost) never overload those myself:
* As explained briefly above, using appropriate container may remove the need. `Vector3` could be written with a `std::array` instead of the dynamic array, and the STL object will be properly copied with default behaviour!
* I define explicitly in my classes the behaviour of these operators with `= default` or `= delete` syntaxes. More often than not, my objects have no business being copied and `= delete` is really my default choice (this keyword indicates to the compiler the operator should not be provided for the class).
I don't pretend it is the universal choice, just my way to avoid the potential issues with manually overloaded copy operators (some would say the [Open-closed principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) would avoid the most problematic one, but in the real world I find it difficult to stick with this principle...)
%% Cell type:markdown id: tags:
## Canonical form of a class
So a typical class of mine looks like:
%% Cell type:code id: tags:
``` C++17
class AlmostCanonicalClass
{
public: // or even protected or private for some of them!
Your IDE or a script might even be handy to generate this by default (with additional Doxygen comments for good measure).
%% Cell type:markdown id: tags:
### [Advanced] The true canonical class
Why _almost_ canonical class? Because C++ 11 introduced a very powerful **move semantics** (see the [notebook](/notebooks/5-UsefulConceptsAndSTL/5-MoveSemantics.ipynb) about it) and so the true canonical class is:
%% Cell type:code id: tags:
``` C++17
class TrueCanonicalClass
{
public: // or even protected or private for some of them!
In my programs, I like to declare explicitly all of them, using `default` and `delete` to provide automatic implementation for most of them.
I admit it's a bit of boilerplate (and to be honest a script does the job for me in my project...), if you don't want to there are in fact rules that specify which of them you need to define: for instance if a class requires a user-defined destructor, a user-defined copy constructor, or a user-defined copy assignment operator, it almost certainly requires all three. See [this cppreference link](https://en.cppreference.com/w/cpp/language/rule_of_three) for more about these rules and [this blog post](https://www.fluentcpp.com/2019/04/23/the-rule-of-zero-zero-constructor-zero-calorie/) for an opposite point of view.
%% Cell type:markdown id: tags:
# References
[<aid="cit-Meyers2005"href="#call-Meyers2005">Meyers2005</a>] Scott Meyers, ``_Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)_'', 2005.
