when we write the for loop like this, it happens the the "quidam" variable
is another variable that will
take the value of each of the elements of the personnages vector, one after the other.
So quidam is a pointer that will point to the same area
as the various pointers to our characters, one after the other,
as they are stored in the vector.
So for example, the first step, which is to say that quidam equals this pointer,
means that two pointers are equal, they point to the same area.
This is impossible, due to the fact that we have unique_ptrs here.
We can only have one pointer per memory area.
So this solution is unacceptable.
To do this, we need a reference to the stored objects,
a reference to the unique pointers. That is quite possible.
So the correct for loop is written like this:
"for auto reference", of course here we will not modify anything,
as the display method is const, so we can use a "const reference".
So "for auto const reference"; quidam is now
a constant reference to the elements of the personnages vector.
That is, a constant reference to unique_ptrs.
This is a subtlety of unique pointers.
Now, let's see how we can use our Jeu class.
Here, we would declare a game and add characters to it
by calling the ajouter_personnage method and creating them dynamically with new.
We have a new warrior here, with parameters for its constructor.
Then we add a new magician, a new thief,
perhaps another new warrior, etc.
When we want to display the game, we simply call jeu.afficher.
But this innocent Jeu class nevertheless hides a potential danger.
What happens if one of the objects we added to the collection,
-- or rather, whose address we added to the collection -- what if one of these objects
were to disappear?
In that case, we would still have a pointer to that object in the vector
despite this object being destroyed, and this could cause big problems.
For everything to work correctly, it is absolutely necessary
for all of the elements that are pointed to to last at least as long as their pointers.
So in this example, all of the characters in the game must exist
at least as long as the game.
And it is up to the programmer to ensure that with good design.
So, it is up to the programmer not to make this kind of mistakes.
For example, imagine a slightly naive programmer who wants to create a function
to create and add a magician into the game
This function would modify the game, and take a reference to the game
and it would create a magician here,
passing parameters to its constructor and then,
it would call the ajouter_personnage. And since we must pass pointers
to add characters,
it passes the address of this magician here
And so in the main, we would have the game.
We call this "creer_magician" function.
We pass the game by reference to add a magician to it.
Then we display the game
The problem is that this creer_magicien function adds
a new magician which is a local variable.
It is important never to do this sort of thing,
never to add local variables.
This local variable will cease to exit: "mago" here will cease to exist as soon as
we exit the function.
So here, we will have added a pointer to a magician via
a reference, but this magician will no longer exist
as soon as we exit the function that created it.
So, from this semicolon here, we should never try to access
this magician.
We should not try to display it anymore.
So here, we know what will happen, we will display a magician
that potentially does not exist anymore.
I say potentially because on some machines,
as this code is relatively short, nothing bad may actually happen.
But if you imagine several lines of code with several manipulations
between this function call and this display here,
then it is virtually certain that you will get a nonsense result.
So, never do such a thing!
Never take the address of a local variable,
never use the address of a local variable like this
The correct way to do this, to solve this sort of problem is to use
what is called dynamic allocation and to guarantee that the allocated memory area
will be preserved for at least as long as its container.
So for example, here, the creer_magicien method which takes a game by
reference, would add to this game a dynamically-allocated magician
as we have done up til now. This new will trigger a dynamic allocation
and the memory area will exist as long as we don't call delete.
In the case of a container where we manage pointers through unique_ptrs,
we don't even need to call delete. The memory will be freed automatically
by the unique_ptr as soon as it is no longer used.
This is one of the advantages of unique pointers.
This is why we recommend you use
these "smart pointers", these unique pointers at first.
You will not need to bother about
freeing memory, so you will not risk accidentally freeing memory while
it is being used. However, the pointer
will automatically be freed as soon as we no longer use this memory area.
Now, the second aspect, the unique aspect.
The smart aspect of the pointer handles deallocation,
and the unique aspect prevents having multiple references to the same area.
As we saw in the example of the for loop, this introduces a few constraints.
But it is a big advantage to have only one pointer to a certain
object. That way, the object truly belongs
to the container to which it is supposed to belong.
There are no other places in the program pointing to this object
and that could modify it.
These are the reasons why we recommend you use, at first,
unique_ptrs
Now, we could also use C-style pointers.
If you wish to learn about this, we have produced another episode,
an optional one, which will detail this solution
and should thus shed more light on the advantages of unique_ptrs.
