Réponse.

Historique de la question :

En C++, le travail avec la mémoire est fondamental, le langage offre au programmeur un contrôle total pour des raisons d'efficacité. Initialement, il n'existait que les concepts de "pile" (stack) et de "tas" (heap) comme zones d'allocation mémoire dynamique et automatique.

Problème :

Le choix de la zone de localisation d'une variable définit sa durée de vie, sa disponibilité, la vitesse d'allocation et de désallocation de la mémoire, ainsi que les risques (fuites, corruption de la pile, fragmentation).

Solution :

L'allocation de mémoire sur la pile est utilisée pour des variables locales avec une durée de vie connue. L'allocation sur le tas est pour des objets nécessitant une durée de vie dynamique ou un grand volume de mémoire. Il est recommandé de minimiser la gestion manuelle du tas, en privilégiant la pile et en utilisant des pointeurs intelligents pour la gestion de la dynamique.

Exemple de code :

// Allocation sur la pile
int a = 5;

// Allocation sur le tas
int* b = new int(10);

// Travail avec un pointeur intelligent
#include <memory>
auto ptr = std::make_unique<int>(15);

Caractéristiques clés :

• Pile : rapide, automatique, taille limitée, étendue de visibilité — fonction.
• Tas : dynamique, nécessite une désallocation explicite (ou des pointeurs intelligents), grands volumes, durée de vie flexible.
• Le mélange peut conduire à des erreurs et des fuites.

Questions pièges.

Que se passe-t-il si on retourne un pointeur vers une variable locale à partir d'une fonction ?

Cela entraînera un comportement indéfini : après la sortie de la fonction, la mémoire "est libérée" (en réalité, la pile n'est pas vidée, mais les données peuvent être écrites à nouveau).

Exemple de mauvais code :

int* foo() {
    int a = 42;
    return &a; // incorrect !
}

La mémoire allouée sur la pile peut-elle fuir ?

Non, la mémoire de la pile est toujours libérée automatiquement lors de la sortie de la portée — seule l'overflow de la pile peut survenir, mais pas de fuite.

Est-il toujours suffisant d'utiliser delete pour libérer la mémoire dynamique ?

Non, on utilise beaucoup plus souvent des pointeurs intelligents (std::unique_ptr, std::shared_ptr) pour éviter les deletes oubliés et les doubles suppressions.

Erreurs typiques et anti-modèles

• Retourner un pointeur/référence vers des variables locales.
• Utilisation de raw new/delete sans contrôle.
• Sous-estimer la limitation de la taille de la pile (récursion sans fin — overflow de la pile).

Exemple de la vie réelle

Cas négatif :

Un développeur utilisait new pour tous les objets temporaires, oubliait de les libérer — au fil du temps, des fuites de mémoire sont apparues dans de grandes applications.

Avantages : au départ rapide et pratique Inconvénients : programmes instables, augmentation de la mémoire, plantages

Cas positif :

Utilisation de variables locales et de pointeurs intelligents pour des objets temporaires et auxiliaires. Pas de delete explicite, tout est libéré automatiquement.

Avantages : absence de fuites, fiabilité Inconvénients : nécessité de comprendre les approches modernes de gestion de la mémoire