In the previous episode,

we have presented, in a very general way,

the concept of operator overloading.

Now, we know that two kinds exist : the internal overloading

and the external overloading.

In today's episode, we will thoroughly focus

on the external overloading.

External overloading consists of defining the operators

as usual functions (as opposed to class member functions).

For example, this function "operator+", taking here 2 complex numbers

in order to define the addition operator "+" for the class representing complex numbers.

Let us thoroughly examine this example.

Let us suppose we have defined a "Complexe" (= "Complex") class.

We have declared 3 instances of this class : z1, z2 and z3.

Now, we wish to compute the addition : "z3 = z1 + z2 ".

In the case of the external overloading,

where the operator is a function,

it corresponds, be reminded, to the call " z3 = operator+(...) "

with z1 and z2 as arguments.

We thus deduce that the prototype of the function "operator+"

will take two Complex-type arguments

and return a Complexe.

This si therefore a possible prototype for the overloading of "operator+".

We may want to optimize this call

and avoid the copies due to passing the parameters by value,

doing a passage by constant reference instead.

Also, we may want to have

(this will be explained in the third episode

on operator overloading)

as return type : "const Complexe".

For now, we take it as granted; it will all be explained

in the last episode on operator overloading.

Here is thus a second possible prototype

for this "operator+" defined in external overloading.

A third solution, which is the optimial solution in C++ 2011

and will also be explained in the third episode

on operator overloading,

would be to have the following prototype : "const Complex" as the return value,

a passage by value for the first argument,

and a passage by constant reference for the second argument.

Here, the passage by value may seem

a little suboptimal and conter-intuitive.

Due to the specificities of C++ 2011, particularly regarding the notion of move

instead of copy

(which stretch far beyond the content of this course)

it is ultimately the better solution.

This leaves us with the following code. Let us examine the details.

We thus have the "Complexe" class

which defines a complex number, for example 2 here, "double".

It also has a constructor

permitting to initialize its 2 attributes "x" and "y"

by receiving two values here.

For example, we could construct a complex number like this.

Here, we are passing the value 1 for "x" and the value 2 for "y".

This is the constructor we have here.

Then, we have a handful of methods necessary

in order to manipulate complex numbers.

For example, we can retrieve the value "x" and retrieve the value of "y".

Here, we have our external overloading of "operator+".

The prototype we have previously described

will be written like this.

Of course, when we write "z1 + z2" like this,

we must define a new complex "z1 + z2".

The result of the addition of z1 and z2 is a new value

which is neither z1 nor z2.

We will here define this new value

and build using our two-parameters constructor.

Actually, the formula for the addition of two complex numbers

is done by retrieving the "x" of z1 and the "x" of z2,

and adding up these 2 "x".

For the "y" component, we will retrieve the two "y" values

and compute their addition.

Here, we are indeed constructing a complex number

corresponding to the definition of the addition of z1 and z2.

We return this complex number

as the return value of "operator+".

Also, the most advanced out of you will of course note

(though it is a detail)

that we could regroup these 2 lines.

Thus, we could simply write "return Complexe(...)", without giving any name.

"return Complexe(...)", with here an anonymous "Complexe"

and a direct call to the constructor.

But, once again, this is advanced and does not bring much.

We have seen that there are 2 overloading ways : external and internal.

In mose cases, we may choose between

external overloading and internal overloading.

In some cases though, we cannot choose;

it is absolutely mandatory to use the external overloading.

Let us look at these cases.

The first case is when we mix different types.

For example, here, we would to do the multiplication

of a complex number and a double.

For example, we have here a double "x" and a complex number "z1".

We would like to retrive the result of "x" times "z1" into "z2".

"x" is a double-type variable, and "z1" is a Complexe-type variable.

In principle, we could choose for the rewriting

between "z2 = x.operator* " with an internal overloading (call to a method)

or "z2 = operator* (x, z1)" (call to a function).

However, it is obvious that the first line makes no sense at all.

Indeed, "x" is not a class instance

but a so-called basic type, a double.

"double" is not a class, there are not methods in "double".

This solution is thus impossible.

Here, we have no choice but to resort to the external overloading,

thus using functions.

Similarly, in the case where we would like to print a complex number,

for example doing "cout << z1 ",

using the overloading of the printing operator less than-less than (<<),

we could have two possible ways to write it.

Either with the method "operator<<" of the class where "cout" is an instance

(the class "ostream");

in this way, we are calling the method of this "ostream" class,

or, we could use a function taking here the 2 parameters "cout" and "z1".

However, here, we only care about overloading the "Complexe" class

and definitely not about meddling with the "ostream" class

where "cout" is an instance.

There, in this case, aswell,

we will never use the internal overloading of the "ostream" class.

Instead, we will prefer the external overloading.

Let us thoroughly examine these 2 examples, starting with the outer multiplication.

Be reminded that we have declared a double, "x" here.

We also have two "Complexe" : z1 and z2.

We wish to compute the multiplication of "x" and "z1"

and store the result into "z2".

The equivalent call would be

"z2 = operator* (x, z1); ".

This gives us the prototype.

The function returns a complex number.

For the same reasons, which will be explained later,

we will rather pick "const".

We will have "operator* " and then,

we are taking a "double" and a "Complexe".

For optimization reasons, we will pass it by constant reference.

We thus end up with the following prototype.

For the definition, we could

either write all the operations explicitly

for the multipllication of this double "a" here and this "Complexe" "z".

Or, if we suppose that the inner overloading exists

(which is very possible for complex numbers

but not possible for all classes).

But when it is possible,

that the internal overloading exists

(please note we have swapped the other and started by multiplying by "z" ).

Since something exists able

to do "Complexe" times "double",

that is, either an internal overloading

of the "Complexe" class

taking a double,

or an already written, external overloading,

the multiplication of "Complex" first by a "double" then

(no matter which solution is chosen).

What matters is that

writing "a" times "z"

is mathematically the same thing as "z" times "a".

In such a case, with this kind

of equality, we do not want

to write the same code twice but instead use already written code.

For the printing operator,

we may wish, for example, to do "cout << z1 ".

Here, z1, is of course a complex number.

Be reminded that the equivalent call

would be an external overloading of the function

"operator<<" with "cout" and z1 as arguments.

This gives, as the prototype of the function :

"operator<< ". Here is the type of "cout"

and here a "Complexe" which we pass once again,

for optimization reasons,

by constant reference.

By the way, "cout" is, an instance of the "ostream" class,

is passed by reference.

Indeed, the very printing "cout << z1 "

will indeed modify "cout"

since we will write informations on "cout", thus modifying it.

Since we are modifying this argument,

we absolutely need to pass it by reference.

We will give you the return type of this function right away

so that you may write correctly

this printing operator. The return type is also an "ostream&".

The reason behind this type will also be explained

in the last video on operator overloading,

regrouping all these subtleties.

Let us now move on to the definition

of this printing operator for complex numbers.

The first solution is to use getters,

for exemple "getX" or "getY",

returning the attributes we wish to print.

This leads to the following :

Here we have received, as the first parameter,

the output stream on which we wish to write.

We are using this stream to print,

for example, a parenthesis here.

Let us say we have a complex number

where "x" is 3 and "y" is 4.

The idea is to print " (3, 4) ";

this is the desired format for the printing here.

Therefore, we write the opening parenthesis,

then we retrieve the "x" of the complex which we have received as the second argument

of this "operator<<" function.

We now print the comma.

Then, we print the retrieved value

for the attribute "y" of this complex number "z".

Then, we finish with the closing parenthesis.

Then we do not forget,

because of the return value "ostream&" here,

to finish our function with a "return" of the output parameter.

For now, please consider this mandatory

in order to avoid unpleasant "segmentations faults"

so that you can use "operator<<" correctly

just like you do for int and double.

A second possible definition is to use

a previously defined method

either to convert a "Complexe" into a character string

or to directly print a complex.

Let us look at this first solution.

Here, we are again using the received stream to print

the result of the call to the method "to_string"

which transforms a "Complexe" into a character string.

In its prototype, the return type is typically a

a character string,

that is, "string".

The method belongs to the class "Complexe"

and is called "to_string".

It does not take any parameters.

Also, it does not modify the current instance;

indeed, modifying a "Complexe" into a character string

does not modify this "Complexe".

Therefore, we will call this method

here, in "operator<< ".

As previously, we finish

by returning the first received argument.

Another solution could to directly have a method

"affiche" working just like "operator<<". (TN: "affiche" means "print").

However, it would be a public method in the class

receiving the stream on which we print

and return this stream.

Therefore, its prototype is very similar

to the one of the printing operator,

thus returning an "ostream".

It is a method of the "Complexe" class.

It is called "affiche", and it takes, as parameter,

a stream it modifies. The stream is thus passed by reference.

This method does not modify the printed complex number;

when we print a "Complexe", we do not modify it.

We conclude here with the keyword "const".

Those were three possible examples of definition of the printing operator

for our "Complexe" class.

You may freely draw inspiration for your very own classes.

By the way, please note (we are anticipating on a later subject)

that it is prefearable to use these kinds of methods "to_string" or "affiche"

when we will be dealing with polymorphism

which will come later.

When we are doing external overloading,

it is sometimes necessary to access private attributes

of the class on which we wish to apply the operator.

Even if we think it is bad programming,

and that we truly advise you to only use getters

and the interface (the public part of the class),

you may sometimes encounter this kind of practice

(though we do not recommand to write it yourself) :

here, you could be tempted to write "z.x" or here "z.y",

that is, to directly access the

private attributes "x" and "y" of the "Complexe" class.

In this case, we need to give a priviliged access

to this function, since it is outside the "Complexe" class.

to give a privileged access to the private parts.

We call this : declaring a friendship

thanks to the keyword "friend".

Once again, we strongly recommand that you rather

use getters,

that is, the public part of the class

rather than the private part through this indirect way

that is the keyword "friend".

However, since you may encounter it, we will present it.

If you have to disregard our advice and use a friendship,

you will put, in the very definition of the class, a line like

"friend" followed by the prototype of the function you wish to have

access to the private parts of the class.

Thus, we do it like this :

"friend" followed by a the prototype of a function.

This gives us the right to access

the private methods and attributes of the class.

Please note that the definition of these functions

remains, of course, outside the class.

Indeed, these functions have nothing to do with the class.

We simply indicate in the class

that we are giving access rights to these external functions.

Let us look concretely what it would look like

for complex numbers.

Here, we have the "Complex" class. The private parts

are the attributes "x" and "y".

Here, we have our printing operator

for complex numbers.

All is as before.

However, we have not followed the aforementioned advice

(we do not recommand you do the same, of course).

Here, we are trying to access the private parts.

If we do not do anything particular,

we will end up with a compiling error here :

we are not allowed to access the private parts

with an external function.

In order for this to work properly,

we need to add, in the "Complex" class,

a line giving access rights (giving the "friendship")

to this external function. We are simply putting its prototype

after the keyword "friend".

Adding this line

means the given function can now access

the private parts.

Personally, we daresay this is a very poor idea,

for it breaks the encapsulation.

This concludes our episode on the external overloading.

In the next episode, we will discuss the internal overloading.

Also, we will tell you in which cases

you should prefer either of these two overloading ways.

Finally, in a last video,

we will go back to all the details

we have left aside.

Surcharge d'opérateurs : surcharge externe

Introduction à la programmation orientée objet (en C++)

Meet the Instructors