Collections hétérogènes

Loading...

Del curso dictado por École Polytechnique Fédérale de Lausanne

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

192 calificaciones

École Polytechnique Fédérale de Lausanne

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

192 calificaciones

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.

De la lección

Polymorphisme

Cette semaine nous abordons la quatrième et dernière notion fondamentale de la programmation orienté objet : le polymorphisme.

Polymorphisme et résolution dynamique des liens 10:57

Polymorphisme : méthodes virtuelles 17:24

Masquage, substitution et surcharge 19:11

Classes abstraites 13:55

Collections hétérogènes 17:10

Collections hétérogènes : compléments avancés 18:25

Conoce a los instructores

Jamila Sam
Dr
School of Computer and Communication Sciences
Jean-Cédric Chappelier
Dr.
School of Computer and Communication Sciences

In this episode, we will go over the details of

one of the important applications of polymorphism, known as

"heterogeneous containers"

Up to now, we have seen that inheritance and virtual methods allow us

to define generic functions accessible to all instances of a class hierarchy

This is polymorphism.

We learned that if we want to use functions or methods

in a polymorphic way,

that is, apply these functions to objects in a polymorphic way,

then these objects must be passed by reference.

What if we have a set of objects, a collection of objects (a.k.a. an "container")

belonging to a hierarchy which we wish to be able to manipulate

in a polymorphic way?

This is known as a "heterogeneous container".

Meaning that each object stored in the container, in the set

can have slightly different, specific behavior.

Let's illustrate this with the example of our game with the characters.

We had a Personnage class with a certain number of members

and specific methods, and different subclasses:

thieves, magicians, warriors etc, who were all characters.

We wanted to put them in a game that would contain several characters.

So we would have a collection of characters, but we want each

character to behave according to their real nature.

A warrior will behave as a warrior, a thief as a thief, etc.

So this collection will be "heterogeneous".

How do we define the game in this case?

We could define the game like this, of course:

having a specific container for each of the subclasses, that is,

having a container for all of the warriors

one for the magicians, etc.

Then we could display all of the warriors through a method

allowing to display the warriors,

display all the magicians through another specific method, etc.

We could add a warrior to the game,

or add a magician, a thief, etc.

This solution is possible and in some cases,

it will be necessary to differentiate between the subclasses

and to have specific containers for each of the subclasses.

They will not be heterogeneous containers.

There would be as many specific containers as subclasses.

That solution is quite possible, but we could imagine

a different solution.

It depends on the context, on the needs of the program,

where we could imagine managing all the characters in a global way,

to manage them generically in a container of characters.

These characters would have their own specificities,

so we would have a heterogeneous container.

In that case, we would define the "Jeu" class like this

We would have a collection of characters, in the form of a vector

which would group all our characters.

We would only have one "afficher" method

that would display all of the characters.

And we would have a generic method here, "ajouter_personnage" which would allow us

to add a generic character to the collection.

In this context, we would want each of the characters to have

their own behavior and so if "personnage[i]" is a warrior,

then the method "personnage[i].afficher" would call the afficher method of the

warrior subclass.

We would want to have a polymorphic behavior

for the characters stored in the game.

Unfortunately, the code we have present up til now does not allow

polymorphic behavior. Indeed, here we have

a vector of characters and we access the characters

directly without passing through a reference or a pointer.

However, remember that polymorphic behavior is only possible

with virtual methods, as well as

either pointers or references.

Which one should we use here?

I'll remind you of a general piece of advice concerning pointers and references:

Use references whenever you can,

and pointers when you must.

Here, the idea would be to use a set of references.

Unfortunately, we cannot put references in a vector

nor in any standard C++ container.

The technical reasons for this are beyond the scope of this course.

We are forced to use pointers here.

So we will change the implementation of our Jeu class to have

a vector of pointers to characters.

To have polymorphic behavior for our characters, we will have

an vector of pointers-to-Personnage.

The question we could ask ourselves here is, do we want to use

"C-style" pointers or "smart pointers", C++11 pointers?

So here is an alternative, a C++11 version.

We recommend you use this second approach.

We will detail the reasons for this choice in a extra, optional episode

which will follow this episode.

If you follow our su"ggestion and use "smart pointers

in the C++11 style, you will define a vector of unique pointers to Personnage.

To use unique pointers, remember to include

the <i>memory</i> library.

For those who would like reminders on pointers, we have uploaded

all of the courses that we gave on pointers

from our previous MOOC, Introduction to Programming.

I encourage you to

review these courses if necessary.

So here, we could use either solution.

In any case, note that it is pointers that

will be stored in this container.

The "personnage" vector here is a vector of pointers, and no longer

of instances directly. This will have some influence

on the design and execution of the game, since the instances

are now outside of the Jeu instance.

In Jeu, we only have pointers to the instances.

How do we continue developing our Jeu class and adding

these methods for displaying or adding characters, for example?

The easiest is to first look at how we will use this game, this instance of Jeu.

So, we would declare a game, an instance of Jeu, and imagine that

we want to add a character.

But we have to add a pointer. The easiest is to add a pointer

allocated dynamically with a "new". For example here, we create a new warrior,

"new Guerrier", which will return a new pointer to a warrior.

So in memory, we would have the following situation:

a <i>Jeu</i> which has a set of pointers.

At first, it is completely empty.

Then, we create a warrior in memory

and the "new" would return a pointer to this warrior that we would store

in our container.

So the prototypes for our methods would be:

here, a "ajouter_personnage" (TN: means "add_character") method that would

take a pointer to Personnage.

This is what it receives, as new returns a C-style pointer to a Personnage.

Then the afficher method which doesn't pose any problems,

which displays all the characters.

So we would have the usual prototype for this display method.

Now, let's see how we can define these methods.

Let's start with the method that adds a character.

Its prototype takes a C-style pointer to a character

to allow a call as we have just seen.

We start, to be safe, by checking that we have indeed received, through

the "nouveau" (TN: means "new") pointer here

a pointer to a real Personnage instance.

So we check that the pointer is not null.

Then we add it to the character container.

Remember that we decided to

implement the character container as a vector of

unique_ptr's to Personnage.

So we simply add it with a "push_back"

The C-style pointer, "nouveau", returned by the call to "new"

will be transformed to a unique_ptr.

Because new returns a C-style pointer and we have decided to

implement our pointers as C++11-style "smart pointers",

we will transform this C-style pointer here into a unique_ptr.

Let's go over the previous call in detail,

" jeu.ajouter_personnage (new Guerrier) ". (TN: means "game.add_character(new Warrior);")

We call the constructor with parameters

for Guerrier's constructor. It will do the following:

first, it will execute new Guerrier, which will create a new warrior

in memory.

New will return a pointer to this allocated memory area.

This pointer will be passed to the ajouter_personnage method

and be called "nouveau".

This pointer is not null.

So we arrive here

in the Jeu class and do a push_back.

Suppose that this vector was initially empty.

So we execute this push_back which will add an element to our vector

in which we will add the result of the transformation of this C-style pointer

to a unique_ptr pointing to the memory area allocated by the new statement.

Now, let's talk about the "afficher" method.

Suppose that each character has its own afficher method

which is polymorphic.

So we simply need to do this, to loop over all of the characters stored

in the vector of pointers to characters,

and to call the afficher method

through this pointer. This is exactly why we have pointers,

to have a polymorphic behavior.

However, this code does not compile.

Indeed, our "Personnages" collection is a vector of

unique_ptrs, of unique pointers.

There cannot be more than one pointer to a given memory area.

In memory, we have something like this:

a vector of unique_ptrs pointing to characters.

When we write the for loop,

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.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play