[C] errore inspiegabile?

[Torav]

aiutoooooooooooo :help:

non so assolutamente come risolvere questo problema..questo pezzo di codice NON mi funziona:

char newExp[256];
char yon = 'n';
int i;

while(yon == 'n') {
printf("Nuova espressione corrente:\n");
//scanf("%s", newExp);
fgets(newExp, 256, stdin);
//gets(newExp);
printf("La nuova espressione corrente e':\n%s\nVuoi mantenerla?", newExp);
yon = getc(stdin);
}
for(i = 0; i < 256; i++) {
currentExp[i] = newExp[i];
}

ho commentato scanf e gets perchè ho provato ad usare anche loro ma con scarsi risultati (nonostante la mia intenzione di utilizzare solo fgets).
in pratica a run time non mi dà la possibilità di inserire la nuova espressione..come se saltasse quell'istruzione...probabilmente sarà un bug idiota ma io non ho la minima idea di cosa fare!! aiut :mc:

[Ziosilvio]

Quando scrivi sullo standard input che non vuoi tenere l'espressione inserita, inserisci prima un carattere 'n', e poi un newline.
Dopo la chiamata a getc, il newline rimane nel buffer: ed è quel newline, che viene letto da fgetc e interpretato come una riga in cui c'è solo l'andata a capo.
Per risolvere questo problema, devi togliere i caratteri dopo 'n' (o 's'); ad esempio con:
while (getc(stdin) != '\n')
;

[VegetaSSJ5]

Ziosilvio man getc mi dice questo

fgetc() reads the next character from stream and returns it as an unsigned char cast to an int, or EOF on end of file or error.

getc() is equivalent to fgetc() except that it may be implemented as a macro which evaluates stream more than once.

non riesco a capire la differenza tra getc e fgetc... :confused:

[Torav]

Quando scrivi sullo standard input che non vuoi tenere l'espressione inserita, inserisci prima un carattere 'n', e poi un newline.
Dopo la chiamata a getc, il newline rimane nel buffer: ed è quel newline, che viene letto da fgetc e interpretato come una riga in cui c'è solo l'andata a capo.
Per risolvere questo problema, devi togliere i caratteri dopo 'n' (o 's'); ad esempio con:
while (getc(stdin) != '\n')
;

ma certo!non ci sarei mai arrivato da solo, grazie mille :)

[Ziosilvio]

non riesco a capire la differenza tra getc e fgetc
Tanto getc quanto fgetc prendono in input un puntatore a FILE, e restituiscono il carattere successivo a quelli letti finora come unsigned char convertito a int, oppure EOF se non ci sono più caratteri da leggere.
La differenza è che fgetc è sempre implementata come funzione, mentre getc potrebbe essere implementata anche come macro: in questo caso, lo standard non richiede che getc valuti il suo argomento una volta sola.
Un esempio di come questo possa avvenire si trova nella sezione 8.5 del K&R, e mi permetto di riportarlo qui:
#define getc(p) (--(p)->cnt >= 0 ? (unsigned char) \
*(p)->ptr++ : _fillbuf(p))
dove p->cnt è il numero di caratteri rimasti, e p->ptr è la posizione del carattere successivo. Nota che getc, in questa implementazione, valuta il proprio argomento sempre due volte.
Ricapitolando, tu hai la scelta tra fgetc, che garantisce una maggiore robustezza agli effetti collaterali; e getc, che potrebbe offrire una velocità maggiore.

[VegetaSSJ5]

ok ho capito. :)
ma gli effetti collaterali che si potrebbero avere nell'utilizzo della getc si avrebbero nel caso in cui l'argomento (p) cambi il proprio valore tra la prima e la seconda valutazione (nel caso in cui getc è implementato come macro e con più alutazioni dell'argomento, come hai scritto tu), ma questa sarebbe comunque una possibilità remota giusto? e inoltre come si farebbe a far cambiar valore al file descriptor passato per argomento?
grazie Ziosilvio, sempre puntuale e impeccabile.

[beppegrillo]

Quando scrivi sullo standard input che non vuoi tenere l'espressione inserita, inserisci prima un carattere 'n', e poi un newline.
Dopo la chiamata a getc, il newline rimane nel buffer: ed è quel newline, che viene letto da fgetc e interpretato come una riga in cui c'è solo l'andata a capo.
Per risolvere questo problema, devi togliere i caratteri dopo 'n' (o 's'); ad esempio con:
while (getc(stdin) != '\n')
;
si potrebbe risolvere effettuando un flush del buffer?

[Ziosilvio]

ma gli effetti collaterali che si potrebbero avere nell'utilizzo della getc si avrebbero nel caso in cui l'argomento (p) cambi il proprio valore tra la prima e la seconda valutazione (nel caso in cui getc è implementato come macro e con più alutazioni dell'argomento, come hai scritto tu), ma questa sarebbe comunque una possibilità remota giusto? e inoltre come si farebbe a far cambiar valore al file descriptor passato per argomento?
Il file descriptor è un puntatore a una struttura: per cui, gli effetti collaterali possono riguardare sia lui, che i campi della struttura puntata.
Inoltre, l'evento che p cambi da un punto all'altro di getc, è improbabile se p è un descrittore "unico" come stdin; ma vedi da te che le cose possono essere diverse se è un elemento di un array di descrittori di file.
Ossia: in linea di principio è possibile scrivere monnezze tipo:
FILE *inputs[10];
/* bla bla bla */
i = getc(inputs[++j]);
e in questo caso, se j vale 3 al momento della chiamata, il test su ++(p)->cnt viene fatto per p uguale a inputs[4], mentre il prelievo del carattere viene fatto per p uguale a inputs[5].

[Ziosilvio]

si potrebbe risolvere effettuando un flush del buffer?
Uno, due, tre...


... venticinque, ventisei, ventisette...


... ottantadue, ottantatre, ottantaquattro...


... novantanove, CENTO! OK, sono calmo, posso rispondere.


Come io stesso e altri abbiamo già spiegato un nutrito numero di volte, e come è detto in uno dei thread in prima pagina oggi in risposta a un quesito simile, lo standard non definisce il comportamento di fflush su uno stream di input.
Per cui, anche se molti compilatori accettano l'espressione fflush(stdin) e la interpretano come un'eliminazione dei caratteri rimasti sullo standard input, chiamare fflush su uno stream di input non è né standard né portabile, e lo si fa a proprio rischio e pericolo.

[beppegrillo]

Uno, due, tre...


... venticinque, ventisei, ventisette...


... ottantadue, ottantatre, ottantaquattro...


... novantanove, CENTO! OK, sono calmo, posso rispondere.


Come io stesso e altri abbiamo già spiegato un nutrito numero di volte, e come è detto in uno dei thread in prima pagina oggi in risposta a un quesito simile, lo standard non definisce il comportamento di fflush su uno stream di input.
Per cui, anche se molti compilatori accettano l'espressione fflush(stdin) e la interpretano come un'eliminazione dei caratteri rimasti sullo standard input, chiamare fflush su uno stream di input non è né standard né portabile, e lo si fa a proprio rischio e pericolo.
:D
Appena visto il thread a cui ti riferivi, grazie della risposta.

[VegetaSSJ5]

Uno, due, tre...


... venticinque, ventisei, ventisette...


... ottantadue, ottantatre, ottantaquattro...


... novantanove, CENTO!
glade soffi! :asd: