Discussion :

[Loceka]

Bonjour, j'ai eu un "problème" avec un programme récemment créé. Mon code ressemblait à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var b : boolean;
begin
while (not b) do begin ... b:=true; (or false) ... end;
end.

Je n'avais donc affecté aucune valeur à b avant d'entrer dans la boucle, et c'est dans cette boucle que je lui en affectait une.
Dans une première version du programme (environ 12Ko), tout se passait comme si b valait "FALSE" par défaut. Puis, après plusieurs ajouts au programme en question (ajouts qui ne concernait en rien cette boucle et qui ne changeaient pas la valeur de b ; à ce moment là le fichier était d'environ 30Ko), quand j'exécutais le programme, b valait apparement "TRUE" par défaut.

Le problème, que je ne comprend pas, c'est le pourquoi de la chose ! Parce que l'affectation de "vrai" ou "faux" à b n'était, selon toute probabilité, non aléatoire (à chaque fois que j'exécutais la première version, b valait "false" par défaut, de même, à chaque fois que j'exécutais la seconde, b était affecté de "true").

Alors est-ce que l'affectation des valeurs à une variable dépend de la taille du fichier, ou à quoi est dû ceci ? (je sais qu'il ne faut pas ne pas affecter une valeur à une variable, mais c'était un oublie, c'est corrigé maintenant.)

[Alcatîz]

Bonjour !

En fait, toute variable non initialisée doit être considérée comme ayant une valeur indéterminée. Donc, il faut éviter cette situation.

Pour un booléen, c'est plus traître car la valeur false correspond à un octet nul et la valeur true à un octet non nul (enfin, ça dépend quand même un peu du compilateur). Il y a donc 255 fois plus de chances de démarrer avec un booléen true plutôt que false.

Pour épargner une instruction d'affectation, tu peux définir non pas des variables globales mais bien des constantes typées. L'avantage de celles-ci est qu'elles ont une valeur au démarrage du programme. Elles sont également stockées dans le segment de données du programme, donc il n'y a pas de problème à ce niveau.

[ALT]

Bonjour

En fait, quand le programme démarre, c'est rarement sur une zone de mémoire vierge : il y a eu des données avant, elles ne sont pas effacées.
Donc, quand tu démarres ton programme avec une version courte ou avec une version longue (ajout de lignes de code), la variable n'est sans doute pas dans la même case mémoire. Il n'y a donc pas la même valeur au lancement de la chose.
D'où les différences de comportement.

Moralité, quand on commence un programme, une procédure..., il faut toujours initialiser les variables, afin d'être sûr de la valeur de départ.

C'est une règle absolue, quel que soit le langage, quelles que soient les circonstances (et c'est encore plus vrai quand on utilise des pointeurs...)

Cordialement

[Loceka]

En fait, quand le programme démarre, c'est rarement sur une zone de mémoire vierge : il y a eu des données avant, elles ne sont pas effacées.
Donc, quand tu démarres ton programme avec une version courte ou avec une version longue (ajout de lignes de code), la variable n'est sans doute pas dans la même case mémoire. Il n'y a donc pas la même valeur au lancement de la chose.
D'où les différences de comportement.

Merci bien, je crois que ça doit être la cause de mon "problème". J'avoue que j'ai du mal à bien comprendre la gestion de la mémoire...

il faut toujours initialiser les variables

Je le fais systématiquement, mais celle-ci était passée à la trappe.