scrittura temporizzata
Antonio Macchi
lentamente, non scrive niente?
e come posso fare per risolvere?
------------
#include <stdio.h>
#include <time.h>
int main() {
clock_t tempo;
while(1) {
printf("*");
tempo = clock();
while(clock() < (tempo + 1000000))
;
}
return 0;
}
-------------
se invece di scrivere "*", scrivo "*\n" pero' funziona normalmente
eppure un modo ci deve essere, visto che, per dire, una riga in bash tipo:
$ while true; do echo -n "*"; sleep 1 ;done
funziona normalmente
Andrea Laforgia
> perche' questo programmino invecedi scrivere un asterisco dopo l'altro
> lentamente, non scrive niente?
Perch� lo standard I/O del C � line-buffered, quindi il sistema bufferizza
i caratteri che scrivi e li "flusha" al primo new-line. Per fare ci� che
vuoi fare � sempre meglio usare funzioni dipendenti dal sistema operativo
e che fanno accesso diretto all'hardware, bypassando l'I/O standard.
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Manlio Perillo
> Antonio Macchi ha scritto:
>
>> perche' questo programmino invecedi scrivere un asterisco dopo l'altro
>> lentamente, non scrive niente?
>
> Perché lo standard I/O del C è line-buffered, quindi il sistema
> bufferizza i caratteri che scrivi e li "flusha" al primo new-line. Per
> fare ciò che vuoi fare è sempre meglio usare funzioni dipendenti dal
> sistema operativo e che fanno accesso diretto all'hardware, bypassando
> l'I/O standard.
Non basta un semplice setvbuf?
http://www.opengroup.org/onlinepubs/009695399/functions/setvbuf.html
Ciao Manlio
Antonio Macchi
> http://www.opengroup.org/onlinepubs/009695399/functions/setvbuf.html
in pratica impostando il buffer a un byte?
e' possibile farlo anche (in linux) da shell?
Manlio Perillo
>> Non basta un semplice setvbuf?
>> http://www.opengroup.org/onlinepubs/009695399/functions/setvbuf.html
>
>
> in pratica impostando il buffer a un byte?
>
No, eliminando il buffering.
> e' possibile farlo anche (in linux) da shell?
No, perchè il buffering è associato al singolo stream C che crei, ed il
valore di default non viene prelevato a runtime (come ad esempio da una
variabile di ambiente) - almeno per quanto ne so.
Ciao Manlio
neonano
> perche' questo programmino invecedi scrivere un asterisco dopo l'altro
> lentamente, non scrive niente?
Già hanno risposto
Antonio Macchi wrote:
> e come posso fare per risolvere?
#include <stdio.h>
#include <unistd.h>
#include <time.h>
int main() {
clock_t tempo;
while(1) {
write(STDOUT_FILENO,"*",1);
neonano
> ... Per fare ciò che
> vuoi fare è sempre meglio usare funzioni dipendenti dal sistema operativo
> e che fanno accesso diretto all'hardware, bypassando l'I/O standard.
??? esistono funzioni C standard per l'input/output non bufferizzato.
fnegroni
Si,
setvbuf e setbuf (gia' menzionate da Manlio piu' su') sono standard
ISO C90.
In questo caso, basterebbe persiono un fflush().
Comunque in genere, se si vuole essere sicuri al 100% che cio' che
appare sullo schermo sia cio' che si vuole, come dice Andrea, e'
meglio usare delle routine piu' vicine all'hardware, o per meglio
dire, piu' vicine ai driver di sistema che gestiscono l'input/output
da console.
In questo caso per esempio, se su Linux, puoi usare la libreria
ncurses.
neonano
> On 6 Dec, 19:15, neonano <neon...@mi5.uk> wrote:
>>
>> ??? esistono funzioni C standard per l'input/output non bufferizzato.
>
> Si,
La mia era una affermazione non una domanda.
antoniomac5
> #include <unistd.h>
> #include <time.h>
>
> int main() {
> clock_t tempo;
> while(1) {
> write(STDOUT_FILENO,"*",1);
> tempo = clock();
> while(clock() < (tempo + 1000000));
> }
> return 0;
>
> }
perfetto, funziona!
e sivvede che "write" segue per scrivere una strada diversa... e
scavalca il buffer
grazie e ciao
neonano
Si a setvbuf, sì a ncurses (esistono anche per Windows
http://gnuwin32.sourceforge.net/packages/ncurses.htm)
no a fflush, no soluzioni dipendenti dal sistema operativo.
Su questo ultimo punto:
fnegroni wrote:
> ...
> meglio usare delle routine piu' vicine all'hardware, o per meglio
> dire, piu' vicine ai driver di sistema che gestiscono l'input/output
> da console.
Leggendo "più vicine all'hardware" e "accesso diretto" e "bypassando
l'I/O standard" mi sono subito venute in mente conio e gli infami
trucchetti che si usavano ai tempi del DOS. Inutile parlarne male.
Mi vengono i brividi.
Se però con "più vicine all'hardware" intendi cose come lseek, read
e write (che sono standard C) o PDcurses (che sono in parte
compatibili con le ncurses) od anche le ncurses stesse (che sono
portabili anche su Windows) allora non ci sono problemi.
Manlio Perillo
> [...]
> fnegroni wrote:
>> ...
>> meglio usare delle routine piu' vicine all'hardware, o per meglio dire,
>> piu' vicine ai driver di sistema che gestiscono l'input/output da
>> console.
>
> Leggendo "più vicine all'hardware" e "accesso diretto" e "bypassando
> l'I/O standard" mi sono subito venute in mente conio e gli infami
> trucchetti che si usavano ai tempi del DOS. Inutile parlarne male. Mi
> vengono i brividi.
Più vicine all'hardware significa usare un API che viene molto
probabilmente implementata direttamente nel kernel.
Questa API non è definita dallo standard C, ma da POSIX.
> [...]
Ciao Manlio