Ce cours introduit la programmation orientée objet (encapsulation, abstration, héritage, polymorphisme) en l'illustrant en langage C++. Il présuppose connues les bases de la programmation (variables, types, boucles, fonctions, ...). Il est conçu comme la suite du cours « Initiation à la programmation (en C++) ». Comme son prédécesseur, ce cours s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.
Surcharge d'opérateurs : surcharge interne
Loading...
En provenance du cours de École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en C++)
181 notes
École Polytechnique Fédérale de Lausanne
181 notes
À partir de la leçon
Surcharge des opérateurs
Cette semaine nous étudions comment étendre les opérateurs du langage C++ à nos propres classes.
Rencontrer les enseignants
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
In this episode,
we will keep discussing operator overloading.
This time, we will focus on the inner overloading.
In the previous episodes,
we have indeed learnt that an operator could be overloaded
either outside a class
(in this case, it is a usual, non-member, function)
or inside a class (in this case,
it is a member function belonging to a class).
For example, let us say we have defined the operator "+"
for complex numbers through a function.
Then, when we write something like "z1 + z2" where z1 an z2 are "Complex",
this corresponds to a call
to the function "operator+ "
taking z1 and z2 as arguments.
The first operand corresponds to the first argument of the function,
and the second to the second argument of the function.
A possible alternative would be to defne the operator "+"
through an inner overloading.
This means we will place this operator's definition
inside the "Complexe" class.
Since it is a member function,
we will need to call it through an object.
Therefore, when we write this,
it does not correspond to the same thing as in the case of outer overloading.
This will be translated to a call to a member function
which looks like this.
The first operand is the current object on which the "operator +" is applied.
The second operand will correspond to the argument of the member function.
As we can see, in the case of inner overloading,
we only need one single argument
which corresponds to the second operand.
Let us sum up. If we wish to realize the inner overloading of a given operator,
we will place the member function "OperatorOP" inside a class.
Just as we did for other member functions, we will simply place,
inside the class, the prototype of the operator.
Then, we will give the operator's definition outiside the class.
In this external definition, the operator will have
to be bound to the class
it belongs to through to scope resolution operator;
this is essentially the same as the other member functions we have seen.
A keypoint you have to remember
is that the first operant of such an operator is the current instance.
Therefore, this instance will not be passed as parameter.
Member functions will only receive as parameter
a possible second operand.
Let us now see a concrete example : the operator " += ".
We will proceed to its inner overloading in the "Complexe" class.
Usually, the " += " operator has the following semantics :
" add to z1 the value of z2 ".
Unlike the operator " + " which we have discussed previously
and was tasked to create a new "Complexe"
from these two existing complex numbers (by summing them),
the operator " += " will modify its first operand.
As we can see, the " += " operator we have chosen as example
is an operator very close to the objects of the "Complexe" class;
indeed it has to modify their content.
In such a case, we usually resort to an inner overloading.
This is translated into the following code.
The operator " += " is thus defined as a member function of the "Complexe" class.
Its only argument is the second operand.
For the purpose of readability, we will place the definition outside the class.
However, this is not mandatory.
The definition can be written like this :
To the attribute "x" of the current object (that is, the first operand),
we will add the value of the attribute "x" of the second operand.
We will do the same for the second attribute.
Now, we know how to define the operator " += "
by using the inner overloading. Now, we are wondering :
How can we define the operators " += " and " + " one with the other.
The fundamental idea is to establish a semantic link between the two.
This link exists anyway, and we would like to set it up
so that our way to add complex numbers
remains coherent from one operator to the other.
By nature, the operator " += " requires les processing that its " + " counterpart;
indeed it does not create any new complex number.
It is rather natural to define the more demanding according to the less demanding
rather than the opposite. This is what we will do now.
In order to understand the body of the "operator+" member function redefined through " += "
in the way we have proposed here, we will use a simple example.
Let us suppose we have two complex numbers
c1 and c2
initialized in a certain way.
Now, we are trying to write the algorithm to compute the sum of c1 and c2
using the operator " += " for complex numbers.
We thus wish to compute a new "Complexe", let us call it "tmp";
it will be the sum of c1 and c2.
Let us ponder on how to compute the value of "tmp" through the " += " operator.
We realize we simply have to copy the value of c1 into "tmp"
and apply the operator " += " to "tmp"
in order to add the value of c2.
Ultimately, we obtain, inside "tmp"
the sum of "c1" and "c2" by proceeding this way.
In order to make sure of this, let's make a little drawing.
The declaration of this "Complexe" will correspond to this situation in the memory.
We have a Complex-type object c1.
Its members " x " and " y " will be initialized like this.
Similarly,
the object c2 will look like this.
The "tmp" object
first build on this line by copying from c1,
Its members x and y will initially
be the values copied from c1.
Then, we will apply the
operator " += " to "tmp".
Thus, executing this line,
we will apply the operator "+= ". Thus, we will add to the " x " of "tmp"
the value of the " x " of c2.
We thus get the value 8.0 here.
Also, we will add to the " y " of "tmp" the value of the " y " of c2.
Thus the value 5 here.
We can clearly see that the "Complexe" computed through the operator " += "
corresponds indeed to the sum of c1 and c2.
This is exactly this algorithm applied
in the version you can see here. There is one subtlety,
related to this passage by value here.
Indeed, we are using this header for "operator+",
which is the recommended header since C++ 2011.
Thus, when we write something like "c1 + c2"
(thus calling this operator " + " )
what will happen is that the value of the "Complexe" c1 will be copied into z1.
z1 is an area local to the function "operator+"
on which we can work and which will be finally returned.
We thus realize that
z1 plays exactly the role of "tmp".
Therefore, it is pointless to redefine, in the body of "operator+",
another intermediate variable
in which we could copy the first operand here.
This role is already fulfilled by the parameter passed by value here.
In other words, the copy of the first operand c1,
done in an intermediate variable "tmp"
is realized de facto upon this by-value call here.
Naturally, the algorithm described here is placed inside a function.
Once the computation is complete, the value will be returned;
this is precisely done here.
We thus get a definition of the operator " + "
done through " += ". This definition is very concise, elegant
and mostly establishes a semantic link
between the operator " += " and the operator " + ".
These two operators should not be defined separately.
Please note that this way to define the header using a passage by value
lets the modern compiler C++ 2011 to process many an optimization.
By the way, this new version of the operator " + ",
defined through " += ",
has the edge of sparing us the trouble of using getters
which were necessary for the external function
to access the private attributes of "Complexe".
These getters are not necessary anymore which is good for the encapsulation.
We know that getters running rampant
can nefarious to the encapsulation.
Thus, we can use outer overloading or inner overloading for operators.
In certain cases though, we do not have a choice as to how to proceed.
For example,
for the printing operator we have seen in the previous episode,
we can only overload it with a (non-member) function.
In some other cases, we may choose between the two.
For example, regarding the operator " + ", which we have encountered already,
it is perfectly possible to define it through an inner overloading,
like this.
It is also possible to define it through an outer overloading;
we have done just that in the previous examples.
Be careful though,
we have seen that, during the external definition of an operator,
we could be tempted to use the "friend".
In the previous examples,
we have always avoided to do so.
Some people could be tempted to do it nonetheless;
it is a very poor idea, breaking the encapsulation
and not a good way to proceed.
This leads us to a few recommendations regarding methodology.
This concerns the choice between inner overloading
and outer overloading for a given operator.
First recommendation :
it is usually recommended to prefer the outer overloading
every time we can do so without having to resort to the "friend" keyword
in the body of the function.
This means, every time we can write the operator
through the member functions of the classe's interface without useless copies.
This was the case with the operator " + " which we could define
without resorting to the "friend" keyword.
In this case, it is thus recommended to define this operator
through an outer overloading, with a function.
On the other hand, if the operator is close to the class,
as was the case before with the operator " += ",
which required the instance to be modified
and thus internal access,
and possibly supplementary useless copies.
Then, in this case,
it is much better to use inner overloading.
You now know all the basics
on operator overloading. In the last episode,
we will discuss the sharper aspects
and will bring the light on a few points,
left in the dark until now.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
