Discussion :

[jjnoui]

Bonjour à tous.
Je pense quitter Windows en avril 2014 (fin du support de XP) etcomme j'ai beaucoup de programmes écrits en Delphi 6 je viens de commencer une approche de Lazarus.
Sympa, on ne perd pas tous ses repères.

Mais ......

Le résultat d'un petit test me fait craindre pour la compatibilité entre les versions Delphi6 et Lazarus (tests effectués sous Windows XP).

J'ai extrait de mon source un petit test :

Code :

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

1
2
3
4
5
6
7
8
9
10
procedure TForm1.Button2Click(Sender: TObject);
var
  i, j : integer;
begin
  j := 0;
  for i := 1 to 4 do begin
    inc(j);    // j n'est là que pour remplir la boucle
  end;
  showmessage('valeur de i : ' + InttoStr(i));
end;

Oh surprise, en tout cas pour moi car les résultats du showmessage ne sont pas les mêmes.

Bien entendu la procédure ci-dessus n'a été écrite que pour mettre en évidence le phénomène, dans la réalité, il s'agit de parser un buffer qui contient des chaînes de caractères de taille fixe '(padés' par des 0 binaires) et des valeur sur 1, 2, ou 4 octets.

Qui pourrait m'expliquer pourquoi cette divergence de comportement?

Merci

[Jipété]

Yop !

(...) Qui pourrait m'expliquer pourquoi cette divergence de comportement ?

Merci

Pas moi, mais par contre j'ai le souvenir (je ne sais plus dans quel langage, peut-être du C...) du warning d'un compilo avec un message genre "la variable de boucle peut être dans un état indéfini à la sortie de la boucle", ce qui veut dire qu'il vaut mieux ne pas l'utiliser...

[Roland Chastain]

Bonjour !

Je ne sais pas exactement de quoi vous parlez dans les lignes suivantes.

Bien entendu la procédure ci-dessus n'a été écrite que pour mettre en évidence le phénomène, dans la réalité, il s'agit de parser un buffer qui contient des chaînes de caractères de taille fixe '(padés' par des 0 binaires) et des valeur sur 1, 2, ou 4 octets.

Cela étant dit, je dirais que dans l'exemple que vous donnez, la valeur de i est indéfinie, et il n'est pas vraiment surprenant qu'elle varie d'un compilateur à l'autre. En d'autres termes, je pense que c'est une erreur d'utiliser la valeur de i en dehors de la boucle for : si ça marche, c'est par bonheur.
Voyez, pour comparaison, le code suivant. Celui-ci, sans aucun doute, donnera toujours le même résultat.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure TForm1.Button1Click(Sender: TObject);
var
  i, j: integer;
begin
  j := 0;
  i := 1;
  while i <= 4 do
  begin
    Inc(j);
    Inc(i);
  end;
  //Dec(i);
  ShowMessage(IntToStr(i));
end;

P.-S. Jipété a été plus rapide que moi.

[droggo]

Pae,

Je confirme : rien dans la définition du langage ne garantit la valeur du compteur à la sortie de la boucle For, c'est même explicitement dit dans les vieux ouvrages.

Si tu veux que la valeur soit garantie, il faut utiliser un autre type de boucle.

[tourlourou]

Dans la mesure où la variable j n'est pas utilisé après la boucle, je ne suis même pas sûr que le compilateur n'élimine pas la boucle toute entière si les optimisations n'ont pas été supprimées. Mais peut-être la lecture de i ensuite l'empêche-t-il de la squizzer ? Il faudrait comparer les codes compilés.
Ensuite, le compilateur peut inverser le sens d'une boucle pour gagner en célérité. Il y a là peut-être motif à différence aussi.

[jjnoui]

Bonjour et merci à tous.

Pour Droggo
Je suis désolé mais je n'ai plus de vieux bouquins sur delphi ou autres (Internet et Google sont passés par là).

Avant de poster j'avais fait une recherche sur 'évaluation de la condition if', mais sans succès.

Si je me posais la question c'est que j'utilise couramment cette méthode, (bon j'ai compris, à tort) et que je ne suis pas sorti de l'auberge pour ma migration vers Linux.

Pour Tourlourou

Je pense aussi qu'en cas d'optimisation de code l'instruction
inc(j);
n'est pas générée, il s'agissait juste d'un mauvais exemple
Pour Roland Chastain :

Mon explication n'était pas très claire.

un tableau dynamique ( Buffer : array of byte ) contient :

un champ Ascii sur 32 caractères,
un 'word',
deux champ Ascii sur 4 caractères

pour récuperer les données je fais un appel, pour chaque champ Ascii à une routine :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
 
Champ1 := GetBufferASCIIZ(32);
Champ2 := // autre routine pour les 'word'
Champ3 := GetBufferASCIIZ(4);
Champ4 := GetBufferASCIIZ(4);
 
function GetBufferASCIIZ(StringLength : integer) : string;
var
  i : integer;
begin
  result := '';
  for i := 0 to StringLength - 1 do begin
    if Buffer[BufferPointer] = 0 then break;
    Result := Result + chr(PDBRecordTable[BufferPointer]);
    inc(BufferPointer);
  end;
//avance du pointeur sur le buffer au champ suivant
  while i < (StringLength) do begin
    inc(i);
    inc(BufferPointer);
  end;
 
// Appelé par :

Bien sûr il y a d'autres méthodes mais c'est celle-là que j'ai utilisée.

Moralité : il ne faut pas jouer avec ce qui n'est pas explicitement défini

Merci aussi à Jipété

[e-ric]

Pae,

Je confirme : rien dans la définition du langage ne garantit la valeur du compteur à la sortie de la boucle For, c'est même explicitement dit dans les vieux ouvrages.

Si tu veux que la valeur soit garantie, il faut utiliser un autre type de boucle.

Le mieux est de considérer le compteur comme une variable locale, et, si nécessaire, le réaffecter en sortie de boucle.
Il ne faut faire aucune hypothèse sur la valeur du compteur en sortie, avec un for transformé de manière immédaite en while, le compteur vaudra la dernière borne de l'itération + 1 mais si le compteur est un type intervalle prenant toutes les valeurs possibles, ça pose problème (dépassement du type avec l'implémentation basique avec un while). Cela laisse penser que le compilateur choisir une implémentation en fonction du contexte.