Organisation des données en mémoire
Que ce soit sous MS/DOS, Windows (NT, 95) ou UNIX, la mémoire (physique ou virtuelle) mise à disposition de l'utilisateur est organisée de façon relativement analogue.
Schématiquement, et comme l'indique la figure suivante, une partie est réservée au code du programme, une autre aux données globales du programme, puis ce qui reste (à l'utilisateur) est accessible par les deux extrémités : d'un coté elle représente ce qui est appelé la pile d'exécution, de l'autre le tas.
Organisation des données en mémoire
Aucune de ces trois zones n'a de taille fixe, seule la somme des trois ne doit pas dépasser les limites indiquées.
Reprenons quelques-unes de ces zones :
-
la zone de données globales (appelées en C/C++ données statiques).
Lorsqu'une variable est définie dans un paquetage, en dehors de tout sous-programme, le compilateur lui réserve le nombre d'octets nécessaires pour stocker les valeurs que peut prendre cette variable (suivant son type) : 1 ou 2 octets pour un caractère, 1, 2, 4 ou 8 octets pour un entier, etc.
Cette zone se trouve à une certaine adresse mémoire (fixe pour toute la durée du programme) et l'identificateur de la variable correspond à cette adresse.
-
la pile d'exécution.
Lorsque l'appel d'un sous-programme est effectué, l'espace mémoire correspondant à ses variables locales (appelées en C/C++ variables automatiques) doit être réservé.
Ceci est fait de façon analogue aux variables globales, mais dans la pile d'exécution, qui s'allonge au dépend de la zone mémoire inutilisée
[1].
Cette zone sera réservée jusqu'à la fin de l'exécution du sous-programme.
Toute la mémoire réservée sera alors rendue et les variables deviendront logiquement inaccessibles.
Pendant toute la durée d'exécution d'un sous-programme, l'adresse mémoire correspondant à une variable sera fixée, et sera représentée par l'identificateur de la variable.
Ces deux cas de stockage d'objets (statiques ou automatiques) présentent pour principal avantage de permettre un accès direct - donc rapide - à l'objet : l'identificateur désigne directement l'objet.
En revanche, ils ont de nombreux inconvénients :
[1]
Il faut envisager le cas particulier des articles mutables (articles à partie variante dont au moins un discriminant a une valeur par défaut).
La norme ADA95 ne précise bien entendu pas comment ces "objets" sont implémentés.
On peut cependant imaginer qu'un compilateur optimisé ne réserve pas en mémoire la taille maximale pour pouvoir y ranger n'importe quelle sorte d'article.
Il est au contraire fortement probable qu'il n'occupe que l'espace strictement nécessaire à un moment donné.
Il doit donc placer ces "objets" dans la mémoire dynamique même s'ils sont déclarés localement, et les réallouer chaque fois qu'une affectation en modifie le discriminant.
Il est donc très vraisemblable que le compilateur place un pointeur de l'article en mémoire automatique (dans la pile), et l'article pointé dans le tas.
Préalablement à la libération de la pile (lors de la sortie du bloc), il doit libérer la mémoire dynamique correspondante.
Dernière mise à jour : 08/07/2001