Newsgroup: it.comp.lang.c++
Titolo: errore niubbissimo in un semplice programma...

come mai quando compilo questo programma
//programma che stampa a video una stringa
#include <stdio.h>
int main(void){
    printf("Ciao Mondo\n");
}
l'exe si apre e si chiude subito senza darmi il tempo di vedere cosa c'è scritto?
c'entra qualcosa il fatto che uso winxp?
è normale che faccia così o ho sbagliato qualcosa?
grazie

 scritto?  
http://groups.google.com/groups/search?hl=en&q=c%2B%2B+%22la+finestra+si+chiude%22
 

"Anima Crepuscolare" ha scritto:

Aggiungi: system("pause");
prima di } 

 prima di }
secondo me questa soluzione non è la migliore. questo dice al SO di
eseguire il comando batch "pause", riconosciuto dal DOS soltanto. se
vuoi mantenere la portabilità IMHO la soluzione migliore potrebbe
essere:
cout<<"premere un tasto per continuare..";
cin.get();

 è normale che faccia così o ho sbagliato qualcosa?
Probabilemente cherchi d'utilisare un IDE che non convienne che
per i programmi a finestre, e che non sa trattare i programmi
che non aprono le sue proprie finestre.
--
James Kanze (Gabi Software)            email: 
james...@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, 
+33 (0)1 30 23 00 34

vabbè, non è che l'exe si apre solo, voleva dire "quando eseguo
l'exe, il programma stampa la riga e si chiude subito, senza darmi il
tempo di leggere la riga". Ma nn soffermiamoci sulle piccole cose :-)
P.S. ciò è semplicemente causato dalla mancanza di un'istruzione che
attenda qualkosa prima di terminare il main, facendo uscire il
programma. per es. cin.get() attende la pressione di un tasto, così
appena hai finito di leggere esce, ma si poteva anke implementare un
metodo che attendeva x sec. prima di uscire
James Kanze ha scritto:


[...]Ma nn soffermiamoci sulle piccole cose :-)
La pensiamo allo stesso modo :-)
E' un po' antipatico, d'altronde, questo non voler capire un problema,
visto che penso si tratti proprio della *volontà* di non capire ;-)




Scusi, ma non capisco davero. Credo ch'è un problemma legato
al suo IDE, ma mi servo di Windows solo per portare codice
essistente, e non mi sono mai servito dal IDE. Sotto Solaris,
con Sun Studio, l'IDE fornisce una finestra dove s'essecuta il
codice. Mi sembra qu'un IDE che non lo fa non è utilisabile per
i programmi "riga di commanda". Mi sembra anche che se l'IDE
cuide la finestra senza che si l'è richiesta, che c'è proprio un
problema dall'IDE. Che non l'ha ben configurato, o qual'cosa di
genero. Ma allora, bisogna domandare proprio al sugetto dal'IDE;
non è più un problema C++.
In ogni caso, aggiungere dalle entrate specifica alfinche la
finestra non chiude non mi sembra una buona soluzione. Per una
vera applicazione, non sara permesso. Sarebbe megliore di
trovare cos'è mal configurato, e corregere la configurazione.
--
James Kanze (GABI Software)             
email:james...@gmail.com



Questo mi pare ingiusto. Non e' che solo perche' si lavora con Windows
tutto il mondo lavora con Windows e tutti i sistemi si comportano come
Windows.
Il vero problema e' che tutti gli ide windows con cui ho lavorato
presentano l'output dei programmi text oriented in finestre che si
chiudono automaticamente alla terminazione del programma, rendendo
necessario inserire istruzioni che chiedono un input per bloccare il
programma, eseguire il programma da linea di comando oppure, ed e' la
soluzione che preferisco, inserire un break point in fondo a main.
Purtroppo mentre il Borland mi permette di inserire il break
sull'ultima graffa e ci si ferma indipendentemente dal punto di main
dal quale si esce, con VC++ devo mettere un break su ogni istruzione di
potenziale uscita dal main().
Nota che tutto questo non ha niente a che fare col C++.
Ciao,
Nicola

 soluzione che preferisco, inserire un break point in fondo a main.
Ma soffra dallo stesso problema, non? Come far per vedere le
uschite dei distruttori degli oggetti statici?
--
James Kanze (GABI Software)             
email:james...@gmail.com


 uschite dei distruttori degli oggetti statici?
Non ho alternative migliori rispetto al procedere a step fino al
distruttore che interessa oppure mettere un altro break point proprio
nel distruttore.
Ciao,
Nicola

 finestra non chiude non mi sembra una buona soluzione.
Per fare un test del codice, va più che bene.

 Nota che tutto questo non ha niente a che fare col C++.
Lo so benissimo, Nicola.  Anche questo ricordarmelo è espressione
della "finta ingenuità" a cui mi riferivo prima ;-)

 della "finta ingenuità" a cui mi riferivo prima ;-)
O della consapevolezza che le proprie risposte non le legge solo
l'autore del messaggio cui si risponde.
Ciao,
Nicola

 Per fare un test del codice, va più che bene.
Per fare un test di "hello, world", va bene. Per fare un test
d'un codice reale, con oggetti statici con distruttori, e dove
non sai dove si trova tutti chiamate di exit o d'abort (dopo un
assert, da essempio), non va bene.


 nel distruttore.
Non è solo questa. Nei miei programmi, le uscite che mi
interessono il più, ci son i messagi d'assert. Chi si segue
immediatemente di un abort(), cioè che il programma termina.
Allora, quel è l'interessa di fare in modo che diviene
impossibile leggere i messagi d'assert? C'è qualcosa che non ho
capito.


 stiamo riferendo.
Ne ho sentito parlare un po, ma sempre come problema di
principianti. Pensavo dunque (e penso proprio ancora, perche è
una cosa così fondamentale) che s'agisce piutosto di un problema
di defaults che non convengono allo sviluppo di programmi non
Windows; molto spesso i principianti lavorono coi defaults,
senza porre la domanda se si addono.
Mi ricordo anche aver visto uno degli primi IDE di Microsoft,
sotto MS-DOS, dove era molto più difficile tenere le uscite dal
programma. Inveci, lo faceva. (Senza finestrine, bisognava
basculare fra due schermi virtuale, ma funzionava.) Dal loro, ho
visto Sun Studio, e avanti Forte, dove non era problema; il
programma ha il suo proprio vetro, dove arriva tutte le uscite
cout e cerr; c'era gia il caso nei primi debugger, come dbxtool,
quasi venti anni fa.
Se Microsoft lo faceva primo, e tutti gli altri l'hanno sempre
fatto, come neache imaginare che non fosse possibile con Visual
Studios?
--
James Kanze (GABI Software)             
email:james...@gmail.com


 capito.
Nessuno secondo me. Forse semplicemente non l'ha mai chiesto nessuno...
Ciao,
Nicola

 Studios?
L'unica è mettere un BP in crt0dat.c (trace con F11 dopo main()).
Kiuhnm