Newsgroup: it.comp.lang.c
Titolo: Perchè questo progr. non conta i caratteri?

#include <stdio.h>
main()
{
        long nc ;
        nc = 0 ;
        while(getchar()!=EOF)
        ++nc ;
        printf("%ld\n", nc);
return;
}

 wrote in message
89oegf$mlm$1...@lacerta.tiscalinet.it...


 #include <stdio.h>
[ snip ]
Mi pare funzioni senza problemi.
[root@fokhouse /tmp]# cat conta.c
#include <stdio.h>
int main(void)
{
        long nc = 0L;
        while (getchar() != EOF)
                ++nc;
        printf("%ld\n", nc);
        return 0;
}
[root@fokhouse /tmp]# ./conta <conta.c
123
[root@fokhouse /tmp]# wc -c conta.c
    123 conta.c
[root@fokhouse /tmp]#
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

 wrote in message
89ohsd$17k$1...@fokhouse.iol.it...


Non so che dirti Francesco anche a me funziona benissimo !!
il programma
ahh ciao mi chiamo Marko !

ho dato un'aggiustatina ....... mi č venuto fuori questo qua, che conta i
caratteri ma oltre a mettere il numero finale mette anche i precedenti. x
esempio, se la parola č "ciao" sul video appare 0 1 2 3 4, mentre io vorrei
che comparisse solo il 4 finale..... uff.....
francesco
#include <stdio.h>
main()
{
        double nc;
        for(nc=0; getchar()!=EOF; ++nc)
      {
        ;
        printf("%.0f\n",nc);
      }
return;
}

dal sito Borland.
L'ho appena compilato (con il Turbo C++ 3.0) e funziona senza
problemi. Se nella while fai il confronto con '\n' allora la printf
viene eseguita non appena premi return. Se invece lasci EOF come avevi
messo tu puoi scrivere quante righe vuoi e quando premerai Ctrl-Z
(EOF) vedrai quanti caratteri hai battuto.
#include <stdio.h>
int main(void)
	{
	long nc ;
	nc = 0 ;
	while(getchar()!='\n')
	++nc ;
	printf("%ld\n", nc);
	return 0;
	}
ciao

e poi sostituisci EOF con '\n'
niente affatto : deve contare i caratteri in input.
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------

che comparisse solo il 4 finale..... uff.....
Il programma cosi' com'era andava benissimo.
Prova a compilare il tuo programma conta.c in conta.exe e a dargli in
input un file di testo :
conta.exe < input.txt


 
--
 Ciao, Luca.
 Reply to 
luca....@tiscalinet.it

 La presenza di "return" e' irrilevante.
Però il DJGPP compilando questo:
main()
{
}
dà i seguenti warnings:
MAIN.c:2: warning: return-type defaults to `int'
MAIN.c: In function `main':
MAIN.c:3: warning: control reaches end of non-void function
e meno warnings ci sono in un programma, meglio è, non sei d'accordo?
EMG

e meno warnings ci sono in un programma, meglio č, non sei d'accordo?
Che cosa c'entra ?
In C quando si scrive il nome di una funzione senza tipo, si assume
che il tipo sia "int". Il DJGPP ti da' quei warning perche' gli hai
espressamente indicato di farlo.
Prova a compilare senza -Wall -pedantic e -ansi.


Il linguaggio C permette tante cose, non necessariamente buone. Aggiungere 
"int" e "return 0;" rende il codice piu' leggibile, elimina i warning a 
prescindere dalle opzioni del compilatore e rende la funzione piu' portabile 
in vista, per esempio, di un passaggio al C++.

in vista, per esempio, di un passaggio al C++.
Ancora una volta ribadisco che qui dentro non si parla di C++, ma di
C. Se e' per questo il codice C NON e' pienamente portabile verso C++,
a prescindere da qualsiasi aggiustamento si voglia fare.
Secondo il mio parere, l'aggiunta di int e return 0 non rende affatto
il codice "piu' leggibile", ma semplicemente aggiunge delle note non
strettamente necessarie.
EMG confonde la presenza di warning che spuntano per probabili errori
nel codice (quelli che non dovrebbero esserci mai) con quelli che
spuntano fuori come suggerimento "stilistico", solo perche' si e'
detto al compilatore di volerli vedere.


EMG se vuole rispondera' da solo ma di sicuro se c'e' qualcuno confuso non e' 
lui.

lui.
Siamo in tre : non lo sono neanch'io, quindi ?

 delle note non strettamente necessarie.
  Cosa ti aspetti che ritorni main() se non lo specifichi con
l'istruzione /return/?
	Alla prossima,
		Marco


Allora resto solo io, che fregatura... :-)

 Prova a compilare senza -Wall -pedantic e -ansi.
Mi sembra che la tua cura sia molto peggiore della malattia. Invece di
togliere completamente tutti i warnings non č meglio fare la pochissima
fatica necessaria a scrivere int main()?
EMG

 La presenza di "return" e' irrilevante.
?????? come sarebbe??? e' da quando leggo il ng che sento dire che
main e' dichiarata in due modi: int main(void) e int main(int argc,
char** argv) e tu mi dici che main() e' uguale a int main() ?!?! e che
return e' irrilevante ?!?!?! 
vabbe' che siamo a carnevale, ma non esageriamo...


fatica necessaria a scrivere int main()?
Il problema e' a monte.
E' la diagnosi che e' peggiore della malattia.
I warning non vengono generati per delle inesattezze logiche del
programma, ma a solo titolo stilistico.
Se si fa presente qualcosa a chi scrive del codice come quello che e'
stato scritto con "guarda che qui ci vuole int main() e return 0", si
puo' pensare che questo sia un suggerimento per "correggere" il
codice. Mentre cosi' non e' : il codice funziona benissimo.
In quanto ai warning, sai benissimo che e' come se il compilatore ti
dicesse : "ok, so che non dovrei farlo, ma te lo dico lo stesso : qui
ci andrebbe un bel "int" e dopo un bel "return qualcosa".
Ovvio che non ti dice che non sono indispensabili, ma e' chiaro che e'
cosi'.

l'istruzione /return/?
La presenza o meno di un valore di ritorno esplicito e' irrilevante.
L'importante e' che main() sia definita come funzione che restituisce
un intero.
Per questo scopo, basta definirla come :
int main()
o 
main()
equivalenti.

return e' irrilevante ?!?!?! 
Vediamo di calmarci.
main() non e' dichiarata in due modi !
main() puo' essere dichiarata come :
main()
main( void )
equivalenti a :
int main()
int main( void )
e
main( int, char ** )
equivalente a :
int main( int, char ** )
La presenza o meno di return e' IRRILEVANTE !
L'importante e' che il valore di ritorno sia un intero.
Vabbe' che siamo in un ng sul C, ma sapere i fondamenti non sarebbe
male.

 codice. Mentre cosi' non e' : il codice funziona benissimo.
_Potrebbe_ funzionare benissimo ma nessuno ti assicura che lo faccia. Se
il tuo compilatore asseconda le tue idiosincrasie e inserisce di suo sia
l'int prima di main() e sia il return 0 allora tutto va bene ma se non
lo fa...
EMG

 L'importante e' che il valore di ritorno sia un intero.
Non so cosa intendi per irrilevante, ma resta il fatto che se non viene
messa l'istruzione return penso che il djgpp ritorni arbitrariamente il
contenuto del registro AX.
Se non ti interessa esplicitamente il valore di ritorno puoi dire che per te
e' irrilevante, ma comunque non si ottengono gli stessi effetti.
--
________________________________
Togliete NoSpaM per rispondermi
bye Brain

lo fa...
A parte il fatto che queste non sono idiosincrasie.
Ma stiamo scherzando ? Ti ripeto che il C, non il mio compilatore,
asserisce che quando una funzione manca del tipo (perche' non scritto,
non perche' non ne abbia, nel qual caso e' void) il tipo restituito e'
int. La presenza o meno di return, come citato nelle faq, e'
irrilevante ai fini della correttezza del codice.
Se il programmatore omette sia l'int che il return non commette alcun
errore, ne' rischia alcunche'.

 restituisce un intero.
  Niente affatto: main() deve ritornare comunque un valore intero
significativo, almeno -- se non sei attaccato ai formalismi -- per il
motivo (2) suindicato. Singificativo, dunque, per lo stato di
terminazione del programma.
	Alla prossima,
		Marco

terminazione del programma.
Ma stiamo scherzando ?
La mancanza di un valore di ritorno (intesa come omissione del return
e non come definizione di main come "void" che potrebbe essere un
errore) non e' affatto un errore.

e' irrilevante, ma comunque non si ottengono gli stessi effetti.
Ti ricordo di cosa si parla nel thread.
EMG afferma (sbagliando) che se si omette "int" come valore di ritorno
di main() e "return" il programma : "_Potrebbe_ funzionare benissimo
ma nessuno ti assicura che lo faccia.".
QUESTO NON E' AFFATTO VERO !
Il programma funziona, comunque, benissimo.
La presenza di int e di return e' IRRILEVANTE ai fini del
funzionamento del programma.
I problemi concernenti l'uso del valore di ritorno di main() sono al
di fuori di quanto si sta discutendo.

 valore non si tramuta in obbligo !!
  Una frase del genere implica che, in futuro, dovro` evitare qualsiasi
programma scritto da te! :)
  Un programma e` un prodotto industriale come tutti gli altri, spesso
avra` requisiti espliciti, altrettanto spesso ne avra` di impliciti. Se
scrivi un programma per certe piattaforme, per esempio UNIX, tutti,
dagli utenti al sistema operativo, si aspetteranno che ritorni un valore
intero che descriva il suo stato di terminazione. Altrimenti, non sara`
un buon programma, anche se il compilatore non ha dato errori.
	Alla prossima,
		Marco

un buon programma, anche se il compilatore non ha dato errori.
VEDI SOPRA !
Non stiamo parlando di questo.

 di fuori di quanto si sta discutendo.
Quanto dici dimostra che ho ragione. Quando scrivi un programma non puoi
prevederne tutti i possibili utilizzi. Se il chiamante (magari il
sistema operativo stesso) si aspetta un valore zero da un programma che
termina correttamente (e mi sembra che in alcuni casi succeda qualcosa
di simile), un valore casuale non avrebbe la stessa semantica
all'interno del sistema formato da applicazione/ambiente. Quello che
accade normalmente è, invece, che il compilatore si preoccupa di mettere
il return 0 da te "dimenticato". Ma questo "aiuto" da parte del
compilatore non significa che una pratica del genere sia corretta.
EMG

 Probabilmente li hai gia' usati.
  ROFLASTC!
	Alla prossima,
		Marco

compilatore come errore.
Precisione : la conferma di non aver scritto nulla di errato.

compilatore non significa che una pratica del genere sia corretta.
Lo standard non afferma affatto che i compilatori devono restituire 0
in automatico, se il programmatore lo omette il valore di ritorno.
Non credo che il compilatore "aiuti" in questo senso.

 non costituiscono un errore del codice.
  Bravo, hai centrato il punto: un codice puo` essere malfunzionante
anche senza che il compilatore segnali errori. Per cui, se qualcuno ha
problemi con codice malfunzionante, e` bene segnalargli subito alcune
tra le piu` probabili cause di malfunzionamento, non ultima la mancanza
di coerenza tra cio` che si dichiara e cio` che si definisce.
  Vedi che avevi capito? Sapevo che facevi finta del contrario solo per
divertirci...
	Alla prossima,
		Marco

divertirci...
Ho capito il C da tanto tempo, a differenza di altri, infatti ho
affermato che la mancanza di int e di return 0 non costituiscono un
errore del codice, ne' provocano malfunzionamenti.

 ignori il valore di ritorno.
...oppure stai scrivendo codice non efficiente. In entrambi casi, e` un
errore. Puoi metterla come ti pare ma programmare non significa solo
scrivere codice. Questo pare non ti sia chiaro e te l'ho segnalato fin
dall'inizio della discussione.
	Alla prossima,
		Marco

dall'inizio della discussione.
Io conosco la programmazione fin dentro le radici e non ho voglia di
continuare a discutere con chi si ostina a non capire (neanche a non
VOLERLO fare) che il problema di cui si sta parlando non e' lo stile
di programmazione.
Qui dentro si sta parlando delle correzioni che vengono compiute sul
codice.
Se si e' convinti che scrivere main() sia diverso da scrivere int
main() o che il valore di ritorno di main() abbia un'importanza ai
fini della correttezza di funzionamento del programma, si e' convinti
di un'enorme sciocchezza e si farebbe bene a studiarsi da zero un buon
manuale sul C.

 da zero un buon manuale sul C.
  Tu non hai nemmeno la piu` pallida idea di che cosa sia la
programmazione ed i tuoi interventi lo dimostrano. Tu lo *vorresti*
sapere, ma non lo sai, perche` sei un wannabe, un "vorrei essere".
  Frequento i gruppi di discussione da un bel po' di tempo e so
riconoscere il tipo: prima di sostenere all'infinito un punto contestato
in un'area a lettura pubblica, ovvero dove tutti possono leggere,
dovresti controllare tutto fino ai minimi particolari. 
  Non lo fai, continui a basare il sostegno alla tua idea sul ripetersi
di un cavillo nonostante ti sia stato fatto notare che non e` risolutivo
ai fini della discussione: sei un wannabe. Almeno, pero`, cerca di non
dare consigli prosopopaici: da buon wannabe sparirai presto da questo
gruppo cosi` come sei comparso, rendici la tua permanenza il meno
sgradevole possibile.
	Alla prossima,
		Marco

 Non credo che il compilatore "aiuti" in questo senso.
Se non aiuta allora tanto peggio. Comunque scrivere una tantum int
main() e return 0 non mi sembra una grossa fatica, non ti pare? Pensa se
utilizzassi il Cobol e fossi costretto a scrivere IDENTIFICATION
DIVISION e tutta quella roba che viene appresso... :-)
EMG

Cito testualmente passaggi tratti dal K&R sperando di chiarire tutto...
...a pag. 28
"Di solito, un valore di ritorno (del main) nullo indica un corretto
comportamneto; valori diversi da zero segnalano la presenza di condizioni di
terminazione eccezzionali o scorrette"
...a pag.87
"Se viene ommesso il tipo del valore di ritorno, esso viene considerato
automaticamente un int"
....
"L'istruzione return è il meccanismo che consente alla funzione chiamata di
restituire un valore al chiamante"
....
"Un caso in cui il chiamante riprende il controllo dell'esecuzione, senza
che gli venga passato alcun valore di ritorno, è quello in cui l'esecuzione
della funzione chiamata termina per il raggiungimento della parentesi graffa
di chiusura. Questa situazione non è illegale ma, in genere, il fatto che
una funzione in un punto ritorno un valore e in un altro punto non ritorni
nulla, è indice di una situazione anomala. In ogni caso se, per un qualunque
motivo, una funzione non riesce a restituire il proprio valore, ciò che il
chiamante riceve è un valore *sporco*" (nb. il valore sporco è il contenuto
di AX su macchine x86)
....
"Il valore restituito dal main viene messo a disposizione dell'ambiente che
ha eseguito il programma"
...a pag. 90
"E' comunque bene evitare di usare questa sintassi (nb. tipo nomefunz (); )
all'interno dei nuovi programmi. Se la funzione richiede degli argomenti
dichiarateli; se non ne richiede, usate il tipo void"
Ne risulta che:
1)
main(void);
 viene considerato automaticamente
int main(void);
...qui siamo tutti daccordo
2)
E' bene usare usare la sintassi
main(void);
invece che
main();
con o senza int davanti. La seconda sintassi era usata dai vecchi programmi
C ed è pertanto ancora riconosciuta dai compilatori, ma non è bene usarla.
3)
Se il main termina per essere arrivato alla perantasi graffa :
a) se in altri punti del codice non viene mai usato exit(espressione) o in
altri punti del main return(espressione) il sistema riceve un valore di
ritorno *sporco*... ma non c'è niente di sbagliato, si intende che il valore
ritornato dal programma non ha significato. (ma come fa il SO a saperlo?)
b) se in altri punti del codice viene usato exit(espressione) o in altri
punti del main return(espressione) il sistema riceve comunque un valore di
ritorno *sporco*... ma la situazione è definita "anomala".
In tutti gli ambienti *di solito* si usa la convenzione del valore di
ritorno nullo in caso di corretto funzionamento e quindi vale la 3b)
--
________________________________
per rispondermi iliasba(at)
tin.it
bye Brain

 manuale sul C.
Scrivere main() invece di int main() è solo una bruttura stilistica,
d'accordo (anche se magari tu non sarai d'accordo sulla "bruttura"), ma
omettere il return significa lasciare al caso il valore restituito al
sistema operativo e questa mi sembra sia una differenza oggettiva
rispetto allo scrivere return 0.
EMG