bout de code à dechifrer svp

Bon voila j'ai recupere un bout de programme mais je ne comprend pas comment il marche

Citation:

---

const char strclord[]="Controlord presente "; /* text */

for (s=strclord; *s; s++) {
printf("%c", *s);
wait(20);
}

---

Voila donc ce que comprend pas c'est ce comment marche la boucle for
alors s=strclord??? j'ai toujours cru qu'il fallait mettre des entiers et la c'est du texte. Ensuite le *s il fait quoi?
merci pour votre aide

Bon alors si je ne trompe pas (et c'est pas evident pasque a 8h45 jsuis pas au max de mon potentiel :oops: )

En fait ce bout de code affiche "Controlord presente " mot apres mot ac un petit delai d attente entre chaque mot.

Code:

---

s=strclord

---

s devient le premier caractère du tableau //Si ce n'est pas sa corrigez moi

Ensuite dans le for on incrémente l adresse pointée par s
puis on affiche la valeur de s.

Apres tout ca c'est pas vraiement clair alors ce que je viens de dire c'est pas du 100% sur

Code:

---

1 2	for (s=strclord; *s; s++) {

---

on initialise le pointeur s en le mettant sur le premier caractère de strclord
tant que *s est différent de 0 c'est à dire différent de '\0' (fin de string)
on avance le pointeur

Code:

---

1 2	printf("%c", *s);

---

on affiche le caractère à l'adresse s

Code:

---

1 2 3 4

wait(20); }

---

on attend 20 sec ?

Citation:

---

Envoyé par bball

Voila donc ce que comprend pas c'est ce comment marche la boucle for
alors s=strclord??? j'ai toujours cru qu'il fallait mettre des entiers et la c'est du texte.

---

Non ca peut être n'importe quelle instruction qui ne sera exécutée qu'à la première itération. ici on initialise le pointeur s a l'adresse de début de la chaîne

Citation:

---

Envoyé par bball

Ensuite le *s il fait quoi?
merci pour votre aide

---

C'est la condition d'arrêt. On boucle tant que *s est vrai. autrement dit tant que le caractère pointé par s est diférent de 0. le caractère de fin de chaîne.
Je te l'accorde. L'instruction for(;;) en C permet de produire du code très compact mais pas forcément très lisible.

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

Citation:

---

Envoyé par Popof

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...

---

Pas forcément. ça évite de déclarer

Code:

---

int i;

---

Et ça a exactement le même effet que s'il y avait un i de déclaré.

Il faut juste s'habituer à ce genre d'écriture.

Ben non... Il a forcement declaré

Code:

---

char *s;

---

C'est marrant d'ecrire de cette facon, mais c'est tout....

Bin je trouve pas d'avantage flagrant a declarer un

Code:

---

char *s;

---

a la place d'un

Code:

---

int i;

---

. Mais bon ce n'est qu'un avis personnel je serais plutot comme Pouic, c'est marrant, interressant a connaitre mais sa s arrete la...

Citation:

---

Envoyé par Popof

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...

---

Dans le cas présent oui mais si tu ne connais pas la taille de la chaîne tu gagnes un appel à strlen().
Pour du parcours de chaîne je fais toujours comme ça quoiqu'avec une intruction while().

Citation:

---

Envoyé par ourk

Dans le cas présent oui mais si tu ne connais pas la taille de la chaîne tu gagnes un appel à strlen().
Pour du parcours de chaîne je fais toujours comme ça quoiqu'avec une intruction while().

---

C'est vrai que vu sous cet angle sa peut etre interressant d'utiliser cette méthode pour parser une chaine inconnue. Mais est ce que l'on gagne vraiement a ne pas utiliser le strlen ???

Citation:

---

Envoyé par ourk

Citation:

---

Envoyé par Popof

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...

---

Dans le cas présent oui mais si tu ne connais pas la taille de la chaîne tu gagnes un appel à strlen().
Pour du parcours de chaîne je fais toujours comme ça quoiqu'avec une intruction while().

---

Tu n'as pas forcément besoin d'appeler strlen, tu peux tout aussi bien faire comme condition d'arrêt:

Code:

---

monstring[i] != '\0'

---

et tu n'appelles pas strlen.

Je trouve que cette façon de codée peut être une légère optimisation...

Reste à savoir si dans le code qui suit il réutilise son s* ou s'il a besoin d'un entier par la suite.

par ailleurs un char prend moins de place en mémoire qu'un int

Pour ce qui est du char *, je ne jurerai de rien.

Difficile de répondre ça dépend de pas mal de choses. Du type de programme d'abord, de la longueur des chaînes et du code généré par le compilateur.

Tu gagnes le temps de parcours de la chaîne (rien n'empêche qu'elle puisse faire 10 000 caractères !).

La solution avec un pointeur (char* ici) est sûrement la solution la plus optimisée par rapport à un indice de tableau.

En effet, lorsque que l'on manipule un pointeur, on manipule directement l'adresse de la donnée, alors qu'avec les indices de tableau, il y a un niveau d'indirection supplémentaire: d'abord il faut l'indice, puis l'adresse correspondant à l'indice.

Si vous comprenez rien à ce que je dis, des notions d'assembleurs vous aideront à mieux comprendre.

Pour ce qui est de l'optimisation ou de la lisibilité, il appartient au programmeur de faire son choix.

En gros utiliser les pointeurs c'est utiliser un niveau d'interprétation de moins (si j'ai bien compris).

Cas d'utilisation de strlen:
strlen agit sur des indices de tableaux qui eux meme agissent sur les pointeurs.

Cas de l'exemple:
on agit directement sur les pointeurs sans passer par les indices.

Mais la question que je me pose toujours c'est s'il y a un réel gain (temps, utilisation processeur...)

La, franchement, on pinaille ;)
Avec un parcours utilisant un char *, on gagne une addition (necessaire dans le cas d'un tab[i] qui equivaut à &tab[0] + i ).
Le gain n'etant pas enorme.... Alors dans une application ou chaque cycle est utile (embarqué temps reel par exemple) , oui, mais sur des machines courantes, le gain est ridicule .... :)

Citation:

---

Envoyé par Pouic

La, franchement, on pinaille ;)
Avec un parcours utilisant un char *, on gagne une addition (necessaire dans le cas d'un tab[i] qui equivaut à &tab[0] + i ).
Le gain n'etant pas enorme.... Alors dans une application ou chaque cycle est utile (embarqué par exemple) , oui, mais sur des machines courantes, le gain est ridicule .... :)

---

Si tu fais 50 gains ridicules sur un programme qui fait 10000 boucles, je pense que ça devient moins ridicule.

Les 2 façons de faire fonctionnent, l'une d'entre elles va plus vite mais est moins lisible par le développeur non averti...(C'est quand même pas la mer à boire non plus, à comprendre)

Je ne vois pas pourquoi se priver d'un gain de temps .

De plus on ne gagne pas qu'une simple addition : on économise aussi en espace mémoire utilisé pour le programme puisqu'on ne déclare pas d'entier qui prends plus de place en mémoire qu'un char.
ça fait donc plus de place pour les autres programmes sur la machine qui ne pinaillent pas :wink: :twisted:

Citation:

---

Envoyé par ggnore

De plus on ne gagne pas qu'une simple addition : on économise aussi en espace mémoire utilisé pour le programme puisqu'on ne déclare pas d'entier qui prends plus de place en mémoire qu'un char.

---

Attention, on ne declare pas un char, mais un pointeur sur char : c'est different ! Sur toutes les implementations que j'ai rencontrees, la place prise en memoire pour un pointeur est celle d'un entier. Mais honnetement, je pense que cette discussion ne mene nulle-part... :D

Citation:

---

Envoyé par Pouic

Citation:

---

Envoyé par ggnore

De plus on ne gagne pas qu'une simple addition : on économise aussi en espace mémoire utilisé pour le programme puisqu'on ne déclare pas d'entier qui prends plus de place en mémoire qu'un char.

---

Attention, on ne declare pas un char, mais un pointeur sur char : c'est different ! Sur toutes les implementations que j'ai rencontrees, la place prise en memoire pour un pointeur est celle d'un entier. Mais honnetement, je pense que cette discussion ne mene nulle-part... :D

---

Humm j'étais pas trop sûr pour l'histoire du pointeur.
En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

l'adresse d'un double long aura la même taille que celle d'un char, mais au final la donnée double long prendra tout de même plus de place en mémoire, non ?

L'optimisation ne mène pas nulle part, j'en suis sûr.

D'ailleurs en voyant ce thread, je me suis dit que j'utiliserais peut être des unsigned char plutôt que des int, maintenant, pour les petites boucles qui nécessitent un indice.

Hum c'est a tester sa peut toujours peut etre ajouter un point de plus dans une interro :lol: et sa peut devenir une bonne habitude a prendre...
Pourquoi pas...

Citation:

---

Envoyé par Popof

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

---

ou d'utiliser printf() avec "%s"... Sans doute trop simple...

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par Popof

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

---

ou d'utiliser printf() avec "%s"... Sans doute trop simple...

---

en même temps, il y a un wait(20) entre chaque affichage de caractère.
J'ai pas bien compris ce que faisait le wait(20),
ça a l'air d'avoir à voir avec des threads et/ou des signaux.

Citation:

---

Envoyé par ggnore

Je ne vois pas pourquoi se priver d'un gain de temps .

---

On saura si on a gagné du temps le jour où on aura fait des mesures dans des conditions reproductibles... Se méfier des apparences.

Prendre aussi en compte le degré d'optimisation du compilateur qui peut très bien, après avoir compris l'intention du programmeur, choisir la stratégie de codage la plus efficace. Et je ne parle pas des pipelines et autres architectures complexes à prédiction...

Pour ces raisons, ce qu'on a pu écrire sur 'tableau vs pointeur' dans les années 80' à propos du langage C n'est plus si évident de nos jour avec les UC et compilateurs modernes...

Le seul critère objectif reste la mesure.

Citation:

---

Envoyé par Pouic

Sur toutes les implementations que j'ai rencontrees, la place prise en memoire pour un pointeur est celle d'un entier.

---

Tu n'as pas du faire beaucoup de x86 en mode réel!

Citation:

---

Envoyé par ggnore

En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

---

L'adresse est une constante. Elle ne prend pas de place. C'est la valeur qui occupe une place en mémoire. Plus exactement, c'est la variable (l'objet). La valeur est le contenu de cette variable.

Citation:

---

l'adresse d'un double long aura la même taille que celle d'un char,

---

Peut être...

Citation:

---

mais au final la donnée double long prendra tout de même plus de place en mémoire, non ?

---

Oui, mais ça veut pas dire que le traitement d'une telle donnée sera plus lent ou plus rapide...

Citation:

---

L'optimisation ne mène pas nulle part, j'en suis sûr.

---

Fait des mesures objectives avant de te prononcer...

Citation:

---

D'ailleurs en voyant ce thread, je me suis dit que j'utiliserais peut être des unsigned char plutôt que des int, maintenant, pour les petites boucles qui nécessitent un indice.

---

Erreur. Il est recommandé d'utiliser toujours des int ou unsigned int (taille 'naturelle des objets vu du processeur) pour les travaux courants. Un char tout seul utilisé comme petit entier génère souvent plus de code, car il faut l'étendre en int pour le traiter dans les registres internes du processeur...

Idem pour les paramètres, on a jamais vu de paramètre de type [signed ]|[unsigned ]char dans la bibliothèque standard du C. Normal, tout paramètre 'char' est converti en 'int' automatiquement (idem pour 'short'). Cette conversion n'est pas gratuite.

Citation:

---

Envoyé par ggnore

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par Popof

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

---

ou d'utiliser printf() avec "%s"... Sans doute trop simple...

---

en même temps, il y a un wait(20) entre chaque affichage de caractère.
J'ai pas bien compris ce que faisait le wait(20),
ça a l'air d'avoir à voir avec des threads et/ou des signaux.

---

Ok, dans ce cas un putchar() aurait été plus léger...

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par ggnore

En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

---

L'adresse est une constante. Elle ne prend pas de place. C'est la valeur qui occupe une place en mémoire. Plus exactement, c'est la variable (l'objet). La valeur est le contenu de cette variable.

Citation:

---

l'adresse d'un double long aura la même taille que celle d'un char,

---

Peut être...
...
paramètre 'char' est converti en 'int' automatiquement (idem pour 'short'). Cette conversion n'est pas gratuite.

---

:(

A quoi est ce qu'on peut se fier alors pour tenter d'optimiser du code ?

Si ça ne vaut rien d'essayer de mettre de types de variables le plus prêt possible du domaine de valeur d'une variable, je ne comprends plus rien.

Comment optimiser du code alors ?

A part tatonner et tester la vitesse d'éxécution ?
Faut il absolument connaître le fonctionnement interne du résultat compilé par le C ? Faut il comprendre comment ce résultat dialogue avec la machine ? Est ce que ça dépend beaucoup de la machine ?

ok ok merci pour vos reponses elles m'ont été tres utiles encore merci :D

Pour comparer deux codes C, il faut comparer la sortie ASM car les compilateurs optimisent beaucoup

Citation:

---

Envoyé par ggnore

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par ggnore

En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

---

L'adresse est une constante. Elle ne prend pas de place. C'est la valeur qui occupe une place en mémoire. Plus exactement, c'est la variable (l'objet). La valeur est le contenu de cette variable.

Citation:

---

l'adresse d'un double long aura la même taille que celle d'un char,

---

Peut être...
...
paramètre 'char' est converti en 'int' automatiquement (idem pour 'short'). Cette conversion n'est pas gratuite.

---

:(

A quoi est ce qu'on peut se fier alors pour tenter d'optimiser du code ?

Si ça ne vaut rien d'essayer de mettre de types de variables le plus prêt possible du domaine de valeur d'une variable, je ne comprends plus rien.

Comment optimiser du code alors ?

A part tatonner et tester la vitesse d'éxécution ?
Faut il absolument connaître le fonctionnement interne du résultat compilé par le C ? Faut il comprendre comment ce résultat dialogue avec la machine ? Est ce que ça dépend beaucoup de la machine ?

---

Optimiser pourquoi faire ?

L'expérience montre que pour gagner en efficacité, il faut :

• Ecrire le code normalement sans astuces particulière, mais en veillant comme toujours à ce qu'il n'y ai ni bug (facile) ni comportement indéfini (difficile...)
• Passer le code au profiler pour voir quelles sont la ou les fonctions les plus utilisées.
• Faire des mesures sur ces fonctions (facile, suffit d'instrumenter le test unitaire...).
• Voir si on peut améliorer l'algorithme (éviter les redondances, les parcours de listes et de tableaux imbriqués etc.)
• Monter le niveau d'optimisation du compilateur
• En dernier seluement, faire les micro optimisations. En fait, c'est rarement utile.

Citation:

---

Envoyé par Emmanuel Delahaye

Optimiser pourquoi faire ?

L'expérience montre que pour gagner en efficacité, il faut :

• Ecrire le code normalement sans astuces particulière, mais en veillant comme toujours à ce qu'il n'y ai ni bug (facile) ni comportement indéfini (difficile...)
• Passer le code au profiler pour voir quelles sont la ou les fonctions les plus utilisées.
• Faire des mesures sur ces fonctions (facile, suffit d'instrumenter le test unitaire...).
• Voir si on peut améliorer l'algorithme (éviter les redondances, les parcours de listes et de tableaux imbriqués etc.)
• Monter le niveau d'optimisation du compilateur
• En dernier seluement, faire les micro optimisations. En fait, c'est rarement utile.

---

Ok.

Est ce que essayer d'économiser la déclaration de variable peut être un plus ? Est ce que par exemple, déclarer 2 char *, parcequ'on veut avoir deux noms de variable causant crée une réelle différence avec la déclaration d'un seul char * qu'on va utiliser pour 2 travaux différents ?

ça doit sûrement être inquantifiable, non ?

Par ailleurs, que penses tu de ce genre de code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int main(){ int a,b,c;   b=12; a = 1 +b; c=3; { int d; d=48; }   }

---

le code en lui même est sans intérêt, mais est ce que mettre des accolades au milieu d'une plus grosse portion de code pour pouvoir rendre une variable 'volatile' a un intérêt ? (ce que je veux dire, c'est qu'une fois l'accolade fermante autour du

Code:

---

int d;

---

la variable d n'a plus d'existence.)

Citation:

---

Envoyé par ggnore

Est ce que essayer d'économiser la déclaration de variable peut être un plus ? Est ce que par exemple, déclarer 2 char *, parcequ'on veut avoir deux noms de variable causant crée une réelle différence avec la déclaration d'un seul char * qu'on va utiliser pour 2 travaux différents ?

ça doit sûrement être inquantifiable, non ?

---

La seule réponse sensée est "faire des mesures"...

Citation:

---

Par ailleurs, que penses tu de ce genre de code

Code:

---

1 2 3 4 5 6 7 8 9 10 11

int main(){ int a,b,c;   b=12; a = 1 +b; c=3; { int d; d=48; } }

---

le code en lui même est sans intérêt, mais est ce que mettre des accolades au milieu d'une plus grosse portion de code pour pouvoir rendre une variable 'volatile'[1] a un intérêt ? (ce que je veux dire, c'est qu'une fois l'accolade fermante autour du

Code:

---

int d;

---

la variable d n'a plus d'existence.)

---

Je fais ça tout le temps parce que ça résout beaucoup de problèmes de conception.

http://emmanuel-delahaye.developpez....tes.htm#portee

Quand à l'effet sur la mémoire, il est variable. Certain compilateurs savent réutiliser la mémoire automatique libérée, d'autres ne se posent même pas la question et allouent toutes les variables sur la pile sans réflechir (MRI de Mentor Graphics, par exemple)...

--------------------------
[1] Attention, le terme 'volatile' a un sens précis en C (c'est même un mot clé) et il n'a rien à voir avec l'utilisation que tu en fais...

Je pense qu'au niveau de l'optimisation, il est bon d'avoir certains réflexes. Je ne dis pas de programmer des portions de code en assembleur, mais de réfléchir à ses algorithmes dans les portions critiques du programme.

Je suis d'accord avec Emmanuel, faire des mesures peut parfois nous apprendre beaucoup de choses.

Juste un exemple: souvent dans mes premiers programmes, j'écrivais mes propres fonctions de concaténation ou de copie de chaîne de caractères.
Et puis un jour j'ai fait des mesures. Et bien quelle surprise lorsque je me suis aperçu que les fonctions strcat, strcpy, etc... étaient bien plus optimisées que ce que je ne pouvais faire.

Donc oui faire des tests, une fois que l'on a pris quelques habitudes, il devient moins nécessaire de s'inquiéter de l'optimisation.

Je pense que le programmeur qui s'inquiète de savoir si le code qu'il écrit est du bon code, est un bon état d'esprit. Je dirais que se poser des questions sur l'optimisation est presque un réflexe pour les programmeurs débutants. Quand on débute on veut savoir si notre code est efficace et optimisé.

Les programmeurs avancées se posent moins ce genre de question(sauf cas particulier, ex: jeux vidéos), parce qu'ils ont pris certaines habitudes et que leur code a pû être maintes fois éprouvé.