citez moi une seul règle qui me dise que je ne suis pas dans mon droit !

Petite bise (lol, ok j'avais mal compris, il aurait pu simplement écrire "Vous vous êtes trompé de partie de forum, je déplace "), lol, c'est oublié ? "De quoi je parlais déjà "!

Merci énromément pour ces indications, mais j'aurais tant voulu que ce soit sur mon forum, pour avoir une petite communauté .

Merci, mêmesi je suis assez bon en anglais pour mon âge (15 ans), je travail en ce moment avec une communauté de 10 membres tous français, bien entendu ceux de 20 ans et plus parle français mais pas le reste, de toutes facons, la doc va etre traduite en anglais plus tard

Oui, c'est vrai en fait, y'a pas besoin de ce bloc. J'ai écrit ça a l'arrache ^^

for( ; ; ), c'est un idiome courant qui produit exactement le même code que while(1), mais qui s'écrit en une lettre de moins, et en plus c'est joli, c'est tout.

Salut,
@BOFH : merci pour les réponses, effectivement ça fait une lettre de moins.
A+.

Plus parlant ? pourquoi ?

Une fois que tu l'as vu une fois, tu sais que for( ;; ) est pareil que while(1), c'est tout...

quand on écrit

for(a; b; c) { code }

le compilateur traduit en

a;
while(b) {
  code;
  c;
}

donc

for(;;)

traduit littéralement en

while() { code }

, avec la seule particularité que le vide dans la condition commande une boucle infinie (alors qu'un while avec rien dans la condition n'est pas valide en C)

Mhh... raisonnement intéressant, mais pas tout a fait correct.

Pour commencer, le compilateur C ne traduit pas directement le code C en code binaire. Prenons le cas de gcc par exempe.

Il y a d'abord une phase de pré-traitement, qui gère les macros #. Ensuite, le compilateur transforme le code C en une représentation interne en forme d'arbre, l'arbre de syntaxe abstrait. C'est au cours de cette transformation que la syntaxe est vérifiée, et qu'a lieu la résolution des symboles.

Lorsque l'arbre est complet, le compilateur effectue ensuite la vérification des types. Lorsque la vérification des types est finie, cet arbre subit une passe d'optimisations, et est traduit dans une deuxième représentation interne plus fine, le langage de transfert de registres.

Une deuxième passe d'optimisations s'occupe du renommage de registres et des problèmes de pipelining. Ensuite, du code en langage d'assemblage est produite à partir de ça, et le compilateur s'arrête.

Entre alors en jeu l'assembleur, qui va transformer le langage d'assemblage en code objet, qui est un morceau de code binaire partiel (que l'on retrouve entre autre dans les librairies). Finalement, tous les fragments de code objet sont assemblés par l'éditeur de liens, qui va produire au final un binaire exécutable.

Tout ca pour dire, que le compilateur ne traduit pas *textuellement* le for( ;; ) en while(1), mais qu'il produit des arbres syntaxiques similaires. Evidemment, dans tout ce travail, les tâches peinibles sont l'optimisation, l'attribution des registres, la résolution des symboles et
la vérification des types; le temps gagné en remplaçant for par while sera de manière générale négligeable par rapport au reste de la compilation.

En fait, on pourrait même argumenter que le for( ;; ) est plus simple a produire pour le compilateur, parce qu'il peut être directement traduit en une boucle infinie, alors que dans le cas du while(1), le compilateur doit examiner le contenu de la condition (le 1) pour réaliser qu'elle est constante et que le test sera toujours vrai. Toujours de manière générale, plus le code source est abstrait, meilleur sera le code généré, parce qu'il est toujours plus facile pour une machine de transformer une représentation abstraite en quelque chose de plus concret, que le contraire.

Hello Jean,

  tu peux jeter un oeil à ce cours de compilation made in switzerland:

http://lamp.epfl.ch/teaching/archive/co … ments.html

C'est vrai qu'il y a cette histoire de pré-compilatio n(avec les macros...), mais comme fais for ( ;; ) pour faire quelque chose comme while (n == 0) ?

A ok, donc le for( ;; ) ne sert qu'a une chose ?