éternel débutant en C pour mon plaisir, je me permets de venir vous
demander quelques éclaircissements sur une situation que je n'arrive pas
à comprendre :
J'utilise le cours en ligne spécial "grand débutant" du "site du zéro" :
<http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html>
Je réalise les exercices du cours dans deux environnements différents :
- sous windows vista avec l'IDE visual C++ 2008 express
- sous linux ubuntu 9.04 avec gcc
J'ai écrit un programme dans le cadre des exercices proposés sur les
tableaux par ce cours en ligne. Le fichier en question peut être
téléchargé ici :
< http://dl.free.fr/to7PFReLM/tableau.c>
Ce qui m'étonne, c'est que j'arrive à compiler sans difficulté ce code
sous Linux, et que le programme se comporte exactement comme je le
souhaite. Par contre, sous Windows, impossible de compiler, l'IDE me
renvoie 42 erreurs et 31 avertissements !!! La plupart des erreurs
semblent être liées aux variables. Par exemple :
"erreur de syntaxe : absence de ';' avant 'type'"
"identificateur non déclaré"
Or, j'ai beau lire et relire mon code, les variables me sembles toutes
déclarées correctement et il ne manque à mon sens pas de ";" en fin
d'instructions. De plus, comme je le disais au début, le même code se
compile sans aucune erreur sous Linux ...
Alors, comment expliquer que deux compilateurs réagissent aussi
différemment, et où et mon erreur ?
Merci par avance du temps que vous pourrez me consacrer,
intéressé par python mais je considère C en premier parce que on peut faire appel à C dans d'autres langages alors que on ne peut pas faire appel à d'autres langage dans C et il semble que C est à la base et que c'est un langage qui se compile rapidement.
On peut embarquer un interpréteur Python (ou Lua, ou Perl) dans un programme en C.
--
> D'ailleurs: c'est une FAQ : csh, pour les scripts, c'est mal :) Oui, pour le reste, aussi. :)
Sauf pour les voyages, dans ce cas les C Shell sont plus ensoleillés. --- azathoth, relevant le niveau de fcol.debats ---
On 2009-09-12, bpascal123@googlemail.com <bpascal123@googlemail.com> wrote:
intéressé par python mais je considère C en premier parce que on peut
faire appel à C dans d'autres langages alors que on ne peut pas faire
appel à d'autres langage dans C et il semble que C est à la base et
que c'est un langage qui se compile rapidement.
On peut embarquer un interpréteur Python (ou Lua, ou Perl)
dans un programme en C.
--
> D'ailleurs: c'est une FAQ : csh, pour les scripts, c'est mal :)
Oui, pour le reste, aussi. :)
Sauf pour les voyages, dans ce cas les C Shell sont plus ensoleillés.
--- azathoth, relevant le niveau de fcol.debats ---
intéressé par python mais je considère C en premier parce que on peut faire appel à C dans d'autres langages alors que on ne peut pas faire appel à d'autres langage dans C et il semble que C est à la base et que c'est un langage qui se compile rapidement.
On peut embarquer un interpréteur Python (ou Lua, ou Perl) dans un programme en C.
--
> D'ailleurs: c'est une FAQ : csh, pour les scripts, c'est mal :) Oui, pour le reste, aussi. :)
Sauf pour les voyages, dans ce cas les C Shell sont plus ensoleillés. --- azathoth, relevant le niveau de fcol.debats ---
JKB
Le 17-09-2009, ? propos de Re: To pointer or not to pointer ?, Thierry B ?crivait dans fr.comp.lang.c :
On 2009-09-12, wrote:
intéressé par python mais je considère C en premier parce que on peut faire appel à C dans d'autres langages alors que on ne peut pas faire appel à d'autres langage dans C et il semble que C est à la base et que c'est un langage qui se compile rapidement.
On peut embarquer un interpréteur Python (ou Lua, ou Perl) dans un programme en C.
Même un RPL/2, c'est dire...
JKB ---> []
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-09-2009, ? propos de
Re: To pointer or not to pointer ?,
Thierry B ?crivait dans fr.comp.lang.c :
On 2009-09-12, bpascal123@googlemail.com <bpascal123@googlemail.com> wrote:
intéressé par python mais je considère C en premier parce que on peut
faire appel à C dans d'autres langages alors que on ne peut pas faire
appel à d'autres langage dans C et il semble que C est à la base et
que c'est un langage qui se compile rapidement.
On peut embarquer un interpréteur Python (ou Lua, ou Perl)
dans un programme en C.
Même un RPL/2, c'est dire...
JKB ---> []
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 17-09-2009, ? propos de Re: To pointer or not to pointer ?, Thierry B ?crivait dans fr.comp.lang.c :
On 2009-09-12, wrote:
intéressé par python mais je considère C en premier parce que on peut faire appel à C dans d'autres langages alors que on ne peut pas faire appel à d'autres langage dans C et il semble que C est à la base et que c'est un langage qui se compile rapidement.
On peut embarquer un interpréteur Python (ou Lua, ou Perl) dans un programme en C.
Même un RPL/2, c'est dire...
JKB ---> []
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
-ed-
On 15 sep, 14:02, "" wrote:
En fait, dans le langage C, aujourd'hui ce qui me pose le plus de difficulté, c'est la portabilité entre Windows et Linux et les mod es de saisie utilisateur ou autre avec scanf, frets, getchar...et les caractères de 'n' et autres. C'est vrai que je n'ai pas encore mis complètement un pied dans les pointeurs ni une grande maîtrise des fonctions. Mais comment se fait-il qu'une simple saisie sur un clavier puisse fonctionner sous Windows et donner une boucle d'erreurs sans fin sous Linux ou inversement?
Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de saisies du C sont assez subtiles. Je conseille de lire ceci :
http://www.bien-programmer.fr/notes.php#saisie
et surtout
http://www.bien-programmer.fr/notes.php#fgetc
1° le passage d'une norme à une autre ne rend pas les choses faciles entre les systèmes qui évoluent, mais pas au même moment que les organismes de normalisation, d'où des décalages de comportements entr e les OS ....
Non. Le comportement est le même si on utilise les fonctions correctement (il faut notamment bannir notamment fflush(stdin) qui, vu de la norme, n'existe pas !)
2° n'ayant pas suivie de formation en informatique, j'ai des lacunes assez importantes pour comprendre certains concepts comme le lien entre un périphérique clavier et la mémoire "buffer" qui je crois s e trouve dans la partie haute de la ram. Je suppose qu'il doit aussi y avoir un lien avec heap, stack et autre...
Aucun rapport. Oublie de c'est une RAM. En C, on parle de mémoire. C'est une abstraction.
En C, les fonctions de saisie clavier avec lesquelles je considère travailler sont scanf pour les entiers seulement, fgets (...stdin) pour les caractères et getchar() soit pour saisir un caractère isol é ou pour "nettoyer" le buffer. Seulement, je n'arrive pas à comprendre l'action de getchar sur le buffer.
C'est expliqué dans l'article cité au-dessus.
On 15 sep, 14:02, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:
En fait, dans le langage C, aujourd'hui ce qui me pose le plus de
difficulté, c'est la portabilité entre Windows et Linux et les mod es
de saisie utilisateur ou autre avec scanf, frets, getchar...et les
caractères de 'n' et autres. C'est vrai que je n'ai pas encore mis
complètement un pied dans les pointeurs ni une grande maîtrise des
fonctions.
Mais comment se fait-il qu'une simple saisie sur un clavier puisse
fonctionner sous Windows et donner une boucle d'erreurs sans fin sous
Linux ou inversement?
Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de
saisies du C sont assez subtiles. Je conseille de lire ceci :
http://www.bien-programmer.fr/notes.php#saisie
et surtout
http://www.bien-programmer.fr/notes.php#fgetc
1° le passage d'une norme à une autre ne rend pas les choses faciles
entre les systèmes qui évoluent, mais pas au même moment que les
organismes de normalisation, d'où des décalages de comportements entr e
les OS ....
Non. Le comportement est le même si on utilise les fonctions
correctement (il faut notamment bannir notamment fflush(stdin) qui, vu
de la norme, n'existe pas !)
2° n'ayant pas suivie de formation en informatique, j'ai des lacunes
assez importantes pour comprendre certains concepts comme le lien
entre un périphérique clavier et la mémoire "buffer" qui je crois s e
trouve dans la partie haute de la ram. Je suppose qu'il doit aussi y
avoir un lien avec heap, stack et autre...
Aucun rapport. Oublie de c'est une RAM. En C, on parle de mémoire.
C'est une abstraction.
En C, les fonctions de saisie clavier avec lesquelles je considère
travailler sont scanf pour les entiers seulement, fgets (...stdin)
pour les caractères et getchar() soit pour saisir un caractère isol é
ou pour "nettoyer" le buffer. Seulement, je n'arrive pas à comprendre
l'action de getchar sur le buffer.
En fait, dans le langage C, aujourd'hui ce qui me pose le plus de difficulté, c'est la portabilité entre Windows et Linux et les mod es de saisie utilisateur ou autre avec scanf, frets, getchar...et les caractères de 'n' et autres. C'est vrai que je n'ai pas encore mis complètement un pied dans les pointeurs ni une grande maîtrise des fonctions. Mais comment se fait-il qu'une simple saisie sur un clavier puisse fonctionner sous Windows et donner une boucle d'erreurs sans fin sous Linux ou inversement?
Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de saisies du C sont assez subtiles. Je conseille de lire ceci :
http://www.bien-programmer.fr/notes.php#saisie
et surtout
http://www.bien-programmer.fr/notes.php#fgetc
1° le passage d'une norme à une autre ne rend pas les choses faciles entre les systèmes qui évoluent, mais pas au même moment que les organismes de normalisation, d'où des décalages de comportements entr e les OS ....
Non. Le comportement est le même si on utilise les fonctions correctement (il faut notamment bannir notamment fflush(stdin) qui, vu de la norme, n'existe pas !)
2° n'ayant pas suivie de formation en informatique, j'ai des lacunes assez importantes pour comprendre certains concepts comme le lien entre un périphérique clavier et la mémoire "buffer" qui je crois s e trouve dans la partie haute de la ram. Je suppose qu'il doit aussi y avoir un lien avec heap, stack et autre...
Aucun rapport. Oublie de c'est une RAM. En C, on parle de mémoire. C'est une abstraction.
En C, les fonctions de saisie clavier avec lesquelles je considère travailler sont scanf pour les entiers seulement, fgets (...stdin) pour les caractères et getchar() soit pour saisir un caractère isol é ou pour "nettoyer" le buffer. Seulement, je n'arrive pas à comprendre l'action de getchar sur le buffer.
C'est expliqué dans l'article cité au-dessus.
Thierry B
On 2009-09-16, Pierre Maurette wrote:
Mouarf. Ça me rappelle les petits jeux sur les premières calculatrices programmables qui écrivaient des trucs marrant quand on les lisait en retournant la calculette.
-- "The argument against using an operator for other than its primary purpose strikes me the same as the old argument that you shouldn't have sex for other than procreational purposes. Sometimes side effects are more enjoyable than the originally intended effect." (Larry Wall)
On 2009-09-16, Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Mouarf. Ça me rappelle les petits jeux sur les premières calculatrices
programmables qui écrivaient des trucs marrant quand on les lisait en
retournant la calculette.
--
"The argument against using an operator for other than its primary
purpose strikes me the same as the old argument that you shouldn't have
sex for other than procreational purposes. Sometimes side effects
are more enjoyable than the originally intended effect." (Larry Wall)
Mouarf. Ça me rappelle les petits jeux sur les premières calculatrices programmables qui écrivaient des trucs marrant quand on les lisait en retournant la calculette.
-- "The argument against using an operator for other than its primary purpose strikes me the same as the old argument that you shouldn't have sex for other than procreational purposes. Sometimes side effects are more enjoyable than the originally intended effect." (Larry Wall)
candide
-ed- a écrit :
Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de saisies du C sont assez subtiles. Je conseille de lire ceci :
http://www.bien-programmer.fr/notes.php#saisie
Tu es vraiment le Monsieur Jourdain du C toi. Quand je lis le titre de ce que tu proposes de lire au PO (vu les questions qu'il a posées ...) :
"Saisie de données par un opérateur (stdin)"
...
ya de quoi se dire que le langage C est un langage de bois, camarade !
et surtout
http://www.bien-programmer.fr/notes.php#fgetc
Et encore pire ici, on navigue entre les abstractions imbitables (pour celui qui ne connait pas mais je suppose que tu es censé t'adresser à lui ou alors tu te parles à toi-même) et les truismes (j'adore le : "Soit le flux est vide, soit il ne l'est pas.").
Tu prétends gaillardemment
"En effet, elle regroupe un certain nombre de comportements non triviaux qui sont rarement expliqués dans la littérature C"
Quels comportement non triviaux as-tu expliqués ? Tu as vraiment lu la littérature C ?
En fait, tu expliques de façon pédante un truc très simple et tu sembles particulariser le cas de fgetc() alors que ça s'applique plus généralement à n'importe quelle saisie sur stdin ("suspension" + bufferisation) et tu esquives toutes les difficultés de fgetc, à savoir :
*) la capture en unsigned int suivie de la conversion en int ; *) le problème de EOF.
Sinon, le contenu du titre n'est pas tout à fait exact : "Comment fonctionne fgetc(stdin) alias getchar()" (au passage t'as oublié le point d'interrogation) : getchar() peut être une macro donc le terme d'alias n'est pas approprié
Et d'autre part, tu proposes le code de test suivant :
Trouves-tu normal que ton programme C ne permette pas de sortir de la boucle infinie (même avec EOF en CTRL+D sous Linux) ?
Exemple de saisie :
$ ./fclc toto x = 116 ('t') x = 111 ('o') x = 116 ('t') x = 111 ('o') x = 10 (' ') jeveux sortir : je tape CTRL+Dx = 106 ('j') x = 101 ('e') x = 118 ('v') x = 101 ('e') x = 117 ('u') x = 120 ('x') x = 32 (' ') x = 115 ('s') x = 111 ('o') x = 114 ('r') x = 116 ('t') x = 105 ('i') x = 114 ('r') x = 32 (' ') x = 58 (':') x = 32 (' ') x = 106 ('j') x = 101 ('e') x = 32 (' ') x = 116 ('t') x = 97 ('a') x = 112 ('p') x = 101 ('e') x = 32 (' ') x = 67 ('C') x = 84 ('T') x = 82 ('R') x = 76 ('L') x = 43 ('+') x = 68 ('D') Seule solution : a la sauvage CTRL+C $
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque un fflush(stdout).
J'adore aussi la remarque qui suit ce code :
"Je laisse au lecteur le soin de refaire les expériences précédentes et d'en tirer les conclusions qui s'imposent."
Moi j'ai tiré les conclusions qui s'imposent :)
-ed- a écrit :
Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de
saisies du C sont assez subtiles. Je conseille de lire ceci :
http://www.bien-programmer.fr/notes.php#saisie
Tu es vraiment le Monsieur Jourdain du C toi. Quand je lis le titre de ce que tu
proposes de lire au PO (vu les questions qu'il a posées ...) :
"Saisie de données par un opérateur (stdin)"
...
ya de quoi se dire que le langage C est un langage de bois, camarade !
et surtout
http://www.bien-programmer.fr/notes.php#fgetc
Et encore pire ici, on navigue entre les abstractions imbitables (pour celui qui
ne connait pas mais je suppose que tu es censé t'adresser à lui ou alors tu te
parles à toi-même) et les truismes (j'adore le : "Soit le flux est vide, soit il
ne l'est pas.").
Tu prétends gaillardemment
"En effet, elle regroupe un certain nombre de comportements non triviaux qui
sont rarement expliqués dans la littérature C"
Quels comportement non triviaux as-tu expliqués ? Tu as vraiment lu la
littérature C ?
En fait, tu expliques de façon pédante un truc très simple et tu sembles
particulariser le cas de fgetc() alors que ça s'applique plus généralement à
n'importe quelle saisie sur stdin ("suspension" + bufferisation) et tu esquives
toutes les difficultés de fgetc, à savoir :
*) la capture en unsigned int suivie de la conversion en int ;
*) le problème de EOF.
Sinon, le contenu du titre n'est pas tout à fait exact : "Comment fonctionne
fgetc(stdin) alias getchar()" (au passage t'as oublié le point d'interrogation)
: getchar() peut être une macro donc le terme d'alias n'est pas approprié
Et d'autre part, tu proposes le code de test suivant :
Trouves-tu normal que ton programme C ne permette pas de sortir de la boucle
infinie (même avec EOF en CTRL+D sous Linux) ?
Exemple de saisie :
$ ./fclc
toto
x = 116 ('t')
x = 111 ('o')
x = 116 ('t')
x = 111 ('o')
x = 10 ('
')
jeveux sortir : je tape CTRL+Dx = 106 ('j')
x = 101 ('e')
x = 118 ('v')
x = 101 ('e')
x = 117 ('u')
x = 120 ('x')
x = 32 (' ')
x = 115 ('s')
x = 111 ('o')
x = 114 ('r')
x = 116 ('t')
x = 105 ('i')
x = 114 ('r')
x = 32 (' ')
x = 58 (':')
x = 32 (' ')
x = 106 ('j')
x = 101 ('e')
x = 32 (' ')
x = 116 ('t')
x = 97 ('a')
x = 112 ('p')
x = 101 ('e')
x = 32 (' ')
x = 67 ('C')
x = 84 ('T')
x = 82 ('R')
x = 76 ('L')
x = 43 ('+')
x = 68 ('D')
Seule solution : a la sauvage CTRL+C
$
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque un
fflush(stdout).
J'adore aussi la remarque qui suit ce code :
"Je laisse au lecteur le soin de refaire les expériences précédentes et d'en
tirer les conclusions qui s'imposent."
Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de saisies du C sont assez subtiles. Je conseille de lire ceci :
http://www.bien-programmer.fr/notes.php#saisie
Tu es vraiment le Monsieur Jourdain du C toi. Quand je lis le titre de ce que tu proposes de lire au PO (vu les questions qu'il a posées ...) :
"Saisie de données par un opérateur (stdin)"
...
ya de quoi se dire que le langage C est un langage de bois, camarade !
et surtout
http://www.bien-programmer.fr/notes.php#fgetc
Et encore pire ici, on navigue entre les abstractions imbitables (pour celui qui ne connait pas mais je suppose que tu es censé t'adresser à lui ou alors tu te parles à toi-même) et les truismes (j'adore le : "Soit le flux est vide, soit il ne l'est pas.").
Tu prétends gaillardemment
"En effet, elle regroupe un certain nombre de comportements non triviaux qui sont rarement expliqués dans la littérature C"
Quels comportement non triviaux as-tu expliqués ? Tu as vraiment lu la littérature C ?
En fait, tu expliques de façon pédante un truc très simple et tu sembles particulariser le cas de fgetc() alors que ça s'applique plus généralement à n'importe quelle saisie sur stdin ("suspension" + bufferisation) et tu esquives toutes les difficultés de fgetc, à savoir :
*) la capture en unsigned int suivie de la conversion en int ; *) le problème de EOF.
Sinon, le contenu du titre n'est pas tout à fait exact : "Comment fonctionne fgetc(stdin) alias getchar()" (au passage t'as oublié le point d'interrogation) : getchar() peut être une macro donc le terme d'alias n'est pas approprié
Et d'autre part, tu proposes le code de test suivant :
Trouves-tu normal que ton programme C ne permette pas de sortir de la boucle infinie (même avec EOF en CTRL+D sous Linux) ?
Exemple de saisie :
$ ./fclc toto x = 116 ('t') x = 111 ('o') x = 116 ('t') x = 111 ('o') x = 10 (' ') jeveux sortir : je tape CTRL+Dx = 106 ('j') x = 101 ('e') x = 118 ('v') x = 101 ('e') x = 117 ('u') x = 120 ('x') x = 32 (' ') x = 115 ('s') x = 111 ('o') x = 114 ('r') x = 116 ('t') x = 105 ('i') x = 114 ('r') x = 32 (' ') x = 58 (':') x = 32 (' ') x = 106 ('j') x = 101 ('e') x = 32 (' ') x = 116 ('t') x = 97 ('a') x = 112 ('p') x = 101 ('e') x = 32 (' ') x = 67 ('C') x = 84 ('T') x = 82 ('R') x = 76 ('L') x = 43 ('+') x = 68 ('D') Seule solution : a la sauvage CTRL+C $
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque un fflush(stdout).
J'adore aussi la remarque qui suit ce code :
"Je laisse au lecteur le soin de refaire les expériences précédentes et d'en tirer les conclusions qui s'imposent."
Moi j'ai tiré les conclusions qui s'imposent :)
-ed-
On 18 sep, 12:48, candide wrote:
-ed- a écrit :
> Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de > saisies du C sont assez subtiles. Je conseille de lire ceci :
>http://www.bien-programmer.fr/notes.php#saisie
Tu es vraiment le Monsieur Jourdain du C toi. Quand je lis le titre de ce que tu proposes de lire au PO (vu les questions qu'il a posées ...) :
<...>
Moi j'ai tiré les conclusions qui s'imposent :)
Oui, oui, et on attend toujours ta méthode de C parfaite...
"La critique est aisée mais l'art est difficile"...
En attendant, j'essaye d'aider les gens du mieux que je peux et à part toi, personne ne s'en plaint ... Si ce que je dis sur mon site était si horrible ou faux que tu le dis, il y a longtemps que tout le monde ici me serait tomber dessus... Or, ce n'est pas le cas. (ok pour le '?' manquant, au moins une critique constructive !).
On 18 sep, 12:48, candide <cand...@free.invalid> wrote:
-ed- a écrit :
> Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de
> saisies du C sont assez subtiles. Je conseille de lire ceci :
>http://www.bien-programmer.fr/notes.php#saisie
Tu es vraiment le Monsieur Jourdain du C toi. Quand je lis le titre de ce que tu
proposes de lire au PO (vu les questions qu'il a posées ...) :
<...>
Moi j'ai tiré les conclusions qui s'imposent :)
Oui, oui, et on attend toujours ta méthode de C parfaite...
"La critique est aisée mais l'art est difficile"...
En attendant, j'essaye d'aider les gens du mieux que je peux et à part
toi, personne ne s'en plaint ... Si ce que je dis sur mon site était
si horrible ou faux que tu le dis, il y a longtemps que tout le monde
ici me serait tomber dessus... Or, ce n'est pas le cas. (ok pour le
'?' manquant, au moins une critique constructive !).
> Ca n'a pas grand chose à voir avec l'environnement. Les fonctions de > saisies du C sont assez subtiles. Je conseille de lire ceci :
>http://www.bien-programmer.fr/notes.php#saisie
Tu es vraiment le Monsieur Jourdain du C toi. Quand je lis le titre de ce que tu proposes de lire au PO (vu les questions qu'il a posées ...) :
<...>
Moi j'ai tiré les conclusions qui s'imposent :)
Oui, oui, et on attend toujours ta méthode de C parfaite...
"La critique est aisée mais l'art est difficile"...
En attendant, j'essaye d'aider les gens du mieux que je peux et à part toi, personne ne s'en plaint ... Si ce que je dis sur mon site était si horrible ou faux que tu le dis, il y a longtemps que tout le monde ici me serait tomber dessus... Or, ce n'est pas le cas. (ok pour le '?' manquant, au moins une critique constructive !).
-ed-
On 18 sep, 12:48, candide wrote:
"En effet, elle regroupe un certain nombre de comportements non triviaux qui sont rarement expliqués dans la littérature C"
Quels comportement non triviaux as-tu expliqués ?
Le comportement de fgetc(stdin) (visible, interne etc.) tu n'as pas lu la suite ? Tu ne l'as pas comprise ?
Tu as vraiment lu la littérature C ?
Je ne prétends pas avoir tout lu Je me base sur ce que j'ai lu et sur les questions posées par les gens...
En fait, tu expliques de façon pédante un truc très simple et tu se mbles particulariser le cas de fgetc() alors que ça s'applique plus génér alement à n'importe quelle saisie sur stdin ("suspension" + bufferisation) et tu es quives toutes les difficultés de fgetc, à savoir :
fgetc() étant la fonction 'atomique' qui sert à créer tout le reste, oui, il est logique de chercher à comprendre le fonctionnement de celle-ci... Le comportement des autres fonction en découle en grande partie.
*) la capture en unsigned int suivie de la conversion en int ;
Hors-sujet. C'est pas le problème de fgetc().
*) le problème de EOF.
Hors-sujet. C'est un cas particulier qui n'a rien à voir avec les problèmes de saisie les plus courants.
Sinon, le contenu du titre n'est pas tout à fait exact : "Comment fonct ionne fgetc(stdin) alias getchar()" (au passage t'as oublié le point d'interr ogation)
Corrigé, merci.
: getchar() peut être une macro donc le terme d'alias n'est pas appropr ié
Si tu en as un meilleur ...
Et d'autre part, tu proposes le code de test suivant :
do { x = fgetc(stdin); printf ("x = %d ('%c')n", x, x); } while (1);
return 0;}
/* -------------------------------------------*/
Trouves-tu normal que ton programme C ne permette pas de sortir de la bou cle infinie (même avec EOF en CTRL+D sous Linux) ?
Oui. Le but est de vérifier un certain comportement, et non de réaliser une application fonctionnelle.
Propose autre chose.
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque u n fflush(stdout).
Non, car la ligne d'affichage est terminée par un 'n'.
Rappel :
printf ("x = %d ('%c')n", x, x);
Moi j'ai tiré les conclusions qui s'imposent :)
et elles sont fausses ou hors-sujet.
On 18 sep, 12:48, candide <cand...@free.invalid> wrote:
"En effet, elle regroupe un certain nombre de comportements non triviaux qui
sont rarement expliqués dans la littérature C"
Quels comportement non triviaux as-tu expliqués ?
Le comportement de fgetc(stdin) (visible, interne etc.) tu n'as pas lu
la suite ? Tu ne l'as pas comprise ?
Tu as vraiment lu la
littérature C ?
Je ne prétends pas avoir tout lu Je me base sur ce que j'ai lu et sur
les questions posées par les gens...
En fait, tu expliques de façon pédante un truc très simple et tu se mbles
particulariser le cas de fgetc() alors que ça s'applique plus génér alement à
n'importe quelle saisie sur stdin ("suspension" + bufferisation) et tu es quives
toutes les difficultés de fgetc, à savoir :
fgetc() étant la fonction 'atomique' qui sert à créer tout le reste,
oui, il est logique de chercher à comprendre le fonctionnement de
celle-ci... Le comportement des autres fonction en découle en grande
partie.
*) la capture en unsigned int suivie de la conversion en int ;
Hors-sujet. C'est pas le problème de fgetc().
*) le problème de EOF.
Hors-sujet. C'est un cas particulier qui n'a rien à voir avec les
problèmes de saisie les plus courants.
Sinon, le contenu du titre n'est pas tout à fait exact : "Comment fonct ionne
fgetc(stdin) alias getchar()" (au passage t'as oublié le point d'interr ogation)
Corrigé, merci.
: getchar() peut être une macro donc le terme d'alias n'est pas appropr ié
Si tu en as un meilleur ...
Et d'autre part, tu proposes le code de test suivant :
"En effet, elle regroupe un certain nombre de comportements non triviaux qui sont rarement expliqués dans la littérature C"
Quels comportement non triviaux as-tu expliqués ?
Le comportement de fgetc(stdin) (visible, interne etc.) tu n'as pas lu la suite ? Tu ne l'as pas comprise ?
Tu as vraiment lu la littérature C ?
Je ne prétends pas avoir tout lu Je me base sur ce que j'ai lu et sur les questions posées par les gens...
En fait, tu expliques de façon pédante un truc très simple et tu se mbles particulariser le cas de fgetc() alors que ça s'applique plus génér alement à n'importe quelle saisie sur stdin ("suspension" + bufferisation) et tu es quives toutes les difficultés de fgetc, à savoir :
fgetc() étant la fonction 'atomique' qui sert à créer tout le reste, oui, il est logique de chercher à comprendre le fonctionnement de celle-ci... Le comportement des autres fonction en découle en grande partie.
*) la capture en unsigned int suivie de la conversion en int ;
Hors-sujet. C'est pas le problème de fgetc().
*) le problème de EOF.
Hors-sujet. C'est un cas particulier qui n'a rien à voir avec les problèmes de saisie les plus courants.
Sinon, le contenu du titre n'est pas tout à fait exact : "Comment fonct ionne fgetc(stdin) alias getchar()" (au passage t'as oublié le point d'interr ogation)
Corrigé, merci.
: getchar() peut être une macro donc le terme d'alias n'est pas appropr ié
Si tu en as un meilleur ...
Et d'autre part, tu proposes le code de test suivant :
do { x = fgetc(stdin); printf ("x = %d ('%c')n", x, x); } while (1);
return 0;}
/* -------------------------------------------*/
Trouves-tu normal que ton programme C ne permette pas de sortir de la bou cle infinie (même avec EOF en CTRL+D sous Linux) ?
Oui. Le but est de vérifier un certain comportement, et non de réaliser une application fonctionnelle.
Propose autre chose.
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque u n fflush(stdout).
Non, car la ligne d'affichage est terminée par un 'n'.
Rappel :
printf ("x = %d ('%c')n", x, x);
Moi j'ai tiré les conclusions qui s'imposent :)
et elles sont fausses ou hors-sujet.
-ed-
On 18 sep, 14:18, -ed- wrote:
> *) la capture en unsigned int suivie de la conversion en int ;
Hors-sujet. C'est pas le problème de fgetc().
OK, je vois ce que tu veux dire (j'avais compris autre chose). Oui, c'est un problème délicat. Je pourrais l'aborder ici, mais j'ai peur que ça ne fasse que compliquer pour rien. (je vois d'ici les commentaires : "verbeux", "pédant" etc.). Mon but était déjà de traiter le problème de base, à savoir le comportement de fgetc(stdin) qui est mystérieux pour beaucoup de monde.
On 18 sep, 14:18, -ed- <emmanuel.delah...@gmail.com> wrote:
> *) la capture en unsigned int suivie de la conversion en int ;
Hors-sujet. C'est pas le problème de fgetc().
OK, je vois ce que tu veux dire (j'avais compris autre chose). Oui,
c'est un problème délicat. Je pourrais l'aborder ici, mais j'ai peur
que ça ne fasse que compliquer pour rien. (je vois d'ici les
commentaires : "verbeux", "pédant" etc.). Mon but était déjà de
traiter le problème de base, à savoir le comportement de fgetc(stdin)
qui est mystérieux pour beaucoup de monde.
> *) la capture en unsigned int suivie de la conversion en int ;
Hors-sujet. C'est pas le problème de fgetc().
OK, je vois ce que tu veux dire (j'avais compris autre chose). Oui, c'est un problème délicat. Je pourrais l'aborder ici, mais j'ai peur que ça ne fasse que compliquer pour rien. (je vois d'ici les commentaires : "verbeux", "pédant" etc.). Mon but était déjà de traiter le problème de base, à savoir le comportement de fgetc(stdin) qui est mystérieux pour beaucoup de monde.
candide
-ed- a écrit :
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque un fflush(stdout).
Non, car la ligne d'affichage est terminée par un 'n'.
Oui otan pour moi.
-ed- a écrit :
Tiens au passage il me semble bien, vu l'effet souhaité, qu'il manque un
fflush(stdout).
Non, car la ligne d'affichage est terminée par un 'n'.
