Bonsoir,
désolé mais je ne savais pas ou mettre ce topic.
Il y a une ligne de commande que je n'arrive pas a saisir :
 
 
#include <stdio.h>
main()
{
 /* Déclarations */
 char TXT[201]; /* chaîne donnée       */
 int I,J;  /* indices courants         */
 int L;    /* longueur de la chaîne    */
 int C;    /* compteur des lettres 'e' */
 int AIDE; /* pour l'échange des caractères */
 
 /* Saisie des données */
 printf("Entrez une ligne de texte (max.200 caractères) :\n" );
 gets(TXT); /* L'utilisation de scanf est impossible pour */
 /* lire une phrase contenant un nombre variable de mots. */
 
 /* a) Compter les caractères */
 /* La marque de fin de chaîne '\0' est */
 /* utilisée comme condition d'arrêt. */
 for (L=0; TXT[L]; L++)
     ;
 printf("Le texte est composé de %d caractères.\n",L);
 
    getch();
    return 0;
}  
 
 
La boucle for se traduit comment svp?
Moi je lis, "pour l'entier L allant de 0 au caractere contenu en TXT[L] par pas de 1"
Et ce je ne comprends pas comment on peut partir d'un entier et arriver a un type caractere.
J'ai surement mal traduit cette ligne.
 
 
Cela se lit peut être pour le charactere contenu en TXT[0] au charactere contenue en TXT[L] non?

Surement que L est la longueur de la chaine que tu vas recuperer sur ta ligne de commande, non ?

Tant que TXT[L] est vrai.

Ou sinon, c'est peut etre :
 
avec  
 
for ( <init.> ; <cond. répétition> ; <compteur> )
 
Pour L=0 on incrémente, tant que TXT[L] ... je ne sais pas cette condition de répitition!

Bref tant que TXT[0] != '\0' ...

 
 
Ok merci !
Mais comment peut il etre vrai ou faux? C'est pas encore concret...
TXT[L] est bien un caractere ?

Ah ok merci tu répond plus vite que ma question!

 
ce n'est pas plutot tant que TXT[L] != '\0'   ?
Car TXT[0] = caractere contenue en 0, dans la premiere case (premiere lettre de la chaine) donc il est fixe.
 
 
Pourquoi on ecrit pas plutot :
 
 
for (L=0; TXT[L] != '\0'; L++)
 
 
?

Oui, mais quand il vaut 0 (ou '\0, c'est pareil) il est 'faux' (En C : 0=faux et <>0=vrai). Il vaut 0 quand on tombe sur le marqueur de fin de chaine.
 
 

On pourrait. Mais les codeurs C aiment bien le code compact... Parfois ça devient illisible...

Parce que c'est pareil, et ça fait 8 caractères en moins

Humm OK, bien reçu.
Donc TXT[L] dans cette ligne de commande peut etre traduite par "tant que TXT[L] est vrai, soit tant qu'il n'est pas égal à 0, marqueur de fin de chaine" .

 
Exact
En fin de boucle, L contient le nb de caractères significatifs de "TXT" (sans compter l'octet valant '\0')

Il connaissait pas strlen() le gars ?

nettement moins performant

Te plains pas, il aurait même pu écrire  
 
for (L=0; TXT[L++]; )
 
 
voire, s'il est vraiment tordu
 
L = 0;
for (;L[TXT++]; )
 

(tiens, un ancien jocebug qui est revenu, le ; final a disparu si je ne mets pas d'espace avant la parenthèse)
 
JagStang > en quoi strlen est moins performant ? Je dirais plutôt le contraire.

Bof, je dirais que c'est pareil mais tant qu'on a pas fait les mesures...
 

 
Oui. Ca dépend des libs, je crois que certaines mettent une pincée d'asm derrière. Par contre, il est vrai que faire un strlen pour faire un strncpy derrière n'est pas forcément une bonne idée vu qu'on parcourt deux fois la même chaine.

 
ben tu parcours une fois la chaine pour trouver la len, puis une autre fois pour modifier.

JagStang, stp explique ce qui te fais dire que strlen est "nettement moins performant".

je t'explique comme je vois la chose.  
 
strlen parcours la chaine pour trouver sa taille (n itérations)
ensuite, tu parcours de 0 à strlen()-1 (à nouveau n itérations)
 
==> 2n
 
tandis que si tu te contente de faire ce test, tu ne fais que n itérations.
 
tout ceci valable sous réserver que la taille de la chaine ne peut être connue par le compilateur ou l'executable sans parcourir celle-ci à la recherche de '\0'
 

 
Le top du top:

 
G gagné...  

Faut gaffer avec les compilos de merde qui te retestent strlen à chaque bouclage

Ah oui, là effectivement... le pire, c'est qu'on tombe de temps en temps sur ce genre de code.
 

A mon avis, la majorité des compilos vont te recalculer strlen  à chaque tour. Le compilo ne peut pas prévoir toutes les conneries que tu écris.

Surtout que la longueur de la chaine pourrait changer dans la boucle.

En fait, le problème est là. Si la longueur change, on est obligé de laiser le strlen() dans le test, à moins de gérer la longueur à la main avec une variable...
 
Par contre, si la taille est fixe, il est préférable d'appeler le strlen() avant et de mettre la variable (invariante) dans la boucle:

Genre le compilo .NET te sort le test de la boucle en passant par une variable temporaire

Bonjour
Je ne parviens pas à saisir l'intéret de parcourir deux fois la chaine pour calculer sa longueur.
Je pense que le temps d'exécution doit être le même avec un léger avantage sur la boucle si le compilateur est bon car il y a l'économie d'un appel de fonction et de gestion du cadre de pile.
Quand on en est à ce genre d'optimisation qui ne favorise pas la lisibilité du code, il est temps de passer à l'assembleur.
Cordialement

 
justement, y'en a pas.
le fait de ne pas coder en ASM ne justifie pas un minimum d'optimisation
 
Amicalement

pour JagStang
Qu'est-ce qui te fait penser que strlen parcourt 2 fois la chaine ?
Il la parcourt une fois pour chercher le 0 ce qui lui permet de conaitre la longueur soit par itération d'un compteur pendant le parcourt soit par différence de pointeur entre l'arrivé et le départ.
A quoi peut bien servir le deuxième passage ?

strlen une fois, la boucle une seconde fois.  
 
la je parle de la version  
taille = strlen(chaine)     // n fois
for i=0 to taille           // n fois

donc, pas justifié de passer 2 fois bien entendu. j'espère qu'on s'est compris

Cette fois tout est clair.
Merci

C'est clair, mais c'est pas ce qui est fait ici... Il parcourt une fois la chaine a la main, pour trouver la longueur. En utilisant strlen c'est strlen qui aurait parcouru une fois la chaine, pour trouver la longueur. Comme il ne profite pas de son parcours pour faire autre chose avec sa chaine, strlen etait la meilleure solution, point. Evidemment si on a autre a faire en parcourant la chaine, il vaut evidemment mieux le faire a la main et s'arreter sur le '\0' final... Ce n'est pas le cas ici.