Avant-propos : description simplifiée pour comprendre comment fonctionne la mémoire et pour expliquer les notions expliquées dans ce chapitre. Mais l'organisation et la gestion de la mémoire est beaucoup plus complexe : il y a plusieurs types de mémoire, plusieurs niveaux d'organisation logiciel, gestion par le système, etc.

La mémoire peut être vue comme un immense tableau d'octets. Dans ce tableau, l'index est l'adresse mémoire, chaque octet peut donc être identifié de manière unique par son adresse.

figure

Object font 1 a plusieurs octets. Un objet simple est un bloc de plusieurs octets continues. Pour connaître la taille d'un objet : sizeof.

copie = création d'un objet identique en mémoire. C'est-à-dire que les octets sont identiques, mais avec une adresse différente. On obtient 2 objets valides.

figure

Deux objets copiés sont indépendants. Si on modifie ou supprime l'un, l'autre n'est pas modifié.

Tous les objets ne sont pas copiables. Les types fondamentaux (int, float, etc) sont par défaut copiable. Pour les objets plus complexes, cela dépendra de la sémantique que l'on veut donner à sa classe (sémantique de valeur). La majorité des classes de la STL (Standard Template Library) ont une sémantique de valeur. (ce sera détaillé dans la partie POO).

déplacement = changement de l'adresse d'un objet, l'objet est conservé à l'identique. L'objet initial n'est plus valide.

figure

En pratique, un déplacement peut être une copie déguisée : copie puis suppression de l'objet initial (dans ce cas, le déplacement aura le même coût que la copie). Ça sera le cas des types fondamentaux. Pour des objets plus complexes (par exemple std::string, std::vector, etc), toutes les données ne seront pas copiée. (dans ce cas, le déplacement sera beaucoup moins couteux que la copie).

void g(int j) {}
 
void f() {
    int i { 123 };   // non const, le déplacement est une modification
    g(std::move(i)); // l'objet contenu dans la variable i est déplacé dans
                     // la variable j de la fonction g, i devient invalide
}

Concerne aussi la sémantique de valeur. Mais indépendant de la copie (c'est-à-dire un objet peut être copiable et movable, copiable et non movable, ou non copiable et non movable)

Indirection = “objet” qui permet d'accéder à un autre objet à distance. Utiliser une indirection revient à utiliser l'objet qui est lié à l'indirection.

image

Si A est un objet et si B est une indirection sur A, alors utiliser B revient à utiliser A.

Exemple d'indirection déjà vu : les itérateurs. Un itérateur est une indirection sur un élément d'une collection. Accéder à l'itérateur revient à accéder à l'élément.

#include <iostream>
#include <vector>
 
int main() {
    std::vector<int> v { 1, 2, 3, 4 };
    auto it = std::begin(v);
    std::cout << (*it) << std::endl;
    (*it) = 5;
    for (auto i: v) { std::cout << i << ' '; }
    std::cout << std::endl;
}

affiche :

1
5 2 3 4 

it permet d'accéder au premier élément du tableau.

Le problème de la validité d'une indirection a déjà été abordé pour les itérateurs. Pour rappel :

#include <iostream>
#include <vector>
 
int main() {
    std::vector<int> v { 1, 2, 3, 4 };
    auto it = std::begin(v);
    std::cout << (*it) << std::endl;
    v.clear();
    std::cout << (*it) << std::endl;
}

Après l'appel à clear, l'élément correspondant à l'itérateur n'est plus valide et utiliser it produite donc un comportement indéterminé.

Et retenez surtout qu'un “undefined behavior” ne produit pas forcément un crash (c'est le cas de ce code, il semblera valide à l'exécution, mais pourra faire n'importe quoi) et ne produira JAMAIS d'erreur de compilation.

Ce qui est valide pour l'itérateur est valide pour toutes les indirections : il faut que l'objet correspond à l'indirection soit valide, sinon l'indirection est invalide et l'utiliser produit un “undefined behavior”.

classification :

• peut être null ou non (la référence doit toujours être valide)
• managé ou non = responsable de détruire l'objet (référence = non managé)
• affectable ou non (référence = non affectable)
• cas particulier des itérateurs (indirection sur élément d'une collection)

Il n'y a pas besoin de voir en détail toutes les indirections, certaines sont moins utilisées et seront vues dans les chapitres complémentaires.

• référence (lvalue et rvalue ?)
• std::reference_wrapper (affectable)
• itérateur = indirection sur collection
• pointeur = peut être null
• pointeur intelligent = managé (partagé = std::shared_ptr ou non = unique_ptr), pointeur nu = non managé

Même si le C et le C++ sont deux langages différents, ils partagent une origine commune (d'où leur noms qui sont proches et des syntaxes que l'on peut retrouver dans les deux langages) et surtout, il est courant d'utiliser des bibliothèques écrites en C dans un programme C++.

Malgré cette origine commune, ces deux langages ont des mécanismes très différents, en particulier concernant la gestion de la mémoire. Mais dans ce chapitre, c'est un autre point qui va être abordé : les indirections.

Le langage C propose qu'un seul type d'indirection, les pointeurs null, alors que le C++ en proposent différents types (voire virtuellement une infinité, puisqu'il est possible de définir des classes implémentant des indirections, comme c'est le cas des itérateurs par exemple).

Cela peut sembler être une difficulté du C++ par rapport au C, puisque cela nécessite d'apprendre plusieurs syntaxes et concepts, là où il n'en faut qu'un seul en C. En fait, chaque type d'indirection apporte des fonctionnalités et garanties différentes, ce qui peut simplifier le code. Il est donc important de bien comprendre les spécificités de chaque type d'indirections et de les utiliser correctement.

Au contraire, en C, les pointeurs null seront utilisés comme indirection sur un objet, comme indirection sur un élément d'un tableau ou pourront même représenter un tableau. Il n'est pas possible de savoir ce que l'on peut faire ou non avec un pointeur uniquement en regardant son type (idem pour le compilateur, ce qui veut dire qu'il ne peut rien vérifier), il faut regarder le contexte d'utilisation du pointeur pour savoir comment l'utiliser.

Un dernier point sur les indirections : il est courant de trouver dans des codes C++ (sur internet ou dans de vrais projets) qui sont en fait des codes C (généralement du C++ écrit en utilisant les pratiques du C). Dans ces codes, vous verrez régulièrement des pointeurs null, puisque c'est le seul type d'indirection disponible en C. Cependant, en C++, les pointeurs null sont le type d'indirection qui apportent le moins de garanties et leur utilisation doit donc être limité aux profits des autres types d'indirection (en premier lieu les références).

Faites bien attention d'identifier les codes C++ problématiques et corrigez les si nécessaire.

Pourquoi présenter les indirections dans la partie sur les fonctions ? Les indirections sont utilisables en dehors des fonctions (en particulier les itérateurs), mais elles sont particulièrement intéressantes avec les fonctions.

On va se limiter à un type d'indirection : les références.

Explications simplifiées pour comprendre la mécanisme. Stack en anglais.

Lorsqu'une fonction est appelée (cas particuler pour la fonction main qui est appelée par le système), cela créé en mémoire un contexte pour cette fonction. Ce contexte contient les informations nécessaires pour l'exécution de la fonction, en particulier la mémoire correspondant aux variables locales de la fonction (ainsi que les paramètres d'appel, que l'on peut considérer comme des variables locales).

void f(int i) {
    double d;
    bool b;   
}

image (contexte d'une fonction avec ses variables locale)

A chaque fois qu'une fonction est appelée, le nouveau contexte “s'empile” sur les précédents (on parle de “Pile d'appel des fonctions”).

void h() {}
 
void g() {
    h();
}
 
void f() {
    g();
}

image (état de la pile après chaque appel et retour)

Lorsque f est exécutée, la pile contient le contexte d'exécution de f. Après l'appel de g, la pile contient f et g, puis après l'appel de h, la pile contient f, g et h. Après le retour de h, la pile contient à nouveau f et g, et après le retour de g, la pile contient f.

Note : mémoire = très gros tableau d'octets. l'“empilement” est conceptuel, il n'y a pas de notion de “dessus” et “dessous” dans une mémoire.

Contexte d'une fonction

Le contexte d'une fonction est l'ensemble des variables qu'une fonction peut utiliser.

void g() {
    i = 123; // erreur
}
 
void f() {
    int i {};
    g();
}

Exception :

• variables globales, accessibles partout. A éviter (complexifie la lecture du code)
• les littérales (il faut bien qu'elles soient quelque part dans la mémoire. Elles sont dans un espace dédié, le data segment. Et il y a un segment spécifique pour le texte. Mais tout cela est géré en interne par le compilateur, pas besoin de s'en préoccuper).

Taille limite de la Pile

Il existe une limite à la taille de la pile (par exemple 1 Mo avec MSVC). Cela dépend des configurations et du système. Mais si vous essayez de créer un milliard de int dans une fonction, cela va produire très certainement un dépassement de pile. (erreur de type “Segmentation fault”).

2 conséquences :

Appeler une fonction consomme un peu de mémoire sur la pile (même si la fonction n'a pas de variable locale). Appelle récursif illimité finira donc pas saturer la pile et produire un crash.

Parfois (souvent) on a besoin d'utiliser plus que 1 Mo de mémoire (penser à une simple image en mémoire, cela peut prendre plusieurs Mo). Il existe un second espace mémoire, le Tas (ou mémoire dynamique), qui contient tout ce qui n'est pas sur la Pile.

Différences Pile/Tas

• Pile = taille très limité, Tas = beaucoup plus de mémoire (en première approximation = infini… en vrai = taille limité, espace libre généré par le système et peut changer avec le temps = besoin de gérer si la mémoire est dispo ou non)
• Pile = généré automatiquement lors des appels et retour de fonction, Tas = à gérer par le code

Cas particulier des objets complexes comme std::vector et std::string. Ils sont en fait constitués de plusieurs parties :

• une petite partie, de taille fixe, qui sera sur la Pile par défaut
• les données proprement dites (les éléments ou le texte), qui sont sur le Tas
• des indirections depuis la partie sur la Pile vers la Partie sur le Tas

image d'un vector

Des collections plus complexes (std::list par exemple) peuvent contenir plusieurs objets différents en mémoire, liés entre eux par des indirections.

En pratique, il n'y a pas de limite au nombre de sous-objets que peut contenir un objet complexe, et il peut y avoir des organisations très complexe en mémoire.

Note sur std::array : toutes les données sont sur la Pile, il y aura donc un problème si tableau est trop grand. Il est préférable d'utiliser std::vector (ou dynarray) si c'est le cas.

Remarque sur vector et copie/déplacement. Quand on copie, cela copie toutes les données. Quand on move, cela copie simplement la petite partie sur la Pile : c'est plus performant. (Mais le plus performant reste d'utiliser une indirection).

Contextes de fonctions indépendants = pas possible d'accéder directement à une variable. Comment faire ?

void g() {
    i = 123; // erreur
}
 
void f() {
    int i {};
    g();
}

On copie l'objet depuis le contexte de f dans le contexte de g. Il est alors possible d'utiliser cet objet dans g.

La syntaxe est celle déjà vue :

// déclaration
void f(TYPE NOM)

// appel
f(VALEUR)  // littérale, expression, variable

Par exemple :

void g(int i) {
    i = 123;  // ok
}
 
void f() {
    int i {};
    g(i);
}

L'objet est perdu à la fin de la fonction (sauf si retourné), donc les modifications faites sont perdues.

void g(int i) {
    i = 123;  // ok
}
 
void f() {
    int i {};
    g(i);
    std::cout << i << std::endl; // affiche 0
}

différence entre copie et déplacement ? (selon le type de value, rvalue ou lvalue, std::move)

retour de valeur

Indirection sur l'objet de f dans g. Chaque indirection a une syntaxe spécifique. Pour la référence, 2 types : const ou non.

// déclaration
void f(TYPE const& NOM)  // const
void f(TYPE      & NOM)  // non const

// appel
f(VALEUR)  // littérale, expression, variable

const = on ne peut pas modifier le paramètre, non const = on peut.

Dans tous les cas, ce n'est pas la référence que l'on manipule, mais c'est en fait l'objet dans f. En particulier, si on fait une modification dans g, elle sera visible dans f.

void g(int & i) {  // on modifie i donc non const
    i = 123;  // ok
}
 
void f() {
    int i {};
    g(i);
    std::cout << i << std::endl; // affiche 123 !
}

Note : une indirection prend un peu de place dans la Pile. Environ le même cout qu'un type fondamental (int, float, etc)

Conclusion : que faut-il utiliser ?

• pour éviter la copie = indirection. Si la copie n'est pas couteuse (types fondamentaux) ou si on a besoin d'une copie (si on veut faire des modifications sans les conserver)
• pour modifier un objet = référence non const
• par défaut (si on ne sait pas si la copie est couteuse) = référence constante.

• lvalue : variable…
• rvalue : temporaire (littérale, expression)…

• passage par valeur et référence constante : accepte lvalue et rvalue
• passage par référence : accepte lvalue uniquement
• passage par rvalue référence : accepte rvalue uniquement

void f(int x);
voif g(int const& x);
void h(int & x);
void i(int && x);
 
int x {};  // lvalue
f(x);      // ok
g(x);      // ok
h(x);      // ok
k(x);      // erreur
 
           // rvalue
f(1);      // ok
g(1);      // ok
h(1);      // erreur
k(1);      // ok

Selon le type de passage. Idem que les arguments, nécessite correspondance.

void f(int x = 123);   // ok, rvaleur vers value
voif g(int const& x = 123);  // ok, rvalue vers ref const
void h(int & x = 123);   // erreur
void i(int && x);    // ?

Ne pas retourner une indirection sur un variable locale, qui sera détruite à la fin de la fonction (donc indirection sur variable invalide).

(N)RVO : optimisation pour retour, le plus efficace. + conditions d'utilisation.

int g() {
    int i;
    return i;
}

Par valeur, mais pas de copie ici, optimisé. Note : utilisation de déplacement = désactive optimisation, moins performant.

+ cas particulier ds fonctions pure

int g(int i) {
    ...
    return i;
}
 
// alternative à
 
void g(int & i) {
    ...
}