Discussion :

[Invité]

Bonjour

Je suis entrain d'apprendre avec le livre le langage C Norme ANSI de Kernighan et richie

jai tapé le code de la page 22 et quand je lance le programme il affiche rien j'ai aucun message d'erreur

est ce quelq'un possede ce livre et a eu le probleme .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <stdio.h>
#include <stdlib.h>
// compte les chiffres, les caracteres d'espacement et les autres caracteres en entree
int main()
{
 
 
    int c,i,nespace,nautre;
 
    int nchiffre[10];
 
    nespace=nautre=0;
 
    for(i=0; i<10; ++i)
        nchiffre[i]=0;
 
    while((c=getchar()) !=EOF)
        if(c >='0'&&c <='9')
            ++nchiffre[c-'0'];
        else if(c == ' ' || c == '\n' || c == '\t')
            ++nespace;
        else
            ++nautre;
 
    printf("Chiffres=");
    for(i =0; i< 10; ++i)
        printf("%d",nchiffre[i]);
    printf(", espacement = %d, autres = %d\n",nespace,nautre);
 
 
 
    return 0;
}

[deletme]

Salut,

Premièrement, très bon livre que je suis en train de lire pour garder la forme !

Quand tu dis qu'il n'affiche rien, la console se lance-t-elle ?
C'est probablement car ton programme arrive sur la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while((c=getchar()) !=EOF)

où getchar est bloquant. C'est à dire que tant que tu n'appuies pas sur une touche, rien ne se passe.

Pour sortir de la boucle, il faut ensuite que tu envoies les caractère EOF : CTRL+Z sur Windows et CTRL+D sur un système Unix

Petit conseil :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
while((c=getchar()) !=EOF)
        if(c >='0'&&c <='9')
            ++nchiffre[c-'0'];
        else if(c == ' ' || c == '\n' || c == '\t')
            ++nespace;
        else
            ++nautre;

Ce code est correct et fonctionne mais il vaut mieux insérer un bloc d'instruction dans le while {} car le jour où tu décides d'ajouter une autre instruction que le if dans ta boucle, tu risques simplement d'oublier les {}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
while((c=getchar()) !=EOF)
{
    if(c >='0'&&c <='9')
        ++nchiffre[c-'0'];
    else if(c == ' ' || c == '\n' || c == '\t')
        ++nespace;
    else
        ++nautre;
}

[Metalman]

Juste pour intervenir en vitesse :

Petit conseil :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
while((c=getchar()) !=EOF)
        if(c >='0'&&c <='9')
            ++nchiffre[c-'0'];
        else if(c == ' ' || c == '\n' || c == '\t')
            ++nespace;
        else
            ++nautre;

Ce code est correct et fonctionne mais il vaut mieux insérer un bloc d'instruction dans le while {} car le jour où tu décides d'ajouter une autre instruction que le if dans ta boucle, tu risques simplement d'oublier les {}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
while((c=getchar()) !=EOF)
{
    if(c >='0'&&c <='9')
        ++nchiffre[c-'0'];
    else if(c == ' ' || c == '\n' || c == '\t')
        ++nespace;
    else
        ++nautre;
}

C'est justement tout "l'art" du C K&R !
Mettre le strict minimum tout en faisant "bien" ce qu'il faut !

[deletme]

Oui c'est ce que je découvre en le lisant et c'est parfois déroutant quand on n'a pas l'habitude de lire du code de ce style. Mais il faut bien avouer, comme tu le précises, que c'est tout un art

[Bktero]

Le style K&R ne correspond plus vraiment à la façon d'écrire du code aujourd'hui. Quand je l'ai eu, je me suis mis à écrire des trucs un peu sioux, genre des boucles for() sans corps pour imprimer le contenu d'un tableau...

Le premier problème je trouve du style K&R est qu'il suppose une très bonne connaissance du langage, typiquement la nécessite ou pas d'accolades dans le code qui nous occupe ici. Le second est que c'est nul d'un point de vue évolutivité car trop sujet à erreur si quelqu'un rajoute à l'arrache une instruction, ne serait-ce qu'un printf() pour faire une trace. Alors certes, cette personne aurait tord, mais pourquoi ne pas directement écrire des accolades pour éviter les soucis futurs ?

Mais bon, on va encore dire que c'est inutile des accolades qui ne servent pas et on va rentrer dans les guéguerres de styles

[Metalman]

Le bouquin est en papier.
Donc il ne changera pas avec le temps !
Donc aucun besoin d'évolutivité sur ce code !!!

(t'as vu comment que je gagne la guéguerre ? )

....ah parce que le code peut être recopié ? mince je n'y avais pas pensé....

[droggo]

Joe,

Quoi qu'il en soit, le K&R n'est absolument pas un bouquin pour apprendre le C.

Il servait plutôt de référence.

Et on y trouve l'explication de cet art : ils écrivaient un minimum de caractères, pour cause temps d'impression avec leur matériel de l'époque (de bonnes vieilles TTY, si je me souviens bien, quelques caractères/s).
C'est la même raison qui les a poussés à introduire les raccourcis genre i++, += ...

Donc, l'art n'est en fait qu'une contrainte matérielle, et puisqu'ils ont pris la peine d'en parler, c'est qu'ils auraient préféré écrire un code plus "propre".

[Obsidian]

Hello,

C'est la même raison qui les a poussés à introduire les raccourcis genre i++, += ...

Je ne suis pas tout-à-fait d'accord sur ce point précis : d'abord, ces expressions restent très utiles même aujourd'hui et elles me manquent lorsque j'utilise des langages qui ne les proposent pas.

Ensuite, il faut se souvenir que le C reste volontairement très proche de la machine, de manière à produire un exécutable le plus autonome possible et s'appuyant le moins possible sur des infrastructures sous-jacentes (« un cran au dessus de l'assembleur »).

Dans le premier cas (« i++ »), l'incrémentation a une sémantique un poil différente d'une addition ordinaire et au niveau électronique, elle prend tout son sens : elle peut être effectuée de manière implicite sur un registre donné en exploitant la retenue entrante alors qu'une addition implique la mise en jeu d'un opérande supplémentaire. En outre, « i++ » est une post-incrémentation. C'est très utilisé lors des itérations sur les listes du style « a[i++]=xxxx » ou encore « *a++=xxxx ». Ça devient important en C++ où les itérateurs sont des objets à part entière.

Dans le même esprit, « =+ » permet d'exprimer en soi l'auto-affectation. Quand on écrit « a = a + 1 », ça ne change pas grand chose, mais quand la lvalue est une expression très longue, c'est utile de ne pas avoir à la recopier systématiquement de part et d'autre du signe et surtout de ne pas avoir à les maintenir toutes les deux chaque fois qu'on leur apporte une modification. Ça permet également de ne pas avoir à se demander si ces deux expressions sont bel et bien identiques ou légèrement différentes. Enfin, dernier détail mais non des moindres, c'est important lorsque la lvalue est tirée d'une expression ayant des effets de bords. L'évaluer plusieurs fois peut avoir des conséquences inattendues.

[Invité]

Joe,

Quoi qu'il en soit, le K&R n'est absolument pas un bouquin pour apprendre le C.

Il servait plutôt de référence.

Et on y trouve l'explication de cet art : ils écrivaient un minimum de caractères, pour cause temps d'impression avec leur matériel de l'époque (de bonnes vieilles TTY, si je me souviens bien, quelques caractères/s).
C'est la même raison qui les a poussés à introduire les raccourcis genre i++, += ...

Donc, l'art n'est en fait qu'une contrainte matérielle, et puisqu'ils ont pris la peine d'en parler, c'est qu'ils auraient préféré écrire un code plus "propre".

tu conseil lequel pour apprendre le C ?

[droggo]

Hoi,

Je ne suis pas tout-à-fait d'accord sur ce point précis : d'abord, ces expressions restent très utiles même aujourd'hui et elles me manquent lorsque j'utilise des langages qui ne les proposent pas.

Je n'ai pas dit qu'elles étaient inutiles, mais que K&R les ont introduites pour diminuer la taille des listings, ce qui est totalement différent.

[Obsidian]

Hoi,

Je n'ai pas dit qu'elles étaient inutiles, mais que K&R les ont introduites pour diminuer la taille des listings, ce qui est totalement différent.

Admettons. :-)
Mais dans ce cas, si c'était à refaire, tu aurais choisi quelle graphie ?

[Metalman]

Dans le premier cas (« i++ »), l'incrémentation a une sémantique un poil différente d'une addition ordinaire et au niveau électronique, elle prend tout son sens : elle peut être effectuée de manière implicite sur un registre donné en exploitant la retenue entrante alors qu'une addition implique la mise en jeu d'un opérande supplémentaire.

Je plussoie !
On peut voir sur certains CPU CISC que des instructions agissent directement sur plusieurs registres en incrémentant les valeurs de certains d'entre eux.
Je crois me souvenir que sur les modes d'adressages du 68000, il existe des modes permettant de travailler directement avec le déréférencement d'une adresse, puis d'automatiquement passer à l'adresse suivante.

Un registre A1 contient une @, D2 contient une valeur, et une instruction va ajouter le contenu présent à l'@ de A1 dans D2, puis va incrémenter A1.
Ainsi, en UNE instruction on va faire un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(*A1) = (*A1) + D2;
A1 = A1 + 2;

Ce qui se résume avec leur syntaxe en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(*A1++) += D2;

Et ça tombe bien...
1 ligne de C avec une fois A1 écrit, et une fois D2 écrit...
Traduisible si je me souviens bien en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ADD D2,(A1)+

C'était soit post-incrémentation, soit pré-décrementation : (Ax)+ ou -(Ax)

Et ça... c'est "typique" de l'époque CISC.

[Invité]

et comment vous avez appris le langage C ?

[JulieCarree]

Bonjour,
perso "Programmation en langage C" de Stephen Kochan , 3éme edition (ANSI C99) chez Pearson. part de zéro et ne couvre pas la libC.

[Médinoc]

Je l'ai appris en classe. Le livre recommandé était le Alannoy, mais c'est surtout les cours et exercices en classe qui m'ont appris le langage.

Puis, fréquenter le forum m'a appris à faire du C standard plutôt que tenter de jouer au plus malin avec les trucs à bas niveau.

[deletme]

Salut,

Tu trouveras une discussion sur les moyens d'apprentissage du langage C ici :
http://www.developpez.net/forums/d13...ait-a-refaire/

dM

[mith06]

J'ai "appris" le C a l’école avec le "K&R" en support. C'est une super bouquin pour se faire une bonne base en C.

Après j'ai beaucoup aimé :
Méthodologie de la programmation en C : Norme C 99 - API POSIX
Achille Braquelaire

Il est plus à jour que le K&R.

[Bysbobo]

Dans le même esprit, « =+ » permet d'exprimer en soi l'auto-affectation. Quand on écrit « a = a + 1 », ça ne change pas grand chose, mais quand la lvalue est une expression très longue, c'est utile de ne pas avoir à la recopier systématiquement de part et d'autre du signe et surtout de ne pas avoir à les maintenir toutes les deux chaque fois qu'on leur apporte une modification.

Juste comme ça, "=+" ça existe?

[Mipwiq]

Juste comme ça, "=+" ça existe?

C'est une faute de frappe pour "+=", mais tu peux parfaitement écrire toto=+50, ton compilateur considèrera que c'est le signe de l'expression après le =.

[Bysbobo]

Ok... Je fais une remarque parce qu'en lisant tous les commentaires, j'ai noté une écriture différente de ce que j'ai l'habitude de voir et je me prends un pouce. La prochaine fois je vous laisse les coquilles

Sinon, merci pour la précision