[Kos-dev] (no subject)

[Christophe Avoinne (Club-Internet)]

> C'est un problème interressant, je ne pense pas que la norme definisse
> le comportement exact dans ce cas la. J'ai pas re-regardé ans la norme
> en détail mais il me semble que ... J'ai ... l'explication ...
>
>
> En théorie l'équivalent correct est en fait (si je me rappelle bien)
>
> right->left = ( right = root )
>
> Ceci doit etre du a l'associativité a droite de l'opérateur =
>
> Or l'évaluation d'une affectation (a = b) donne b.
>
> Donc en fait c'est bien equivalent à
>

cas 1)

> right -> left = root
> right = root
>
> OU (hehehe, voici à mon avis le point de détail)
>

cas 2)

> right = root
> right -> left = root
>

Oui, ce ne peut être que ça ! j'aime mieux ça car ça explique tout en fait,
Fabrice :).

En effet, si on a :

file_entry_type
  file_entry[FILE_ENTRIES_MAX];
root = file_entry+0;
right = file_entry+1;

Dans le cas 1), on aurait :

d'abord, "right->left = root;" i.e, "(file_entry+1)->left = file_entry+0;"
puis "right = root;" i.e, "right = file_entry+0;"

tandis que dans le cas 2), on aurait :

d'abord, "right = root;" i.e, "right = file_entry+0;" puis "right->left =
root;" i.e, "(file_entry+0)->left = file_entry+0;"

Ce qui évidemment ne donne pas du tout le même résultat.

Merci Fabrice, je comprenais vraiment pas pourquoi ça merdait, mais là oui
:-).

Conclusion, si on fait : a->left = b = c; ça marche pile poil, mais si on
fait : a->left = a = c; ça ne passe pas à cause de la dépendance entre
a->left et a, incertitude liée à la non détermination de l'ordre
d'évaluation exacte.

Hlide.