Compilatore C

[NubeCheCorre]

Ho un' altra domandina da porvi...

Sto provando il compilatore e devo dire che e' ben fatto, ma ho un problemino che non so come risolvere...

Quando compilo il file e lo eseguo il compilatore mi apre una " shell " ?? che pero' richiude in un millisecondo dove dovrebbe esserci il mio programma.. Il problema e' che io non riesco a vedere nulla !

Dando un' occhiata alla guida ho letto che aggiungendo un comando

SYSTEM ( "wait "); ( se non ricordo male e' questo )

Si puo' "bloccare" l' esecuzione del programma e metterlo in pausa fino a che non si preme invio..

Ora se faccio un semplice "hello word" mi puo' stare anche bene ma se faccio programmi dove devo usare la tastiera per fare scelte o quant' altro come faccio ?? non c'e' un modo per avere la shell su schermo senza che scompaia in un millisecondo ?...

Ripeto la shell mi va bene perche' devo allenarmi con il c e non con le api di windows. sto aspettando il mio A1...

Grazie !

[Trix180]

è

system("PAUSE");

[RadomE]

Si con system ("PAUSE"); nella shell Win appare il tipico comando "Premere un tasto per continuare"

Se invece vuoi fermare il programma per un determinato tempo puoi usare la sintassi sleep(); e tra le parentesi si deve specificare un intero che corrisponderà (mi pare) al numero di millisecondi in cui l'applicazione resterà in sospeso.

Ricorda che cmq non è consigliabile usare Win per applicazioni real-time

[Fab0569]

Ricorda che cmq non è consigliabile usare Win per applicazioni real-time

Una grande Verità!

[Trix180]

Ricorda che cmq non è consigliabile usare Win per applicazioni real-time

pultroppo c'è windows per Realtime (non CE[sso]) e ha anche una, per fortuna, una piccola frangia del mercato.

[NubeCheCorre]

Ma io non devo fare chissa' cosa devo semplicemente esercitarmi con il c e fare un po' di quegli esercizi che si trovano sui libri di programmazione per non arrugginirmi del tutto..

Ma come faccio se la shell mi sparisce in un millisecondo ?

Cioe' con amiga non avevo questo problema perche' la shell stava li' tranquilla e non se ne andava e io potevo fare tutto quello che volevo..

Invece sotto Win tutti sti casini...

Un' altra domanda questo problema e' legato a questo compilatore che sto usando oppure e' proprio un problema dell' Xp con le shell e quindi anche con i compilatori ?

Thanks !!

[Fab0569]

Succede la stessa cosa con Visual Studio sotto Win2000 (utilizzato tempo fa in ufficio)

[sHaDy]

Un' altra domanda questo problema e' legato a questo compilatore che sto usando oppure e' proprio un problema dell' Xp con le shell e quindi anche con i compilatori ?

Il problema è legato a windows non al compilatore (se non ricordo male con l 98 non c'era questo problema). Comunque se devi solo esercitarti e non scrivere applicazioni vere e proprie puoi semplicemente aprire il prompt dei comandi e lanciare il programma da lì per evitare il problema.

[NubeCheCorre]

Ok! Grazie per la dritta non ci avevo pensato !

[riko]

Il problema è legato a windows non al compilatore (se non ricordo male con l 98 non c'era questo problema). Comunque se devi solo esercitarti e non scrivere applicazioni vere e proprie puoi semplicemente aprire il prompt dei comandi e lanciare il programma da lì per evitare il problema.

Veramente non e` affatto un problema, semplicemente e` il comportamento corretto. Quando lui vede un'applicazione da console, lui lancia il terminale, quando ha finito lo chiude.
Questo a meno che non ci sia del pending-input. Nel caso aspetta.
Infatti come fai notare, se apri il prompt e lanci da li, funge tutto.

Dopo di che si Windows di applicazioni 'vere' da prompt non ne girano. In pratica quasi tutte usano una GUI, oppure sono servizi di sistema ( e lanciati come tali ), molto diversa la situazione sugli *nix, dove invece ci sono *molte* applicazioni pure-cl assai utili.
D'altra parte l'utente medio Win non ne vuole sapere di cl

Peraltro do alcuni consigli:
Se si vuole riprendere la mano sulla programmazione (o si vuole iniziare da 0) oggi, se non si hanno particolarissime esigenze, sono tentato di sconsigliare il C. Troppi dettagli 'inutili' di cui tenere traccia, quelli si possono affontare in un secondo momento.
Il C deve essere conosciuto e poi *non* usato. Salvo per cose specifiche, appunto.

Per programmare Windows non e` il sistema operativo su cui piu` mi senta a mio agio, anzi. Troppo diverso dagli ambienti che conosco, per fare sul serio bisogna prendere la mano sul Platform SDK, tutte conoscenze *non* spendibili in ambito *nix (o quasi).

Molto piu` efficace lavorare in ambiente *nix direttamente.

[sHaDy]

Veramente non e` affatto un problema, semplicemente e` il comportamento corretto. Quando lui vede un'applicazione da console, lui lancia il terminale, quando ha finito lo chiude.
Questo a meno che non ci sia del pending-input. Nel caso aspetta.
Infatti come fai notare, se apri il prompt e lanci da li, funge tutto.

Sì lo so ma fatto sta che è un "problema" per chi vuole fare programmi lanciabili dal prompt (soprattutto se uno arriva da versioni precedenti di windows.

Peraltro do alcuni consigli:
Se si vuole riprendere la mano sulla programmazione (o si vuole iniziare da 0) oggi, se non si hanno particolarissime esigenze, sono tentato di sconsigliare il C. Troppi dettagli 'inutili' di cui tenere traccia, quelli si possono affontare in un secondo momento.
Il C deve essere conosciuto e poi *non* usato. Salvo per cose specifiche, appunto.

Sono d'accordo con te, il C non è un linguaggio molto adatto per chi ha appena cominciato ad occuparsi di programmazione o, peggio, per chi non ne sa ancora una cippa Però è un linguaggio che prima o poi va imparato, non ci sono storie.

[riko]

Sì lo so ma fatto sta che è un "problema" per chi vuole fare programmi lanciabili dal prompt (soprattutto se uno arriva da versioni precedenti di windows.

Vero... anche se io non sono cosi` sicuro che prima di problemi non ce ne fossero :))
Sara` che io sono sempre andato di vim + gcc anche sotto win :))
[ peraltro gvim funziona divinamente sotto Windows ]

Sono d'accordo con te, il C non è un linguaggio molto adatto per chi ha appena cominciato ad occuparsi di programmazione o, peggio, per chi non ne sa ancora una cippa Però è un linguaggio che prima o poi va imparato, non ci sono storie.

Infatti. Lo ritengo importante perche` avvicina alla macchina il mimo indispensabile per capire grosso modo come funziona, senza entrare in cose dipendenti dall'implementazione (per esempio le chiamate di sistema).
Non solo... c'e` un mucchio di documentazione in giro che pensa soprattutto al C. E mentre un programmatore C che si trova davanti del PHP piu` che altro storcera` il naso per certe brutture, un programmarore PHP che si trova davanti un sorgente C potrebbe trovarsi davanti qualche brutto (per valori ampli di qualche) quarto d'ora.

Purtroppo e` spesso abusato. Per questo io pongo sempre la domanda: 'ti serve veramente farlo in C'?
Generalmente la risposta e` no, e si risparmia un bel po' di tempo e guai.
Poi allo stato attuale siamo d'accordo. Va conoscito, non c'e` storia (esattamente come va conosciuto anche un po' di Assembly, anche se poi mai mi sognerei di svilupparci -- sempre in programma un'ottimizzazione di GMP per PPC... ma necessito di tanto tanto tempo e voglia, specie perche` io adoro i linguaggi di alto livello, sigh :( ).

[sHaDy]

Purtroppo e` spesso abusato. Per questo io pongo sempre la domanda: 'ti serve veramente farlo in C'?

Lo so bene, io stesso lo utilizzo in modo improprio per fare cose che magari (esageriamo) potrebbero essere fatte con un semplice script bash. Però questo accade perchè quando devo scrivere un qualsiasi programma ormai mi trovo a pensarlo direttamente in C. Insomma la scelta del linguaggio non dipende sempre solo da qual'è il più adatto per risolvere un determinato problema ma anche da qual'è quello con cui uno è più pratico e con cui si trova meglio.