Newsgroup: it.comp.programmare.win32
Titolo: Problema privo di senso: kbhit()

Questo banalissimo codice, eseguito con il Borland C++ 5.0 prende in input
un numero, lo riscrive, prende in input un'altro numero lo riscrive quindi
attende che venga premuto un qualunque tasto prima di uscire.
#include <iostream.h>
#include <conio.h>
void main()
{
 int n;
 cin>>n;
 cout<<n<<endl;
 cin>>n;
 cout<<n;
 while(!kbhit());
}
Lo stesso identico algoritmo col Visual C++ preso da Visual Studio 6.0
prende in input un numero, lo riscrive, prende in input un altro numero,
attende che venga premuto un qualunque tasto, quindi scrive il numero preso
in input ed esce, esattamente come farebbe il Borland se il while fosse una
riga sopra, subito sotto il cin.
Per quale <assurdo> motivo, secondo voi?
Non sarò un genio di C++ ma faccio algoritmi (in Pascal Delphi e Visual
Basic) da 4 anni e lo stesso algoritmo <dovrebbe> fare la stessa cosa con
tutti i compilatori, o no?

  cout<<n<<endl;
---------------^-----
Se aggiungi endl all'ultimo cout consenti la scrittura del numero.
Ciao

 writes:
N> Per quale <assurdo> motivo, secondo voi?
N> Non sarò un genio di C++ ma faccio algoritmi (in Pascal Delphi e Visual
N> Basic) da 4 anni e lo stesso algoritmo <dovrebbe> fare la stessa cosa con
N> tutti i compilatori, o no?
Gli algoritmi sono qualcosa di astratto indipendente dal linguaggio con
cui si implementano. E no, non è detto che tutti i compilatori abbiano la
stessa semantica su cose dipendenti dal sistema (conio.h).
Niente di più probabile che il buffered I/O del VC++ agisca così:
\begin{nellaTestaDelRuntime}
Leggo un  numero 
Metto  nel buffer la  stringa col numero  letto.  
Oh, cavolo, un'altra operazione di input da console, forziamo il flush
del buffer.
Leggo un numero
Metto nel buffer la stringa col numero letto. Per ora il buffer non è
pieno, quindi niente flush.
chiamo kbdhit().  Nessuno ha detto  alla kbdhit() (che è  una funzione
ereditata dal  DOS e non  è del C++)  di avvisare iostream di  fare il
flush - libertà che si è presa la Borland immaginando come molta gente
l'avrebbe usata - e quindi il buffer rimane li.
Oh, cavolo, sono nel codice di uscita del programma, flush dei buffer
di I/O prima di andarsene...
Good bye
\end{nellaTestaDelRuntime}
-- 
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 tutti i compilatori, o no?
No, specie se l'algoritmo determina, con un particolare compilatore,
un comportamento indefinito.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 tutti i compilatori, o no?
Scusa, è 4 anni che programmi e non sai la differenza tra algoritmo ed 
implementazione???
-- 
Luc.

> void main()
TF> Un paio di correzioni: 
TF> #include <iostream> 
TF> e' la versione standard dell'inclusione e, 
Dell'ultimo standard. Prima si usava  la notazione derivata dal C che,
dovendo il C++ compilare anche C, è ancora valida.
TF> inoltre, main() DEVE restituire un valore intero:
TF> int main()
TF> e' la forma corretta.
Solo secondo lo standard  e non secondo l'esecuzione, sopratutto sotto
Windows  dove  i  return  code  dei programmi  sono  pressoché  sempre
ignorati.
TF> No, specie se l'algoritmo determina, con un particolare compilatore,
TF> un comportamento indefinito.
In questo caso _non_ è un algoritmo. E' una implementazione.


In questo caso _non_ è un algoritmo. E' una implementazione.
Leggi meglio:
"Non sarò un genio di C++ ma faccio algoritmi (in Pascal
Delphi e Visual Basic) da 4 anni e lo stesso algoritmo
<dovrebbe> fare la stessa cosa con tutti i compilatori, o
no?"
Quando un algoritmo viene implementato su un particolare
compilatore, se con quel compilatore le istruzioni
utilizzate provocano un comportamento indefinito, allora gli
effetti non sono gli stessi su tutti i compilatori.
-- 
The Follet

 effetti non sono gli stessi su tutti i compilatori.
Nel caso in questione succede perchè <conio.h> non è tra gli standard e
quindi MS e Borland ne hanno creato due differenti (per includerli nel
pacchetto) dove la funzione kbhit() si comporta in modo leggermente
differente (con Borland fa il flush, con MS no).
Ok grassie mille a tutti.
Follet, ma io a te non ti ho già visto su it.comp.lang.c e su
it.comp.lang.c++?
Ma li frequenti tutti i newsgroup sul C e parenti?
^_^
Ciao

Ma li frequenti tutti i newsgroup sul C e parenti?
Si'.
-- 
The Follet

 tutti i compilatori, o no?
Si, probabilmente perň non trattano allo stesso modo il problema di
rimuovere un oggetto:
Borland c++ (evidentemente) lo fa dopo l'ultimo utilizzo dell'oggetto cout,
quindi prima di entrare nel ciclo viene eseguito il distruttore che svuota
il
buffer; mentre Visual c++ lo fa solo alla fine del blocco di istruzioni,
cioč
dopo il ciclo.
Si comporta cosě anche gcc...

> In questo caso _non_ è un algoritmo. E' una implementazione.
TF> Leggi meglio:
Studia meglio.
TF> "Non sarò un genio di C++ ma faccio algoritmi (in Pascal
TF> Delphi e Visual Basic) da 4 anni e lo stesso algoritmo
TF> <dovrebbe> fare la stessa cosa con tutti i compilatori, o
TF> no?"
La frase  è sbagliata alla  radice. Gli algoritmi  non li _fai_  in un
linguaggio. Li descrivi in un  linguaggio e quando questo linguaggio è
un linguaggio di programmazione (puoi descrivere un algoritmo anche in
arabo,  anzi, il primo  algoritmo della  storia è  stato probabilmente
descritto in arabo :) :) ) allora si dice che li implementi.
Lo  _stesso_ algoritmo  lo puoi  implementare in  linguaggi  diversi e
troverai linguaggio che possono non permetterne un'implementazione.
L'algoritmo  in  se  è  un  qualcosa  di  astratto,  tra  algoritmo  e
implementazione c'è più  o meno lo stesso rapporto  che c'è tra classe
ed oggetto  istanziato (se non  erro nel linguaggio filosofico  c'è un
"termine tecnico" per definire la cosa, ma non lo ricordo).
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<

 descritto in arabo :) :) ) allora si dice che li implementi.
Dimmi una cosa: lo stai spiegando a me ?
Secondo me ribatti per il gusto di ribattere.
Il nostro amico ha scritto un programma, che e' l'implementazione
di un algoritmo (spero che questa volta la tua vena sofista sia
soddisfatta).  Il nostro amico si meraviglia che quei passi 
dell'algoritmo, descritti con lo stesso linguaggio, ma con 
compilatori differenti, diano risultati differenti.
Cioe', parte dall'algoritmo, ne traccia una definizione in un
particolare linguaggio di programmazione e arriva a due
implementazioni, che hanno differenti comportamenti.
Questo e' dovuto al fatto che, nel momento dell'implementazione
ha fatto uso di funzioni specifiche per quella piattaforma,
specifiche di quel compilatore.  Dato che, in ogni implementazione
utilizza funzioni specifiche messe a disposizione da quel
particolare compilatore, e' chiaro che abbia due comportamenti
diversi.


> codice scritto da gente che non trova utile arrivare ad usare il C++.
TF> Io sto dicendo una cosa precisa, non cambiare strada:
No. La cambi tu. Se dico che parlo di programmi C parlo di programmi C
anche se  il programma va in  pasto ad un compilatore  C++ I programmi
C++ non sono la stessa cosa.
TF> La conformita' allo standard e' dettata, innanzitutto,
TF> dall'esigenza di rendere il codice portabile.
La portabilità (salvo alcuni linguaggi)  è più o meno mitica a seconda
del campo in cui si lavora. A cominciare dall'interfaccia utente.
TF> Nel caso specifico di main(), la conseguenza e' che si
TF> evita un "undefined behavior" su molte piattaforme.
Sono _sinceramente_ curioso di conoscerne una.
TF> questo lo sappiamo tutti quanti.
Non capisti il senso del discorso. 
TF> Tu vieni su it.comp.lang.c++ che ti rinfreschiamo le idee ;)
 
E' una cosa language independent. Ergo studia meglio.
TF> Dimmi una cosa: lo stai spiegando a me ?
Certo. Non lo avevi capito ?

 Io sto dicendo una cosa precisa, non cambiare strada:
Mai mettersi con l'Uberto... 8-PPP 
-- 
Luc.

 Si può fare in almeno (quelli che conosco) modi:
ne conosco 3!!
:-D
Ciao
    Fed


Se parli di programmi C allora non puoi questionare tra iostream.h
e iostream, che e` questione C++, pre-standard vs. std.
ciao
Massimo

 Certo. Non lo avevi capito ?
Allora  mi  spiace, ma quello che non capisce  (o  non
vuol capire) sei tu.
Io la differenza tra le due cose la conosco  benissimo
ed e' proprio in base a tale differenza che ho postato
il mio messaggio di risposta all'OP.
Tu  ribatti  al  mio  messaggio  ricordando  cio'  che 
affermo  nel  messaggio stesso e cioe' che,  data  una 
implementazione  dell'algoritmo  con  un   particolare 
compilatore,  non  e' detto che lo  stesso  algoritmo, 
implementato  con un altro compilatore dia gli  stessi 
effetti.
Questa    e'   la   differenza   tra    algoritmo    e 
implementazione  dell'algoritmo  con  un   particolare 
compilatore.
Pretendi,  cioe', di rimarcare questa  differenza  nei 
confronti di chi questa differenza la conosce gia'.  
La  prossima volta, cerca di definire meglio che  cosa 
vuoi dire e, sopratutto, *a chi* lo vuoi dire.
E cerca di documentarti su quelli che sono gli aspetti
del C++ contro cui vuoi ribattere.


 Mai mettersi con l'Uberto... 8-PPP 
Per la serie: non c'e' peggior sordo ... ;)


 Per la serie: non c'e' peggior sordo ... ;)
Ne so qualcosa, a long time ago... 8-)
-- 
Luc.

> Sono _sinceramente_ curioso di conoscerne una.
TF> Leggi la FAQ di comp.lang.c++.
Grazie, è  un po' come "Cerca  un ago in  un pagliaio" ma è  meglio di
NULL.
TF> Che  sia  una  questione  "language  independent"  sto
TF> cercando  di  ripetertelo da molti messaggi  a  questa 
TF> parte. Sei tu che stai ribattendo dicendo: si ma sotto
TF> Windows  non ha senso, si' ma sotto Windows e'  cosi',
TF> si ma sotto Windows e' cola'.
Questo non rientra coi linguaggi ma  con gli S.O. E il discorso "si ma
sotto  Windows"  era legato  alla  questione  dell'intestazione di  un
programma in C.
TF> No, specie se l'algoritmo determina, con un particolare compilatore,
TF> un comportamento indefinito.
Questa era la tua frase dove confondevi capra e cavoli.
Non è l'algoritmo. E'  la particolare implementazione di un algoritmo.
E c'è  poi una differenza (anche se  non è netta) tra  cosa si intende
come algoritmo e  cosa è una tecnica di  programmazione (come l'uso di
kbdhit()).
Ah,  io non  sto  a sentire  i  dogmatici che  parlano  come parlò  il
profeta, i saggi che fanno capire le cose invece si.


dovendo il C++ compilare anche C, č ancora valida.
In alcuni compilatori <iostream> e <iostream.h> mi pare siano diversi
(e forse VC++ č uno di questi) inoltre in futuro alcuni compilatori
potrebbero non supportare piů <iostream.h>.
Non mi sembra una grande fatica abituarsi a togliere un .h.
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di it.comp.lang (per i linguaggi di
programmazione senza un gruppo apposito e per i confronti fra i
linguaggi) partecipa alla discussione sul manifesto su it.news.gruppi.

profeta, i saggi che fanno capire le cose invece si.
Quindi, visto che tu "fai capire le cose", suppongo ti sia
autodefinito saggio.  Io, personalmente, conservo una
visione molto meno aulica del soggetto.
-- 
The Follet

Non mi sembra una grande fatica abituarsi a togliere un .h.
Si, ma non sai quanto si fa fatica a dire: "e' vero, hai
ragione" ;)
-- 
The Follet

 Si'.
Hai visto? Stavolta ho postato sul newsgroup  giusto.....
(una volta mi hai ripreso perchè il mess era OT su lang.c++ siccome non
trattava gli standard......)
^_^

trattava gli standard......)
Bravo ;) sempre cosi' ;)
-- 
The Follet


Grassie mille anche a te e complimenti per la chiarezza nelle spiegazioni e
nelle soluzioni.
Ciao

 >Non mi sembra una grande fatica abituarsi a togliere un .h.
Per me la posso anche togliere l'h dall'include ma il punto è diverso.
Per me, che ho ancora problemi a gestire le classi, che non conosco
approfonditamente le varie possibilità e potenzialità dei più svariati
strumenti del C++ e che conosco di questo linguaggio solo le basi (diciamo
che come conoscenze applicative arrivo ai tipi di dati derivati più comuni e
ai puntatori) è inutile programmare assiduamente in modo conforme allo
standard.
E questo perchè i miei programmi sono generalmente esercizi o semplici
applicativi destinati ad essere utilizzati solo sul mio computer e a non
essere distribuiti. Non sono progetti sviluppati in modo da essere
portabili. Cioè, per il momento trovo molto più importante imparare a
conoscere i vari strumenti del C++ che non imparare le regole dello
standard. Anche perchè sicuramente, se io tolgo l'h è facile che il codice
non sarà standard per altri motivi (conio.h o per qualche altro motivo
simile). Ho inoltre l'impressione che per i miei fini, cercare di aderire
allo standard significa allungarsi la strada inutilmente, complicarsi la
vita senza avere un effettivo guadagno e fare programmi meno "belli" laddove
ti serve che lo siano per avvantaggiare ad esempio la possibilità di
portarlo su SO dove non verranno mai eseguiti.
L'h mi costa poco toglierla ma ammetterai anche tu che sforzarsi per
scrivere
#include <iostream> e una riga sotto aggiungere
#include <conio.h> non ha senso perchè in ogni caso un programma che usa le
conio non è standard, con o senza h dopo iostream.
Se volessi attenermi allo standard inoltre immagino che per fare quello che
interessava a me avrei dovuto appellarmi all'assembler (che non conosco) o
peggio non avrei potuto farlo.Non mi sembra infatti che vi sia uno standard
sull'I/O di questo tipo. Invece così con una linea ho risolto il mio
problema, limitatamente al mio SO (l'unico dove serve che giri).
Sicuramente prima di sviluppare progetti di una certà entità che dovranno
essere distribuiti o che verranno svolti in gruppi numerosi mi informerò
meglio sullo standard ma per ora, ai miei fini, mi sembra piuttosto futile
complicarmi la vita con la portabilità. Sono concetti, metodi e tecniche che
vanno apprese per ultime, dopo che tutti gli strumenti del C++ sono ben
chiari al programmatore.
Vorrei inoltre corregere la mia frase
"Non sarò un genio di C++ ma faccio algoritmi (in Pascal
Delphi e Visual Basic) da 4 anni e ....."
in
Non sarò un genio di C++ ma -implemento- algoritmi in Pascal
Delphi e Visual Basic da 4 anni e .....
Adesso me ne lavo le mani, sulla differenza tra implementazione e algoritmo
(che tral'altro conoscevo e l'errore era una pura e semplice distrazione)
scannatevi pure tra di voi ^_^
Ciao a tutti-

standard.
E` difficile perdere le cattive abitudini quando le hai da anni.


 differente (con Borland fa il flush, con MS no).
Dubito che sia kbhit() a eseguire il flush di cout,
perchč la prima č una funzione c, la seconda č
un metodo di una istanza di un ogetto c++.
Comunque la questione č piů complicata perché
questo codice su Visual C++ si comporta come su
Borland C++:
#include <iostream>
#include <conio.h>
int main(){
 int n;
 std::cin>>n;
 std::cout<<n<<std::endl;
 std::cin>>n;
 std::cout<<n;
 while(!_kbhit());
 return 0;
}
Quindi non dipende dall'implementazione di kbhit().
Ciao
    Fed

chiari al programmatore.
E' l'esatto contrario, vanno imparati per primi.
-- 
The Follet


E' inutile sapere come deve essere creata una classe per essere standard, se
non sai cosa è una classe.  (parzialmente è il mio caso)
E' inutile sapere cosa può e non può contenere un distruttore/costruttore
per essere standard se non sai cosa è e cosa fa un distruttore/costruttore
(è il mio caso)
E' inutile sapere che <iostream> è standard e <iostream.h> non è standard se
non sai cosa sono le librerie (non è il mio caso)
Sia ben chiaro, la mia non è polemica, è ignoranza. Non ho problemi ad
ammetterlo, ignoro come sia definito lo standard, in effetti negli altri
linguaggi (puramente Borland certi, puramente Microsoft altri) non vi erano
tutte queste diatribe sugli standard e quindi fino ad ora non mi sono posto
il problema dello standard quanto invece mi sono posto il problema di
tradurre in C++ quello che già sapevo fare in Pascal (così come mi son posto
il problema di tradurre in VB quello che sapevo in Delphi due anni fa, quasi
puramente un problema sintattico) e di imparare ad utilizzare gli strumenti
nuovi che il C++ mette a disposizione (rispetto al Pascal ci sono le classi,
che conosco per sommi capi -quel poco che ho ereditato dal Delphi- ma di cui
ignoro le peculiarità particolari, ma c'è anche una gestione diversa e più
potente dei puntatori).

 *NEL TUO CASO* produce lo stesso effetto.
Leggi il messaggio che ho mandato
venerdě 16 novembre 2001 22:01
;-)
Ciao
    Fed

> profeta, i saggi che fanno capire le cose invece si.
TF> Quindi, visto che tu "fai capire le cose", suppongo ti sia
TF> autodefinito saggio.
No. Questa è una tua conclusione, sbagliata come altre.
