Newsgroup: it.comp.lang.c++
Titolo: Problemi con EOF

Allora, ho il seguente problema con in conteggio di parole:
#include <iostream.h>
#include <stdio.h>
void main()
{
    char c;
    for(int nc = 0; (c=getchar()) != EOF; nc++)
        ;
    cout << nc;
}
Ora il problema è che il compilatore non mi da errore, ma mandando in
esecuzione il programma non mi vusualizza sul monitor il valore della
variabile nc. Ho provato a mettere al posto di EOF il carattere '\0', e
tutto funziona correttamente. Come mai??

elimina il ; tra for e cout (vedi sintassi di for).
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

 tutto funziona correttamente. Come mai??
Devi in qualche modo produrre il carattere EOF dalla tastiera alla fine
della digitazione. In DOS, ad esempio, si ottiene premendo CTRL-Z.
EMG


Senti, prova con  int getc(FILE *stream);
quella li ti restituisce un intero, perche EOF in realta non è un char ma un
int, percio se tu lo misuri come char ti puo capitare di fare un errore....
Ciao by Tdx

 wrote in message
37dcf7da...@proxy.cli.di.unipi.it...


 elimina il ; tra for e cout (vedi sintassi di for).
Ehm, forse non hai capito cosa voleva ottenere: la stampa, alla fine,
del numero di caratteri letti. Se č cosě allora il punto e virgola sta
bene dove sta.
EMG

bene dove sta.
In tal caso c'e` comunque un errore, nc e` (dovrebbe essere) 
una variabile locale al ciclo for e dunque non visibile dopo
lo statement del for.
Questo se non ricordo male lo standard!


che ogni volta legge ctrl-z e poi ricomincia????
Correggendo l'errore relativo alla variabile nc, per esclusione
il problema e` EOF... Quanto vale EOF o meglio di che tipo e`?
Se EOF e` int (come presumo) non puoi fare il confronto tra un int
e il valore di un char convertito a int.
Dato che getchar() ritorna un intero dichiara c di tipo int anzicche`
char


Questo se non ricordo male lo standard!
Direi che il compilatore che sta usando (microsoft, giusto?) non e' conforme,
se no avrebbe avuto un errore di compilazione. Il problema sta solo
nel non aver dichiarato c come int.

 lo statement del for.
Piů che giusto! Hai ragione.
EMG

 Il problema sta solo nel non aver dichiarato c come int.
E' vero che c andrebbe dichiarato int ma è anche vero che se lo dichiaro
char e se il char è per default signed allora tutto funziona ugualmente
a patto di non immettere caratteri con codice superiore al 127 o
comunque al massimo rappresentabile con un signed char.
EMG

}
Stai confrontando un char con un int (EOF). Prova a dichiarare c come int.
Ciao, Giuseppe
---------------------------------------------------------------------------
_Guybrush su IRCNet canale #programmazione
ICQ: 42227764
---------------------------------------------------------------------------

comunque al massimo rappresentabile con un signed char.
Il punto (credo) che nella conversione da int a char di EOF (quando
questo viene restituito da getchar) c'e` perdita di informazione, nel
confronto pero` il comportamento del compilatore e` quello di promuovere
entrambi i membri ad un tipo comune, ovvero riconvertire c da char a 
int... il valore che cosi` si ottiene pero` non e` piu` EOF...
in sostanza (int)((char)EOF) != EOF


nel non aver dichiarato c come int.
NI... nel senso che hai ragione ritenendo il codice non standard, se 
pero` vogliamo fare le cose per benino...
Ad ogni modo avevo frainteso gli obiettivi del programma...


comunque al massimo rappresentabile con un signed char.
Si', ma questo in genere significa andare in cerca di guai...

 in sostanza (int)((char)EOF) != EOF
Questo perň vale solo se EOF non č esprimibile nel tipo char (signed).
Se, come normalmente č, EOF vale -1 la conversione non dovrebbe causare
alcun problema, o sbaglio?
EMG

 Si', ma questo in genere significa andare in cerca di guai...
Sono d'accordo. :-)
EMG

  
PGP 2.6.3i key available
--------------------

 ha scritto:
:> In tal caso c'e` comunque un errore, nc e` (dovrebbe essere) 
:> una variabile locale al ciclo for e dunque non visibile dopo
:> lo statement del for.
:> Questo se non ricordo male lo standard!
Le cose stanno esattamente come dici tu, tuttavia questa regola di scoping è cambiata dalle vecchie edizioni dello standard.
Per questo il gcc compila normalmente quel programma, ma con l'opzione -pedantic-errors si rifiuta.


 ha scritto:
:> E' vero che c andrebbe dichiarato int ma è anche vero che se lo dichiaro
:> char e se il char è per default signed allora tutto funziona ugualmente
:> a patto di non immettere caratteri con codice superiore al 127 o
:> comunque al massimo rappresentabile con un signed char.
Il problema è che EOF è un intero non rappresentabile con un signed char (0xFFFF o 0xFFFFFFFF).


 Il problema è che EOF è un intero non rappresentabile con un signed char (0xFFFF o 0xFFFFFFFF).
Premetto che (come ho già detto) sono d'accordo con voi che c vada
dichiarato int. Però in senso esclusivamente pratico mi sembra che EOF
(almeno sul DJGPP e sul TurboC++ 1.01) venga definito come
#define EOF (-1)
senza quindi alcuna indicazione sul tipo che potrebbe benissimo essere
signed char. Sbaglio?
EMG

signed char. Sbaglio?
Se non erro il default per le costanti intere e` int...


 ha scritto:
:> #define EOF (-1)
:> senza quindi alcuna indicazione sul tipo che potrebbe benissimo essere
:> signed char. Sbaglio?
mmm... le costanti numeriche sono int. Almeno così dice il Kernigan & Ritchie, al capitolo 2.3 (non voglio fare il dotto, è un caso che ce l'abbia davanti :-))


 Se non erro il default per le costanti intere e` int...
Anche questo è vero. Però scusa: se io scrivessi
char c = -1;
non ci troveresti niente da dire, giusto? Allora cosa mai può esserci di
male in
#define EOF (-1)
char c = EOF;
Forse il problema si manifesta solo in un confronto? Scusami se insisto
ma non riesco a vedere il nocciolo esatto della questione.
EMG


A me sembra che sia vero che se EOF vale -1 il tutto funziona, pero`
non credo che lo standard garantisca che quello (-1) sia il valore di
EOF per cui i problemi che potrebbero aversi sono i soliti che
si hanno quando non si segue lo standard (l'assunzione
"EOF vale -1" non rispetta lo standard).
Marco Guidi.
 

In effetti hai completamente ragione...
Pero` a questo punto perche` il codice non funzionava?
C'e` per caso qualcuno che lo ha provato con successo?


 "EOF vale -1" non rispetta lo standard).
Hai perfettamente ragione. Se, ad esempio, EOF fosse definito come
#define EOF (256)
la cosa non funzionerebbe piů.
EMG

 C'e` per caso qualcuno che lo ha provato con successo?
A me funzionava. Ma ora non ricordo più se avevo trovato qualche errore.
Bisognerebbe rileggere i vecchi messaggi.
EMG