🚀 go-pugleaf

Jean-Marc Bourguet wrote:

> "Charlie Gordon" <news@chqrlie.org> writes:
> 
>> Exact, ce qui permet par exemple d'evaluer en parall�le sur les
>> architectures qui le permettent les expressions des param�tres de f.
> 
> Ce n'est permis evidemment que quand ces parametres sont des
> expressions sans appels de fonction, sinon il y a quelques points de
> sequencement en plus (mais leur ordre relatif n'est pas fixe).  Pour
> reprendre mon exemple:
> 
> int incr(int* i) {
>    return (*i)++;
> }
> i = 0;
> k = f(incr(i), incr(i));
> ici on est sur que l'appel a f se fait avec a=0 et b=1 ou a=1 et b=0.
> (Ou alors il y a autre chose qui m'echappe).

Techniquement, ce n'est pas vrai, car tu as un beau comportement
ind�fini ;-)

Pour que ton code compile, il faut que int soit declar� comme int * et donc
tu passes NULL � incr dans la derniere ligne.

Le passage par r�f�rence doit �tre explicite en C, ce qui est une
b�n�diction et �vite d'avoir � se poser des questions m�taphysiques �
chaque appel de fonction : peut-elle avoir un effet de bord sur les
param�tre ???

> Plus subtil, est-ce que
> 
> k = f(incr(i), i++);
> 
> a les memes garanties?  (Pas le temps de faire un exegese pour essayer
> d'apporter une reponse). 

Tu voulais dir k = f(incr(&i), i++);
parce que ton code est correct avec int *i; mais est un autre exemple de
comportement ind�fini.

> Naturellement, je laisse
> 
> int j = 0;
> incr(int*i) { j++; return (*i)++;}
> k = f(incr(i), i++ + j++);

La encore avec la d�finition int *i; manquante cela compile, mais quel
d�lire !

> a ceux qui veulent reellement s'amuser.

Sans aucun doute ;-)

> Une chose qui m'echappe c'est un exemple realiste ou ca apporte un
> gain et ou la regle du "as-if" ne permet pas le meme gain.  Il faut
> avouer que j'ai le meme probleme pour l'ordre d'evaluation des
> parametres (si j'admets que ca simplifie un peu le compilateur, je ne
> percois pas de gain en performance).

Comme d'habitude, au moment de la normalisation, diff�rents compilateurs
impl�mentaient d�j� des comportements diff�rents et incoh�rents sur de
telles expressions, donc le comit� a d�cid� d'ent�riner l'existant qui a
l'avantage de laisser une certaine libert� au compilateur.  C# a pris un
chemin diff�rent, Microsoft semble avoir sp�cifi� le comportement
syst�matique de son compilateur pour ce genre de construction, ce qui est
sans doute une bonne chose pour les programmeurs, mais va en produire un
g�n�ration qui seront incapables de s'adapter au C ou au C++
ult�rieurement.  Je ne sais pas ce qu'il en est de java.

-- 
Chqrlie.