Utilisation de VariablesEdit

Visibilité et durée de vie des variables VariablesEdit

Peuvent avoir une visibilité ou une portée différentes selon la façon dont elles sont déclarées et utilisées. La portée fait référence à la possibilité d’accéder au contenu d’une variable particulière à un certain point du programme.

Habituellement, la portée d’une variable est déterminée par son bloc englobant. Un bloc peut être inclus explicitement dans certaines langues (paires begin/end, {/}), tandis que dans d’autres, le bloc est implicite.

Presque tous les langages ont une portée globale, et si un programme déclare une variable dans cette portée, elle est appelée variable globale.

Une variable locale, en revanche, est une variable qui n’est visible, ou  » dans la portée », que dans son bloc.

Considérez ce code:

integer globalVariableglobalVariable = 5begin integer localVariable localVariable = 7 globalVariable = 8endlocalVariable = 3 /* <-- this is a syntax error */

la variable globale est déclarée en dehors de tout bloc, elle est donc dans la portée globale (implicite), ce qui en fait une variable globale. la variable locale est déclarée dans le bloc de début/fin, limitant sa portée à ce bloc.

La variable globalVariable commence par 5, se voit attribuer 8 dans le bloc et se termine par 8. La variable localVariable est affectée à 7, puis sort de la portée avant d’être attribuée illégalement à 3. Il n’y a pas de variable localVariable à ce niveau.

La durée de vie d’une variable vous indique quand la variable est active. Dans l’exemple précédent, une variable globale est créée au début du programme et a une durée de vie égale à la longueur du programme. Pour localVariable, il n’est créé que juste après le début de la directive block. Sa durée de vie est terminée lorsque le programme passe la directive end.

Allocation de mémoire dynamiquedit

De nombreux programmes ont des objectifs très spécifiques et nécessitent des zones de mémoire très spécifiques et petites. Si nous écrivions un programme de lecture de fichiers d’images, nous ne savons pas exactement quelle pourrait être la taille des images. Certains pourraient être des centaines de mégaoctets, tandis que d’autres pourraient être des kilooctets ou moins. Allouer des centaines de mégaoctets qui ne sont pas nécessaires rendrait le programme difficile à exécuter sur certains ordinateurs, tandis qu’allouer trop peu de mémoire signifierait qu’il y a des images que nous ne pouvons pas gérer.

Une bonne approche de ce problème consiste à allouer de la mémoire au besoin. C’est ce qu’on appelle l’allocation de mémoire dynamique. Nous demandons simplement tout ce dont nous avons besoin pendant l’exécution du programme (plutôt qu’au moment de la compilation), ni plus ni moins. Dans notre exemple, cela nous permettrait d’éditer des fichiers d’images énormes et minuscules de manière efficace et efficace. Il y a une certaine complexité supplémentaire puisque ce n’est plus le langage qui traite des détails de l’allocation, mais nous directement. Dans notre exemple, si nous fonctionnons sur un ordinateur bas de gamme, il peut ne pas y avoir assez de mémoire pour accueillir de gros fichiers image, nous devons donc détecter (et éventuellement échouer gracieusement) dans de telles situations.

L’allocation dynamique de mémoire est une source principale de « fuites de mémoire », où les programmes allouent, utilisent et sont ensuite effectués avec une zone de mémoire, mais ne parviennent pas à la marquer comme étant à nouveau disponible. Ces problèmes peuvent être difficiles à détecter car contrairement à d’autres bogues, les fuites ne sont pas facilement apparentes.

Certains langages modernes ont des mécanismes intégrés pour essayer d’empêcher les fuites de mémoire, connus sous le nom de garbage collection. Ce système garde une trace de l’allocation utilisée où, quand elle est hors de portée. La collecte des ordures a une légère pénalité de performance, mais elle est maintenant généralement considérée comme un progrès. Java et Python, par exemple, ont un ramasse-miettes.