2013-01-21 13 views
5

questo esempio è dalla K & R libroPerché getchar() riconosce EOF solo all'inizio di una riga?

#include<stdio.h> 


main() 
{ 
    long nc; 

    nc = 0; 
    while(getchar() != EOF) 
     ++nc; 
    printf("%ld\n", nc); 
} 

enter image description here

Mi può spiegare perché funziona in questo modo. Grazie.

^Z^Z non funziona o (meno che non sia l'inizio di una riga)

enter image description here

interpretazione
+0

Impossibile vedere l'esempio .. Puoi pubblicare il codice qui? –

+4

Questa è una "funzionalità" della shell di Windows. Su Unix, puoi digitare EOF alla fine di una riga digitando Ctrl + D due volte; prova a digitare Ctrl + Z due volte. (Oppure reindirizzare l'input da un file.) –

+0

digitando Ctrl + Z due o più non funziona comunque – Vorgin

risposta

0

tradizionale UNIX di tty EOF carattere è quello di rendere il blocco read ritorno dopo aver letto tutto ciò che è tamponata all'interno di un buffer tty line cotto. All'inizio di una nuova riga, significa read restituendo 0 (lettura zero byte) e, incidentalmente, 0 dimensioni read è il modo in cui viene rilevata la condizione di fine file su file ordinari.

Ecco perché la prima EOF nel bel mezzo di una linea costringe solo l'inizio della linea da read, non facendo libreria di runtime C rileva un fine del file. DueEOF caratteri in una riga producono una lettura di 0, poiché la seconda forza un buffer vuoto da read da un'applicazione.

$ cat 
foo[press ^D]foo <=== after ^D, input printed back before EOL, despite cooked mode. No EOF detected 
foo[press ^D]foo[press ^D] <=== after first ^D, input printed back, and on second ^D, cat detects EOF 

$ cat 
Some first line<CR> <=== input 
Some first line <=== the line is read and printed 
[press ^D] <=== at line start, ^D forces 0-sized read to happen, cat detects EOF 

Presumo che la vostra libreria di runtime C imita la semantica sopra descritte (non v'è alcun trattamento speciale della ^Z a livello di kernel32 chiamate, lasciare che le chiamate di sistema da solo, su Windows). Ecco perché probabilmente rileverebbe EOF dopo lo ^Z^Z anche nel mezzo di una linea di input.

+0

No, non lo sarebbe.^Z^Z o più non funziona se prima ci sono altri personaggi in questa linea. – Vorgin

0

Il programma leggerà EOF solo alla fine effettiva dell'input. Se il tuo terminale/sistema operativo/qualunque sia il permesso di terminare i file all'inizio di una riga, allora è lì che li troverai. Credo che questo sia un ritorno ai vecchi terminali in cui i dati venivano trasmessi solo una linea alla volta (per quanto ne so, si tratta di lettori di schede perforate).

Prova a leggere i dati da un file che hai preparato con una linea intermedia EOF. Potresti anche scoprire che alcuni editori lo rendono difficile! Il tuo programma dovrebbe funzionare bene come input.

0

EOF indica "fine del file". Una nuova riga (che è ciò che accade quando si preme invio) non è la fine di un file, è la fine di una riga, quindi una nuova riga non termina questo ciclo.

A seconda del sistema operativo, il carattere EOF funziona solo se è il primo carattere di una riga, ovvero il primo carattere dopo uno . Poiché l'input della console è spesso orientato alla linea, il sistema potrebbe anche non riconoscere il carattere EOF fino a quando non lo si è seguito con uno .

0

Mi è capitato di avere la stessa domanda come te. Quando voglio terminare la funzione getchar(), devo inserire 2 EOF o inserire un <ENTER> più uno EOF.

E qui è una risposta facile Ho cercato su questa questione:

Se c'è personaggi che entrano nel terminale, EOF interpreterà il ruolo di fermare questo ingresso, che non mancherà di suscitare un nuovo turno di entrare; mentre, se non vi è alcuna immissione in corso o in un'altra parola, quando il getchar() è in attesa di una nuova immissione (come se hai appena finito di entrare o un EOF), l'EOF che stai per inserire ora è uguale a "fine" di file ", che porterà il programma a interrompere l'esecuzione della funzione getchar().

PS: la domanda si verifica quando si utilizza getchar(). Penso che questa risposta sia più facile da capire, ma forse non per te dal momento che è tradotta dal cinese ...

Problemi correlati