Parser & post-incrémentation / post-décrémentation : comment ? - Page 2

Thibault la demo que tu donnes est en effet tres simple a comprendre, mais heu.. qui est la jeune fille dans le meme répertoire ;-) ?

La solution c de PAS utiliser des trucs du genre [i]a=i++;
Enfin, à la limite si tu ne te poses pas la question de la portabilité,
c pas grave, tu vois avec TON compilateur ce que ça donne.

Il y a d'autres pbs avec des codes du genre :

printf("%d %d", ++n, power(n, 2)); /* #bbbbouuuuu# */

power(n, 2) peut très bien être évalué AVANT ++n, ce qui évidemment change le resultat..
il est préférable d'écrire :

++n;
printf("%d %d", n , power(n, 2)); /* #hhhaaaaaaaa# */

là on est sûr que ça donnera la meme chose ac tous les compilateurs

[edit]Edité par Pen^2 le 11-11-2001 à 15:05:32[/edit]

Je ne suis pas d'accord, une ligne comme "a[i]=i++; " est vraiment dépourvue d'ambiguïté.

"a[i]=i++; " : cette ligne place dans a[i] la valeur de i, et ensuite incrémente i.

au vu des differents exemples "ambigus" donnés, je crois que la solution de Kevin consistant a traiter les pre-incrementations avant l'instructions, puis les post-incrementations regle tous les problemes, aussi bien de semantique que de simplicité d'implémentation coté compilateur.
Il suffit de bien déterminer dans une doc l'ordre des incrementations.

De toute facon qqe soit le compilo il est evident qu'on evite toujours les lignes du genre "i++ + i++" qui sont quasi-imprevisibles...
Les questions qui se posent ici se posent pour tout compilateur. Chaque auteur choisit une solution qui lui est propre...

Lever les ambiguités, c'est s'astreindre a ne pas utiliser des instructions de ce type !!
Ce travail doit etre fait par le codeur, pas par le compilateur.

Blue_Z
>[i] Je ne suis pas d'accord, une ligne comme "a=i++; " est vraiment dépourvue d'ambiguïté.
pourtant c'est une mise en garde toute droit sortie du bouquin de Kernighan et Ritchie
[i]>"a[i]=i++; " : cette ligne place dans a la valeur de i, et ensuite incrémente i.
Je pense pour ma part que rien n' empeche le compilateur de copier la valeur de i qq part, de l'incrementer, et de copier la valeur ds le tableau à l'indice correspondant à la nouvelle valuer de i.

naholyr
ou par LINT
[edit]Edité par Pen^2 le 15-11-2001 à 18:36:22[/edit]

Ce qu'a dit Pen² me plaît bien. Je vais implémenter ces opérateurs à ma façon (inspirée du PpHdStyle)

Kevin : malheureusement un des objectifs de l'Azur est d'être TRES rapide à compiler. Je ne peux pas me permettre ces 3 passes.

Il faut savoir que mon compilo compile + de 30 % plus vite que GTC, et je tiens à garder mon avance.

arf...
Les lois de la concurrence....

He oui.

héhé

c ce qui fait progresser...
Que serait Windows sans Linux ?
Ou sans MacOS...

=> toujours MS-DOS ?

au - ça serait stable

oué, c vrai que le ODS, ça buggait pas souvent...
Et puis, au moins, mon père ferait pas n'importe quo iac le PC...

Tout à fait squale92, c'est pour ça que, comme je te le disais tout à l'heure, le compilo produira un jour du code optimisé, mais c'est pas dans mes priorités.

oué.

gavé

ca a peut-être aucun rapport, mais comment faire un truc comme
if (*a++ == 1 && *a==2) {
...

pour que le a++ se fasse ressentir dans la 2ème partie du test?
[edit]Edité par ExtendeD le 18-11-2001 à 19:13:34[/edit]

houla...

Mets 2 ifs:
if(*(a++)==1) if(*a==2) ...

Qui parle encore de C K&R ? On est au C discipliné maintenant, la 3ème génération, donc K&R, plus là...

K&R restent qd même les fondateurs de ce langage, et leur bouquin reste une référence connue...
Quiconque sait programmer en C doit au moins savoir ce que signifient les lettres K&R !!!

(le seconde édition de leur bouquin "The C programming language" traite de l'ANSI-C, qui est loin d'être dépassé... Même si TIGCC utilises du GNU-C, toutes les fonctionnalités ANSI sont présentes (du moins tout ce que j'ai eu besoin d'utiliser !)

Le C K&R n'est pas entièrement dépassé: GCC est écrit en C K&R, A68k aussi.

oué...
Et le C K&R est qd même la base du C !!!

Et le C discipliné, vous ne connaissez pas ?

Ca m'intéresse, parle un peu de ce que tu appelles le C discipliné

--------------------------------------------------------------------------------
ca a peut-être aucun rapport, mais comment faire un truc comme
if (*a++ == 1 && *a==2) {
...

pour que le a++ se fasse ressentir dans la 2ème partie du test?
--------------------------------------------------------------------------------

Mets 2 ifs:
if(*(a++)==1) if(*a==2) ...
--------------------------------------------------------------------------------


ac 2 if imbriqué, mefie toi si tu mets un else apres, parce que dans

if (***)
   if (***)
   ;
else
   ;

le else est pour le 2eme if. (ça saute pas aux yeux ac l'indentation)

utilise :

if (***) {
   if (***)
   ;
   }
else
   ;

[edit]Edité par Pen^2 le 21-11-2001 à 19:20:31[/edit]

Je me suis fait avoir y'a pas longtemps avec ça

Le C discipliné empêche certaines choses avec un utilitaire appelé dcc qui vérifie le code source. Le seul truc, c'est qu'il y a des pargmas partout et qu'ils sont indispensables. Mais je ne me rappelle plus de la suite. Il faut que je cherche le bouquin chez mon frangin. En tout cas, ça élimine certaines erreurs de compilation. y'a des conventions d'appel de fonction et de transfert d'informations chiantes mais utile - personnellement -

Je préfère le C indiscipliné, alors.

arf...
même chose que Kevin

pour verifier les sources, il y a deja LINT