Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C Vider le buffer associe a stdin

Vider le buffer associe a stdin

98 réponses
Avatar
korchkidu
Bonjour,

je me pose une question par rapport a la maniere classique de vider le
buffer associe a stdin:

c = getchar();
if (c != ’\n’)
while ( (getchar()) != ’\n’) {
};

Que se passe t-il si stdin ne contient aucun \n? (fichier contenant une
ligne mais aucun \n par exemple). Dans ce cas, il me semble que l'on
pourrait avoir un probleme non?

Comment feriez vous pour resoudre ce probleme? (J'ai bien une petite
idee mais je prefere savoir si c'est la bonne..;) )

Merci d'avance pour vos reponses,
K.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
6 7 8 9 10
Avatar
Thierry
Charlie Gordon wrote:
Pas terrible.



je suis d'accord. La bonne solution est d'éviter les mots clés du C++ dans du
code C. A fortiori dans des headers dont personne ne peut jurer qu'ils ne
seront jamais partagés avec du C++.


Donc, pour toi, pour faire du C, il est recommandé de connaître le C++ ?

--
Thierry


Avatar
Antoine Leca
En 4193498a$0$8435$, Thierry va escriure:
La bonne solution est d'éviter les mots clés du C++ dans du code C.


Donc, pour toi, pour faire du C, il est recommandé de connaître le
C++ ?


Pour toi, connaître les mots clés suffit pour connaître un langage de
programmation ?


Antoine


Avatar
Emmanuel Delahaye
korchkidu wrote on 29/10/04 :
Bonjour,

je me pose une question par rapport a la maniere classique de vider le buffer
associe a stdin:

c = getchar();
if (c != ?n?)
while ( (getchar()) != ?n?) {
};


Je ne sais pas d'où vient ce code, mais je préconise plutôt:

void clr_stdin(void)
{
int c;

while ((c = getchar() != 'n' && c != EOF)
{
}
}

Que se passe t-il si stdin ne contient aucun n? (fichier contenant une ligne
mais aucun n par exemple). Dans ce cas, il me semble que l'on pourrait avoir
un probleme non?


Ben oui, c'est pour ça que je m'interroge sur l'origine du code que tu
as posté...

Comment feriez vous pour resoudre ce probleme? (J'ai bien une petite idee
mais je prefere savoir si c'est la bonne..;) )


Voir ci-dessus.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Avatar
Charlie Gordon
"Thierry" wrote in message
news:4193498a$0$8435$
Charlie Gordon wrote:
Pas terrible.


je suis d'accord. La bonne solution est d'éviter les mots clés du C++ dans
du


code C. A fortiori dans des headers dont personne ne peut jurer qu'ils ne
seront jamais partagés avec du C++.


Donc, pour toi, pour faire du C, il est recommandé de connaître le C++ ?


Il est recommandé de connaitre d'autres langages en effet, mais pas nécessaire.
Je recommande juste d'éviter certains mots-clés, que je liste explicitement.
Tous ne sont pas du C++.
Ceux qui connaissent le C++ comprendront pourquoi.

Les mot-clés en question sont suffisamment vagues pour que le choix de nommer
ainsi des variables soit de tout façon peu avisé : this new delete class private
public template try catch using virtual... mais aussi in out...

J'en réserve certains pour un usage précis : byte word typeof ...

Chqrlie.



Avatar
Thierry
Antoine Leca wrote:
En 4193498a$0$8435$, Thierry va escriure:

La bonne solution est d'éviter les mots clés du C++ dans du code C.


Donc, pour toi, pour faire du C, il est recommandé de connaître le
C++ ?



Pour toi, connaître les mots clés suffit pour connaître un langage de
programmation ?



Je repose ma question : est-il recommandé de connaître les mots-clef du
C++ pour faire du C ?

--
Thierry



Avatar
Thierry
Charlie Gordon wrote:
"Thierry" wrote in message
news:4193498a$0$8435$

Charlie Gordon wrote:

Pas terrible.


je suis d'accord. La bonne solution est d'éviter les mots clés du C++ dans



du

code C. A fortiori dans des headers dont personne ne peut jurer qu'ils ne
seront jamais partagés avec du C++.


Donc, pour toi, pour faire du C, il est recommandé de connaître le C++ ?



Il est recommandé de connaitre d'autres langages en effet, mais pas nécessaire.
Je recommande juste d'éviter certains mots-clés, que je liste explicitement.
Tous ne sont pas du C++.
Ceux qui connaissent le C++ comprendront pourquoi.

Les mot-clés en question sont suffisamment vagues pour que le choix de nommer
ainsi des variables soit de tout façon peu avisé : this new delete class private
public template try catch using virtual... mais aussi in out...

J'en réserve certains pour un usage précis : byte word typeof ...



J'avais bien compris :-) et je suis d'accord avec toi.

D'ailleurs je n'utilise pas des noms comme "new", "class" ou "this"
quand je fait du C (*), mais c'était plutôt la logique "pour faire du C
il faut connaître les mots-clef du C++" qui me fait toujours un peu tiquer.

--
Thierry
* : sauf quand on me soutient qu'un compilateur C++ peut *toujours*
compiler du C ;-)




Avatar
James Kanze
Gabriel Dos Reis writes:

|> James Kanze writes:

|> | drkm writes:

|> | |> Emmanuel Delahaye writes:

|> | |> > il me
|> | |> > semble que ce qui est extern "C" n'est pas soumis aux lois
|> | |> > du C++

|> | |> Pas pour ce qui est de l'analyse syntaxique. C'est au niveau
|> | |> du code généré. C'est comme cela par exemple que ton linker
|> | |> s'y retrouve.

|> | Même pas. Les noms et les types qui y sont définis le sont selon
|> | les règles de C,

|> La norme C++ n'est pas d'accord avec toi, 7.5/4 :

Je ne cherchais pas la précision. C'était juste pour dire que même au
niveau du code généré...

En fait, je crois que la seule chose concernée est le type des fonctions
globales (à la portée de namespace, en C++-speak). C'est toujours le
compilateur C++ qui génère le code, et *sauf* les appels des fonctions
avec type « extern "C" », et les préambule et postablule de telles
fonctions, il génère le code exactement comme il fait pour C++.

Pour bien comprendre le « extern "C" », d'ailleurs, il faut bien saisi
cette indirection. Le « extern "C" » n'influe *que* sur le type des
fonctions et des pointeurs aux fonctions (déclarés au moyen des
typedef), et que c'est le type que influe sur la génération du code.
Donc, si j'ai quelque chose du genre :

extern int f() ;
extern "C" int g()
{
f() ;
}

int h()
{
g() ;
}

l'appel de g(), dans h(), se ferait selon les règles C, tandis que
l'appel de f() (dans g()) se ferait selon les règles C++, même s'il se
trouve dans un bloc extern "C".

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Jean-Marc Bourguet
Thierry writes:

Antoine Leca wrote:
En 4193498a$0$8435$, Thierry va escriure:

La bonne solution est d'éviter les mots clés du C++ dans du code C.


Donc, pour toi, pour faire du C, il est recommandé de connaître le
C++ ?
Pour toi, connaître les mots clés suffit pour connaître un langage de

programmation ?



Je repose ma question : est-il recommandé de connaître les
mots-clef du C++ pour faire du C ?


Tout dépend de ce que tu fais et dans quel cadre tu te
places.

Chez nous, la probabilité pour qu'un en-tête public C
finisse par être inclus dans un fichier C++ est fort proche
de 1 et j'imagine assez mal embaucher quelqu'un qui ne
connait pas le C++, même si c'est pour travailler sur un
projet pour le moment en C pur. Le nombre de ceux-ci a
tendance à diminuer (en fait je ne suis pas sûr qu'il y en
ait encore, il y a des parties qui sont en C et maintenue en
C, mais le programme a aussi des parties en C++) et on
change quand même de projets assez souvent. Parmis les plus
vieux il est possible que certains ne connaissent pas le C++
(je n'en sais rien, mon groupe a commencé par une partie C++
donc tout le monde connait le C++).

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org




Avatar
Antoine Leca
En 419376a0$0$24905$, Thierry va escriure:
La bonne solution est d'éviter les mots clés du C++ dans du code C.




Je repose ma question : est-il recommandé de connaître les mots-clef
du C++ pour faire du C ?


Si tu veux éviter au mainteneur des problèmes gratuits de compatibilité plus
tard, oui.


Antoine




Avatar
drkm
James Kanze writes:

l'appel de g(), dans h(), se ferait selon les règles C, tandis que
l'appel de f() (dans g()) se ferait selon les règles C++, même s'il se
trouve dans un bloc extern "C".


Oui. Mais c'est tout de même bien au niveau de la génération de
code que se manifestent les conventions d'appel C, non ? En fait, je
pensais principalement à la décoration des noms et au passage des
paramètres, ce qui pour moi a trait à la génération de code.

Ai-je loupé quelque chose ?

En tout cas, ce que je voulais dire à Emmanuel, qui semblait penser
entre autres que l'analyse syntaxique était différente, que ce n'était
pas le cas. Qu'on écrivait toujours bien du C++ (également du point
de vue sémantique, comme l'a précisé Gaby), et que la différence se
situe au niveau du code généré (où je situe les conventions d'appel).

Mais il est vrai que cela est plus subtile, en fait. L'interdiction
de surcharge, l'interaction avec les namespaces, etc.

Je me rend compte que je ne voyais qu'une partie du problème, et le
limitais principâlement (sic) aux conventions d'appel de fonction.

--drkm

6 7 8 9 10