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
James Kanze
drkm writes:

|> 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 ?

Oui, mais je tiens à ma distinction. Le choix des conventions d'appel se
fait selon le type, et non selon qu'on soit dans un bloc extern "C" ou
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.

Il n'y a pas, formellement, une interdiction de surcharge. C'est
simplement qu'une seule des fonctions surchargées a le droit d'être
extern "C". C'est aussi la raisonement derrière les interactions avec
les namespaces, bien que là, j'avoue qu'il ne me viendra jamais à
l'esprit d'écrire une fonction extern "C" dans un namespace.

|> 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.

C'est quand même la partie principale. La reste en sort, à cause des
limitations techniques que la compatilité (du générée) avec le C impose.

--
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
drkm
James Kanze writes:

Il n'y a pas, formellement, une interdiction de surcharge.


7.4/6 :

At most one function with a particular name can have C language
linkage.

--drkm

Avatar
Yves ROMAN

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?) {
};



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é...



De la FAQ de fclc ! (chapitre 14.5)


Avatar
Emmanuel Delahaye
Yves ROMAN wrote on 12/11/04 :
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?


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


De la FAQ de fclc ! (chapitre 14.5)


La FAQ n'est pas gravée dans le marbre. Si il y a une erreur, il serait
bon de la corriger. Mais il me semble que ce sujet a été abordé il y a
quelques temps...

--
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
Gabriel Dos Reis
drkm writes:

| 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 ?

Tu peux aussi surcharger selon le linkage :

extern "C" double abs(double); // #1
double abs(double); // #2, surcharge de #1

-- Gaby
Avatar
Gabriel Dos Reis
James Kanze writes:

| Il n'y a pas, formellement, une interdiction de surcharge. C'est
| simplement qu'une seule des fonctions surchargées a le droit d'être
| extern "C". C'est aussi la raisonement derrière les interactions avec
| les namespaces, bien que là, j'avoue qu'il ne me viendra jamais à
| l'esprit d'écrire une fonction extern "C" dans un namespace.

La norme C++ demande que l'entête <cstdlib> donne les fonctions

extern "C" int atexit(void (*f)(void));
extern "C++" int atexit(void (*f)(void));

et les place dans le namespace std::.

-- Gaby
Avatar
Gabriel Dos Reis
drkm writes:

| James Kanze writes:
|
| > Il n'y a pas, formellement, une interdiction de surcharge.
|
| 7.4/6 :
|
| At most one function with a particular name can have C language
| linkage.

oui, mais tu peux surcharger sur le linkage. Sic.

-- Gaby
Avatar
drkm
[ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]

Gabriel Dos Reis writes:

drkm writes:

| James Kanze writes:

| > Il n'y a pas, formellement, une interdiction de surcharge.

| 7.4/6 :

| At most one function with a particular name can have C language
| linkage.

oui, mais tu peux surcharger sur le linkage. Sic.


Je la connaissais pas, celle-là. Comment se passe la résolution de
surcharge ?

--drkm

Avatar
James Kanze
drkm writes:

|> [ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]

|> Gabriel Dos Reis writes:

|> > drkm writes:

|> > | James Kanze writes:

|> > | > Il n'y a pas, formellement, une interdiction de surcharge.

|> > | 7.4/6 :

|> > | At most one function with a particular name can have C
|> > | language linkage.

|> > oui, mais tu peux surcharger sur le linkage. Sic.

|> Je la connaissais pas, celle-là. Comment se passe la résolution de
|> surcharge ?

En fait, je pensais plutôt au fait que tu peux surcharger une fonction
extern "C" avec d'autres fonctions extern "C". Mais le surcharge sur le
linkage marche aussi, comme n'importe quel autre surcharge. (Comme j'ai
dit dans le thread, extern "C" joue sur les types.) Même, il y en a des
cas dans la norme, comme atexit.

Mais pour le petit exemple :

typedef void (*pfCpp)( void * ) ;
extern void f( void* ) ;
extern "C" {
typedef void (*pfC)( void * ) ;
extern void g( void* ) ;
}

void h( pfCpp ) ; // #1
void h( pfC ) ; // #2

h( f ) ; // appelle #1
h( g ) ; // appelle #2

Exactement comme n'importe quel autre surcharge, en fait.

--
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
James Kanze
Gabriel Dos Reis writes:

|> drkm writes:

|> | 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 ?

|> Tu peux aussi surcharger selon le linkage :

|> extern "C" double abs(double); // #1
|> double abs(double); // #2, surcharge de #1

Et comment est-ce qu'on résoud le surcharge, quand j'appelle abs( 3.14 ) ?

--
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
6 7 8 9 10