Problema con il compilatore devc++
mi sono scaricato il compilatore devc++ , ma quando devo compilare un programma la schermata nera improvvisamente sparisce. perchè? cosa dovrei fare per risolvere il problema?
Risposte
Ma intendi questo software... http://www.bloodshed.net/devcpp.html
Perché usandolo anche io per studiare non ho ancora visto una schermata nera, poi per compilare o uso l'apposito menù oppure la combinazione di tasti CTRL+F9.
Perché usandolo anche io per studiare non ho ancora visto una schermata nera, poi per compilare o uso l'apposito menù oppure la combinazione di tasti CTRL+F9.
"baldo89":
mi sono scaricato il compilatore devc++ , ma quando devo compilare un programma la schermata nera improvvisamente sparisce. perchè? cosa dovrei fare per risolvere il problema?
cambia compilatore
Veramente cambiare IDE, oramai DEVC++ è vetusto, e non più aggiornato dal 2005 se ricordo bene.
Ne esistono a decinaia di migliori, completi e aggiornati. Es: NetBeans.
Per il problema in particolare non saprei, non ho mai utilizzato DevC++ per i motivi sopra
Innumerevoli volte, io e molti altri programmatori, ci siamo battuti su questo e altri forum, italiani ed esteri, contro Dev-C++. Riassumo qui brevemente le principali critiche:
1. È un progetto abbandonato da una decina di anni.
2. È pieno di bug che non verranno mai risolti.
3. È incompatibile con tutte le versioni di Windows da Vista in poi.
4. È la causa dell'uso immotivato della bruttissima riga system("PAUSE"); prima del return del main per impedire la chiusura della finestra.*
D'altra parte non esiste alcun, se pur misero, vantaggio derivante dall'uso di Dev-C++. Esistono infatti innumerevoli IDE gratuiti, alcuni anche open-source, meglio progettati, con meno bug, che vengono migliorati di giorno in giorno e con compilatori (perché Dev-C++ NON è un compilatore ma un IDE) più moderni, performanti e attenti agli standard. Questi altri IDE dispongono inoltre spesso di interfacce migliori con accesso a strumenti di analisi, testing e debugging più avanzati e potenti di quelli presenti in Dev-C++. Ma nonostante tutto questo, si continua a consigliare quello schifo di programma nei corsi di laurea e nelle scuole, in mondi in cui a quanto pare i professori non scrivono un programma un po' complesso in C o C++ da decenni e forse non ne sarebbero neanche in grado. E i programmatori inesperti se lo consigliano tra di loro come una pietra rara.
DEV-C++ FA SCHIFO E NON C'È ALCUNA RAGIONE AL MONDO PER USARLO. Esistono ovviamente soluzioni semplici al tuo problema, il già citato e criticato system("PAUSE") ad esempio o le altre che trovi cercando quella riga su internet, ma perché risolvere con del codice un problema del programma che usi per svilupparlo, compilarlo ed eseguirlo? Problema che non verrà mai risolto. E anche risolvendo questo problema con quella riga o con altre soluzioni, incapperai presto in innumerevoli altri bug e problemi. Non ha senso rimandare l'inevitabile passaggio a qualcosa di meglio. Tra quelli gratuiti mi sono sempre trovato bene con Visual C++ Express della Microsoft (e tutte le sue versioni più professionali che sono però a pagamento) e con Code::Blocks (che è open-source). Ne esistono poi altri, ma non li conosco benissimo.
1. È un progetto abbandonato da una decina di anni.
2. È pieno di bug che non verranno mai risolti.
3. È incompatibile con tutte le versioni di Windows da Vista in poi.
4. È la causa dell'uso immotivato della bruttissima riga system("PAUSE"); prima del return del main per impedire la chiusura della finestra.*
D'altra parte non esiste alcun, se pur misero, vantaggio derivante dall'uso di Dev-C++. Esistono infatti innumerevoli IDE gratuiti, alcuni anche open-source, meglio progettati, con meno bug, che vengono migliorati di giorno in giorno e con compilatori (perché Dev-C++ NON è un compilatore ma un IDE) più moderni, performanti e attenti agli standard. Questi altri IDE dispongono inoltre spesso di interfacce migliori con accesso a strumenti di analisi, testing e debugging più avanzati e potenti di quelli presenti in Dev-C++. Ma nonostante tutto questo, si continua a consigliare quello schifo di programma nei corsi di laurea e nelle scuole, in mondi in cui a quanto pare i professori non scrivono un programma un po' complesso in C o C++ da decenni e forse non ne sarebbero neanche in grado. E i programmatori inesperti se lo consigliano tra di loro come una pietra rara.
DEV-C++ FA SCHIFO E NON C'È ALCUNA RAGIONE AL MONDO PER USARLO. Esistono ovviamente soluzioni semplici al tuo problema, il già citato e criticato system("PAUSE") ad esempio o le altre che trovi cercando quella riga su internet, ma perché risolvere con del codice un problema del programma che usi per svilupparlo, compilarlo ed eseguirlo? Problema che non verrà mai risolto. E anche risolvendo questo problema con quella riga o con altre soluzioni, incapperai presto in innumerevoli altri bug e problemi. Non ha senso rimandare l'inevitabile passaggio a qualcosa di meglio. Tra quelli gratuiti mi sono sempre trovato bene con Visual C++ Express della Microsoft (e tutte le sue versioni più professionali che sono però a pagamento) e con Code::Blocks (che è open-source). Ne esistono poi altri, ma non li conosco benissimo.
bè, mi avete convinto! cambio compilatore . visual c++ va bene anche per per programmare in c?
Sì, ma se stai seguendo un corso in cui si fa uso di Dev-C++, ti consiglio Code::Blocks con Mingw (lo puoi scaricare direttamente da questo link) perché avrai probabilmente meno problemi di compatibilità con alcuni programmi del tuo professore (ho notato che molti dei codici nei corsi di C base fanno uso di estensioni non standard del C e che il compilatore Microsoft non supporta). Per uno esperto non ci sono problemi ad aggiustare il programma, ma se non lo si è, allora è meglio usare qualcosa che possa dare meno problemi.
Scusatemi se interrompo la propaganda anti-IDE e mi permetto di ritornare IN TOPIC.
@baldo: nessuno si è posto il dubbio che il tuo problema possa essere molto più semplice di quello che sembra.
Aggiungi la riga
in fondo al tuo codice, prima dell'ultima parentesi graffa, quella che chiude il main, e dimmi se cambia qualcosa.
@baldo: nessuno si è posto il dubbio che il tuo problema possa essere molto più semplice di quello che sembra.
Aggiungi la riga
scanf("%*s");in fondo al tuo codice, prima dell'ultima parentesi graffa, quella che chiude il main, e dimmi se cambia qualcosa.
per raptorista: no non cambia nulla.
per apatriarca: non sto seguendo nessun corso di programmazione, vorrei solo riprendere a programmare in c perchè per i fisici questo linguaggio è fondamentale.grazie!
per apatriarca: non sto seguendo nessun corso di programmazione, vorrei solo riprendere a programmare in c perchè per i fisici questo linguaggio è fondamentale.grazie!
Per la questione codice: descrivi meglio l'anomalia; la finestra quando si chiude esattamente? Riesci a fare un programma tipo "Hello world"?
Per la questione compilatore: io uso senza problemi gcc e g++, che sono compilatori da riga di comando, e non uso alcun IDE [non mi piacciono perché creano una marea di file spazzatura].
Se sei su linux, quindi, ti consiglio di andare diretto con gedit + gcc o vim + gcc. Se scegli questa via ti posso dare qualche dritta su come renderli molto più efficienti per la programmazione.
Se sei su winzoz, la soluzione di prima è comunque adattabile, penso; gedit c'è di sicuro anche per win, gcc non sono sicuro ma credo di sì.
Per la questione compilatore: io uso senza problemi gcc e g++, che sono compilatori da riga di comando, e non uso alcun IDE [non mi piacciono perché creano una marea di file spazzatura].
Se sei su linux, quindi, ti consiglio di andare diretto con gedit + gcc o vim + gcc. Se scegli questa via ti posso dare qualche dritta su come renderli molto più efficienti per la programmazione.
Se sei su winzoz, la soluzione di prima è comunque adattabile, penso; gedit c'è di sicuro anche per win, gcc non sono sicuro ma credo di sì.
Che manuale stai seguendo? Come mai hai scelto Dev-C++?
La schermata nera che ti sparisce di cui parli, fa riferimento a quando lanci l'eseguibile col doppio click? Se si, è normale che accada se non metti un system("pause") prima del return del main (o qualsiasi altra soluzione che mandi momentaneamente in pausa il programma, anche un getchar() per dire). E questo non dipende dal compilatore! Il punto è che su windows gli utenti non sono abituati ad avere a che fare con la shell, di conseguenza vanno avanti per click, ma se fai un'applicazione da shell, per forza che poi che agendo per click, qualcosa non andrà.
Se invece lanci la tua applicazione dal cmd, non ci saranno problemi.
Se il problema di cui parli, avviene mentre sta compilando, allora assicurati che non ti segnali qualche errore o se nonostante ciò, il programma venga comunque compilato.
VisualC++ è un ottimo IDE se devi programmare esclusivamente su windows e devi far uso di librerie non standard utilizzabili su windows (infatti il VisualC++ non è multipiattaforma).
Se devi considerare un altro IDE, ti consiglio, come qualcuno ha già fatto, Code::Blocks.
Sempre come qualcuno ha già detto, se hai possibilità/voglia di utilizzare una qualche distro linux, un editor di testo e gcc (g++ per il C++) bastano ampiamente (mettici pure gdb per il debug). Come editor di testo ti consiglierei Vim che inizialmente può sembrare magari un po' macchinoso, ma con un po' di pratica ti ci abitui e direi che è l'editor di testo più potente che ci sia ed è anche più di un semplice editor di testo volendo...ha una miriade di plugin e puoi addirittura scrivere il codice e compilare, direttamente da Vim senza dover uscire dalla sua finestra.
Non capisco perchè per i fisici il C sia fondamentale, non mi risulta.
Se invece lanci la tua applicazione dal cmd, non ci saranno problemi.
Se il problema di cui parli, avviene mentre sta compilando, allora assicurati che non ti segnali qualche errore o se nonostante ciò, il programma venga comunque compilato.
VisualC++ è un ottimo IDE se devi programmare esclusivamente su windows e devi far uso di librerie non standard utilizzabili su windows (infatti il VisualC++ non è multipiattaforma).
Se devi considerare un altro IDE, ti consiglio, come qualcuno ha già fatto, Code::Blocks.
Sempre come qualcuno ha già detto, se hai possibilità/voglia di utilizzare una qualche distro linux, un editor di testo e gcc (g++ per il C++) bastano ampiamente (mettici pure gdb per il debug). Come editor di testo ti consiglierei Vim che inizialmente può sembrare magari un po' macchinoso, ma con un po' di pratica ti ci abitui e direi che è l'editor di testo più potente che ci sia ed è anche più di un semplice editor di testo volendo...ha una miriade di plugin e puoi addirittura scrivere il codice e compilare, direttamente da Vim senza dover uscire dalla sua finestra.
Non capisco perchè per i fisici il C sia fondamentale, non mi risulta.
"maths91":
La schermata nera che ti sparisce di cui parli, fa riferimento a quando lanci l'eseguibile col doppio click? Se si, è normale che accada se non metti un system("pause") prima del return del main (o qualsiasi altra soluzione che mandi momentaneamente in pausa il programma, anche un getchar() per dire). E questo non dipende dal compilatore! Il punto è che su windows gli utenti non sono abituati ad avere a che fare con la shell, di conseguenza vanno avanti per click, ma se fai un'applicazione da shell, per forza che poi che agendo per click, qualcosa non andrà.
Giusto per curiosità... Leggere i post precedenti prima di rispondere??
"maths91":
ha una miriade di plugin e puoi addirittura scrivere il codice e compilare, direttamente da Vim senza dover uscire dalla sua finestra.
Questa mi mancava... Un riferimento?
[OT]
Adesso capisco perchè in molti codici compare questa riga, e molte persone la utilizzano inspiegabilmente senza saperne il significato. Interessante
Gedit fun pure io
Dipende però dal linguaggio, con un Java è naturale utilizzare un IDE, per le librerire.
Confermo che esiste la versione di Gedit per Win e per l'alternativa del gcc c'è cygwin...
[/OT]
4. È la causa dell'uso immotivato della bruttissima riga system("PAUSE"); prima del return del main per impedire la chiusura della finestra.
Adesso capisco perchè in molti codici compare questa riga, e molte persone la utilizzano inspiegabilmente senza saperne il significato. Interessante
"Raptorista":
Per la questione compilatore: io uso senza problemi gcc e g++, che sono compilatori da riga di comando, e non uso alcun IDE [non mi piacciono perché creano una marea di file spazzatura].
Se sei su linux, quindi, ti consiglio di andare diretto con gedit + gcc o vim + gcc. Se scegli questa via ti posso dare qualche dritta su come renderli molto più efficienti per la programmazione.
Se sei su winzoz, la soluzione di prima è comunque adattabile, penso; gedit c'è di sicuro anche per win, gcc non sono sicuro ma credo di sì.
Gedit fun pure io
Dipende però dal linguaggio, con un Java è naturale utilizzare un IDE, per le librerire.
Confermo che esiste la versione di Gedit per Win e per l'alternativa del gcc c'è cygwin...
[/OT]
E questo non dipende dal compilatore!
Il compilatore non ha niente a che fare con l'esecuzione del programma ed è quindi ovvio che non abbia niente a che fare con il problema. Ma dipende senza dubbio dall'IDE (e Dev-C++ è un IDE e non un compilatore). Code::Blocks e Visual C++ non sono affetti dal problema, eseguendo il programma in modalità release* la finestra rimane aperta fino alla pressione di un tasto. E lo stesso vale per tutti gli altri IDE che ho usato negli ultimi anni. Per cui lo considero un bug dell'IDE e non un problema più generale.
Il punto è che su windows gli utenti non sono abituati ad avere a che fare con la shell, di conseguenza vanno avanti per click, ma se fai un'applicazione da shell, per forza che poi che agendo per click, qualcosa non andrà. Se invece lanci la tua applicazione dal cmd, non ci saranno problemi.
Ho utilizzato IDE in grado di mostrare (emulato) il funzionamento di programmi su piattaforme molto diverse da quelle sulle quali stavo sviluppando (cellulari ad esempio). Un programma per console è semplicemente un programma che riceve e invia "messaggi" di tipo testuale e non è certamente difficile redirigere questi stream su finestre interne all'IDE (come fa ad esempio Eclipse se non ricordo male) o aprire una finestra console nel quale stai eseguendo un file batch in cui il programma è seguito da un PAUSE (stiamo parlando di Windows) o qualcosa di più complicato. A me sembra qualcosa di tutt'altro che complicato.
VisualC++ è un ottimo IDE se devi programmare esclusivamente su windows e devi far uso di librerie non standard utilizzabili su windows (infatti il VisualC++ non è multipiattaforma).
È possibile sviluppare programmi multipiattaforma utilizzando Visual Studio facendo uso di librerie multipiattaforma. È poi ovviamente necessario compilare il programma per le piattaforme diverse da Windows con tools esterni, ma è possibile. Alcune piattaforme che Windows Mobile e Xbox360 sono poi supportate direttamente da Microsoft.
Sempre come qualcuno ha già detto, se hai possibilità/voglia di utilizzare una qualche distro linux, un editor di testo e gcc (g++ per il C++) bastano ampiamente (mettici pure gdb per il debug). Come editor di testo ti consiglierei Vim che inizialmente può sembrare magari un po' macchinoso, ma con un po' di pratica ti ci abitui e direi che è l'editor di testo più potente che ci sia ed è anche più di un semplice editor di testo volendo...ha una miriade di plugin e puoi addirittura scrivere il codice e compilare, direttamente da Vim senza dover uscire dalla sua finestra.
Esistono svariati editor di testo e compilatore da linea di comando anche per Windows e non mi sembra una buona ragione per passare a Linux.
* Visual C++ suppone che se si usa il debugger ci siano dei breakpoint e che quindi non sia necessario fermare l'esecuzione alla fine mentre Code::Blocks lo fa in ogni caso e restituisce anche delle statistiche sull'esecuzione del programma
"ham_burst":
[OT]
Gedit fun pure io
Dipende però dal linguaggio, con un Java è naturale utilizzare un IDE, per le librerire.
Confermo che esiste la versione di Gedit per Win e per l'alternativa del gcc c'è cygwin...
[/OT]
Anche a me piace tantissimo gedit quando lavoro su Linux. Non sapevo ci fosse su Windows (uso normalmente Notepad++). Ma credo che mingw sia un porting migliore di gcc su Windows. Ma sono ultimamente in dubbio se abbandonare gcc in favore di LLVM.
@raptorista: si evince facilmente dalla mia risposta, che ho letto i post precedenti. Se qualcosa, sfugge, pazienza.
Per la tua seconda domanda: link.
@apatriarca: si, volevo dire IDE, avevo in mente il discorso sul gcc e quindi mi è venuto di scrivere compilatore. Non è un bug, semplicemente una funzionalità in meno al limite, ma comunque non attribuirei propriamente la cosa all'IDE visto che se crei un'applicazione da console, mi pare logico lanciarla da console (ed il problema non si presenterebbe). E comunque per la modalità release di cui parli o qualsiasi altra che non presenti questo "problema", non vorrei sbagliare, ma è perchè in fase di compilazione viene comunque aggiunto qualcosa che mandi in pausa momentaneamente il programma.
Sul secondo punto, corcordo che non sia niente di complicato da implementare, ma ritorniamo al punto che quell'IDE non ha semplicemente tale funzionalità e rimane di fatto che le applicazioni da console, andrebbero utilizzare da essa (altrimenti ti fai un'applicazione con GUI e vai di click quanto ti pare). Ed è un dato di fatto che il normale utente windowsiano, non ha familiarità con la console.
Sul terzo punto, beh se devi scrivere semplicemente il codice e basta con quell'IDE, tanto vale che usi un semplice editor di testo i punti a favore di quell'IDE rispetto agli altri su windows (non per niente di certo non leggero), sono l'ottima integrazione in ambiente windows (e non lo usi altrove) soprattutto con le sue librerie/API permettendo di gestirle facilmente e con una certa dinamicità (tra le altre cose).
Sicuramente l'esperienza in quanto a programmazione su ambienti *nix è superiore rispetto all'ambiente windows (ad eccezione se vogliamo per il framework .NET, ma con Mono ormai è molto agevole anche in ambiente *nix) ed ho scritto poi se ha voglia (è un modo per avvicinarsi anche a sistemi operativi migliori, al di la della programmazione).
I compilatori di cui parli, ma la quasi totalità parlando più in generale, sono basati sempre su gcc, quindi perchè non usare direttamente esso.
Ragione in più allora magari per usare VisualC++ su windows. Poi dipende da cosa uno deve farci, per piccole applicazioni, sicuramente non ci si va ad installare un IDE grosso come VisualC++, si userà qualcosa di più leggero, vedi Code::Blocks. Personalmente poi, non amo gli IDE.
Per la tua seconda domanda: link.
@apatriarca: si, volevo dire IDE, avevo in mente il discorso sul gcc e quindi mi è venuto di scrivere compilatore. Non è un bug, semplicemente una funzionalità in meno al limite, ma comunque non attribuirei propriamente la cosa all'IDE visto che se crei un'applicazione da console, mi pare logico lanciarla da console (ed il problema non si presenterebbe). E comunque per la modalità release di cui parli o qualsiasi altra che non presenti questo "problema", non vorrei sbagliare, ma è perchè in fase di compilazione viene comunque aggiunto qualcosa che mandi in pausa momentaneamente il programma.
Sul secondo punto, corcordo che non sia niente di complicato da implementare, ma ritorniamo al punto che quell'IDE non ha semplicemente tale funzionalità e rimane di fatto che le applicazioni da console, andrebbero utilizzare da essa (altrimenti ti fai un'applicazione con GUI e vai di click quanto ti pare). Ed è un dato di fatto che il normale utente windowsiano, non ha familiarità con la console.
Sul terzo punto, beh se devi scrivere semplicemente il codice e basta con quell'IDE, tanto vale che usi un semplice editor di testo
i punti a favore di quell'IDE rispetto agli altri su windows (non per niente di certo non leggero), sono l'ottima integrazione in ambiente windows (e non lo usi altrove) soprattutto con le sue librerie/API permettendo di gestirle facilmente e con una certa dinamicità (tra le altre cose).Sicuramente l'esperienza in quanto a programmazione su ambienti *nix è superiore rispetto all'ambiente windows (ad eccezione se vogliamo per il framework .NET, ma con Mono ormai è molto agevole anche in ambiente *nix) ed ho scritto poi se ha voglia (è un modo per avvicinarsi anche a sistemi operativi migliori, al di la della programmazione).
I compilatori di cui parli, ma la quasi totalità parlando più in generale, sono basati sempre su gcc, quindi perchè non usare direttamente esso.
Ragione in più allora magari per usare VisualC++ su windows. Poi dipende da cosa uno deve farci, per piccole applicazioni, sicuramente non ci si va ad installare un IDE grosso come VisualC++, si userà qualcosa di più leggero, vedi Code::Blocks. Personalmente poi, non amo gli IDE.
In un IDE è per me fondamentale la capacità di poter valutare il corretto funzionamento del codice. Deve quindi essere possibile leggere l'output del programma senza dover intervenire manualmente con qualche hack. Il fatto che sia necessario ricorrere a soluzioni come system("PAUSE") lo rende per me un bug. È vero che è possibile eseguire il programma via console, ma si tratta di un IDE e il fatto stesso di doverlo aggirare (e di dover andare a cercare l'eseguibile nelle cartelle del progetto 
) per fare qualcosa che dice di fornire (la capacità di eseguire il programma) non è per me accettabile. Che senso ha avere un IDE, se devi chiuderlo per fare una cosa semplice come eseguire il programma?
Non si tratta di una modalità release. Mi sono in realtà espresso molto male. Intendevo semplicemente dire eseguire il programma senza fare il debugging. Fa certamente qualcosa in più per mantenere la finestra aperta, ma è a mio parere una funzionalità necessaria.
Se un IDE sopporta lo sviluppo di applicazioni console, allora devi poter essere in grado di eseguirle al meglio.
Sono d'accordo che un IDE è inutile se viene usato solo un editor di testo. E, infatti, quando parlavo di sviluppo di applicazione multipiattaforma mi riferivo anche all'uso di tutti gli altri strumenti (debugging, testing, analisi statica, gestione delle versioni..) dell'IDE. A patto di fare uso solo di librerie multipiattaforma il codice dovrebbe poter essere compilato anche su altre piattaforme senza grossi problemi. Ma parlando di applicazioni multipiattaforma pensavo più a Visual Studio che Visual C++ in particolare. Con Mono è possibile eseguire molte applicazioni realizzate per il .NET framework (anche se non tutte) e con Visual C# è possibile realizzare giochi per la Xbox360.
A me gli IDE piacciono abbastanza, ma uso Visual C++ solo per progetti di una certa complessità. Code::Blocks è abbastanza leggero ed è abbastanza comodo per progetti medio-corti. Per il C o il C++ raramente uso un editor di testi e la shell (a meno di essere su linux in cui la shell è in effetti più potente e utile). Ma suppongo siano gusti personali.
) per fare qualcosa che dice di fornire (la capacità di eseguire il programma) non è per me accettabile. Che senso ha avere un IDE, se devi chiuderlo per fare una cosa semplice come eseguire il programma?E comunque per la modalità release di cui parli o qualsiasi altra che non presenti questo "problema", non vorrei sbagliare, ma è perchè in fase di compilazione viene comunque aggiunto qualcosa che mandi in pausa momentaneamente il programma.
Non si tratta di una modalità release. Mi sono in realtà espresso molto male. Intendevo semplicemente dire eseguire il programma senza fare il debugging. Fa certamente qualcosa in più per mantenere la finestra aperta, ma è a mio parere una funzionalità necessaria.
Sul secondo punto, corcordo che non sia niente di complicato da implementare, ma ritorniamo al punto che quell'IDE non ha semplicemente tale funzionalità e rimane di fatto che le applicazioni da console, andrebbero utilizzare da essa (altrimenti ti fai un'applicazione con GUI e vai di click quanto ti pare). Ed è un dato di fatto che il normale utente windowsiano, non ha familiarità con la console.
Se un IDE sopporta lo sviluppo di applicazioni console, allora devi poter essere in grado di eseguirle al meglio.
Sul terzo punto, beh se devi scrivere semplicemente il codice e basta con quell'IDE, tanto vale che usi un semplice editor di testo
Sono d'accordo che un IDE è inutile se viene usato solo un editor di testo. E, infatti, quando parlavo di sviluppo di applicazione multipiattaforma mi riferivo anche all'uso di tutti gli altri strumenti (debugging, testing, analisi statica, gestione delle versioni..) dell'IDE. A patto di fare uso solo di librerie multipiattaforma il codice dovrebbe poter essere compilato anche su altre piattaforme senza grossi problemi. Ma parlando di applicazioni multipiattaforma pensavo più a Visual Studio che Visual C++ in particolare. Con Mono è possibile eseguire molte applicazioni realizzate per il .NET framework (anche se non tutte) e con Visual C# è possibile realizzare giochi per la Xbox360.
A me gli IDE piacciono abbastanza, ma uso Visual C++ solo per progetti di una certa complessità. Code::Blocks è abbastanza leggero ed è abbastanza comodo per progetti medio-corti. Per il C o il C++ raramente uso un editor di testi e la shell (a meno di essere su linux in cui la shell è in effetti più potente e utile). Ma suppongo siano gusti personali.
Visto che l'utente che ha aperto il topic ha ricevuto ampiamente risposte riguardo al suo problema, non vorrei andare off-topic, ma dato che il dialogo si è fatto interessantino ed appurato che te lo consideri un bug, io una funzionalità in meno, continuo 
Apatriarca, al di la dei gusti personali, a meno che non lo fai per lavoro e tranne se devi utilizzare librerie unicamente per quell'OS, perchè programmi in ambiente windows ed usi IDE?
Voglio dire, un editor di testo, come in un IDE, ha tutte le funzioncine di autocompletamenteo del testo, ecc, per la parte compilatore, gcc lo trovo più immediato che in un IDE, testare il programma o fare debug, pari o più immediato nella shell visto lavori tutto li dentro, quindi perchè un IDE? Mi riferisco principalmente allla programmazione in C/C++ (magari in java, utilizzare eclipse può avere le sue comodità).
Prendiamo il caso dell'uso di librerie esterne, con gcc basta passare gli appositi attributi nella stringa di compilazione e via. Con un'IDE devi linkargli le librerie andandole a pescare te una per una e a volte, se non spesso, devi passargli parecchi file, perdendo quindi più tempo.
Ovviamente non parlo della gestione di una GUI di un programma, dove può esser comodo si trascinare degli oggetti ed ottenere subito quello che ti serve (cosa che a mio avviso consiglio comunque a chi già conosce le librerie grafiche che va ad usare ad esempio, in modo da velocizarsi solo il lavoro, altrimenti è solo un male).
Anche io ho usato IDE a volte (su windows e compresi quelli di cui si è parlato) per programmare in C/C++, ma ho notato solo che mi rallentava facendo il paragone con editor di testo + gcc, ecc su una distro linux (e parlo di progetti più grossi ovviamente, non di piccolissi). Quindi sarò io che non mi ci sono applicato mai abbastanza magri o un'IDE non è migliore degli altri strumenti citati?
p.s.: ah, so cos'è la "modalità" release, l'ho chiamata così giusto per adattarmi a come l'avevi chiamata te, ma avevo capito che era un modo tanto per definire quella funzionalità.
Apatriarca, al di la dei gusti personali, a meno che non lo fai per lavoro e tranne se devi utilizzare librerie unicamente per quell'OS, perchè programmi in ambiente windows ed usi IDE?
Voglio dire, un editor di testo, come in un IDE, ha tutte le funzioncine di autocompletamenteo del testo, ecc, per la parte compilatore, gcc lo trovo più immediato che in un IDE, testare il programma o fare debug, pari o più immediato nella shell visto lavori tutto li dentro, quindi perchè un IDE? Mi riferisco principalmente allla programmazione in C/C++ (magari in java, utilizzare eclipse può avere le sue comodità).
Prendiamo il caso dell'uso di librerie esterne, con gcc basta passare gli appositi attributi nella stringa di compilazione e via. Con un'IDE devi linkargli le librerie andandole a pescare te una per una e a volte, se non spesso, devi passargli parecchi file, perdendo quindi più tempo.
Ovviamente non parlo della gestione di una GUI di un programma, dove può esser comodo si trascinare degli oggetti ed ottenere subito quello che ti serve (cosa che a mio avviso consiglio comunque a chi già conosce le librerie grafiche che va ad usare ad esempio, in modo da velocizarsi solo il lavoro, altrimenti è solo un male).
Anche io ho usato IDE a volte (su windows e compresi quelli di cui si è parlato) per programmare in C/C++, ma ho notato solo che mi rallentava facendo il paragone con editor di testo + gcc, ecc su una distro linux (e parlo di progetti più grossi ovviamente, non di piccolissi). Quindi sarò io che non mi ci sono applicato mai abbastanza magri o un'IDE non è migliore degli altri strumenti citati?
p.s.: ah, so cos'è la "modalità" release, l'ho chiamata così giusto per adattarmi a come l'avevi chiamata te, ma avevo capito che era un modo tanto per definire quella funzionalità.
"maths91":
... quindi perchè un IDE? Mi riferisco principalmente allla programmazione in C/C++ ...
Solo per dire alcune banalità - si fa per dire - perché gestire le versioni e le piattaforme target diverse, o anche solo i sottoprogetti, "a mano" è un po' macchinoso (solo un po'?!?
); secoli fa mi preparavo dei makefile intricatissimi e se scordavo qualcosa e/o facevo un errore, per venirne a capo impiegavo eoni. Con un buon IDE, una volta che ti sei abituato all'ambiente di lavoro tutte queste problematiche sono ridotte al minimo. Ovviamente ci sono altri vantaggi, che hai noti e che anche apatriarca ha segnalato, pe. il debugging.Certo, manco io uso un IDE se devo fare un programma di media complessità, magari solo su una piattaforma - e gedit effettivamente è molto comodo.
Approfitto del lunghissimo OT per una curiosity:
"apatriarca":poiché mi tocca (sic) anche a me fare applicazioni per periferiche mobile (detta così fa più figo di "cellulari"
Ho utilizzato IDE in grado di mostrare (emulato) il funzionamento di programmi su piattaforme molto diverse da quelle sulle quali stavo sviluppando (cellulari ad esempio).
) con quale ti sei trovato meglio?
Io credo che tu non sia in grado di vedere i vantaggi di un IDE perché non hai dimestichezza con le loro interfacce e con il loro modo di lavorare. Il nome stesso indica come sia un ammasso di tools e funzionalità differenti incluse nello stesso programma per semplificare lo sviluppo. Trovo quindi assurdo affermare che “testare il programma o fare debug, pari o più immediato nella shell visto lavori tutto li dentro, quindi perchè un IDE?” Lavorare tutto lì dentro sembra quasi la definizione di IDE ed è in effetti semplicissimo fare quelle operazioni con un IDE. È sufficiente premere dei tasti. La stessa operazione con una shell mi sembra molto più complicata. È sufficiente leggersi un tutorial per fare il debug in Visual Studio e con gdb per notare quale sia il più semplice. Fai poi l'esempio del linking delle librerie, ma io non vedo alcuna differenza. È anzi l'IDE il più semplice fornendo le funzionalità di make. Una volta che Visual Studio sa dove andare a cercare una cartella (e lo fai solo una volta per ogni libreria e a volte non è neanche necessaria) è sufficiente scrivere l'elenco delle librerie (i nomi) nell'apposita casella di testo nelle proprietà del progetto. In gcc? Che cosa cambia esattamente, se gcc non sa dove prendere la libreria gli devi comunicare la cartella nel quale cercarlo e poi inserire l'elenco delle librerie. E questo lo devi fare tutte le volte a meno di creare un makefile, la cui scrittura richiede maggiori conoscenze che la compilazione di qualche casella di testa in un IDE.
Perché mi piace ogni tanto giocare a qualche videogioco e uso principalmente Windows. Mi occupo poi principalmente di programmazione grafica e uso sia le DirectX che le OpenGL. Infine è un ambiente di sviluppo al quale sono abituato e nel quale sono quindi abbastanza produttivo. Ma nell'ultimo anno ho comunque lavorato principalmente in Java per un applicazione multi-piattaforma e uso NetBeans sia su Windows che su Linux (utilizza librerie native e quindi devo testarlo su diversi SO). Se avessi un Mac utilizzerei anche quello.. Di fatto, non credo di aver mai realizzato un'applicazione console di una certa complessità, lavoro ormai quasi solo con interfacce grafiche di qualche tipo.
Bhe.. in realtà è un sacco che non mi interesso di programmazione mobile. Ma immagino dipenda dalla piattaforma scelta (J2ME, Android, iOS..).
Apatriarca, al di la dei gusti personali, a meno che non lo fai per lavoro e tranne se devi utilizzare librerie unicamente per quell'OS, perchè programmi in ambiente windows ed usi IDE?
Perché mi piace ogni tanto giocare a qualche videogioco e uso principalmente Windows. Mi occupo poi principalmente di programmazione grafica e uso sia le DirectX che le OpenGL. Infine è un ambiente di sviluppo al quale sono abituato e nel quale sono quindi abbastanza produttivo. Ma nell'ultimo anno ho comunque lavorato principalmente in Java per un applicazione multi-piattaforma e uso NetBeans sia su Windows che su Linux (utilizza librerie native e quindi devo testarlo su diversi SO). Se avessi un Mac utilizzerei anche quello.. Di fatto, non credo di aver mai realizzato un'applicazione console di una certa complessità, lavoro ormai quasi solo con interfacce grafiche di qualche tipo.
poiché mi tocca (sic) anche a me fare applicazioni per periferiche mobile (detta così fa più figo di "cellulari" ) con quale ti sei trovato meglio?
Bhe.. in realtà è un sacco che non mi interesso di programmazione mobile. Ma immagino dipenda dalla piattaforma scelta (J2ME, Android, iOS..).
Boh, non vedo questi vantaggi io. Sarà una questione di abitudine, ma anche confrontandomi con altri miei amici che usano IDE principalmente, la mia produttività tutta da console è >= alla loro. Avete parlato entrambi di makefile, se la mettiamo sotto l'aspetto della richiesta maggiore di conoscenze, lo vedo un bene, non un male, quindi sotto questo aspetto, l'IDE è nato per i più pigri? Non vedo poi tutta questa difficoltà nel gestirli, a meno che non scriviate un intero sistema operativo , anche per grossi progetti, quante righe di codice scriverete mai in un makefile?
Lavorare tutto li dentro, non implica parlare di IDE. È il poter lavorare tutto li dentro che mi fa chiedere già: perchè usare un IDE? Il fatto che qualcosa venga creato, non implica necessariamente una sua così reale utilità (mi viene in mente a tal proposito anche il discorso del perchè dei tanti DE, ma vabbè, non andiamo così oltre). Forse anche voi non riuscite a vedere la comodità di lavorare in questo modo perchè siete abituati principalmente ad un IDE.
Per le librerie, in genere una volta installate, basta usare l'apposito attributo che le richiama dinamicamente ed hai fatto, non hai altro da scrivere, quindi la vedo una cosa sicuramente più immediata (senza dovergli "insegnare" dove le librerie sono e senza scrivergliele).
Trovo anche che a volte si perda più tempo nel muoversi con i click, che scrivere in un terminale senza staccare mai le mani dalla tastiera.
Col mio Vim configurato a puntino (come già scritto in un post precedente, volendo si può anche compilare ed eseguire il proprio programma senza uscire da esso), gcc e gdb tanto per cominciare, dormo sonni tranquilli. Poi se vogliamo, diciamo che messi insieme questi strumenti formano uno pseudo-IDE? A maggior ragione, perchè usare un IDE allora (che poi questi IDE son sempre basati su detemrinati strumenti di base)
In definitiva un IDE lo vedrei come un ambiente per facilitare lo sviluppo a chi non ha un certo background di conoscenze richieste altrimenti (questo può essere un bene per far affacciare alla programmazione anche i meno esperti, un male perchè diventa o può diventare una sorta di abitude a "cerchiamo di facciamo sempre più imparando sempre meno", che per me proprio non esiste).
Vabbè, alla fine ad ognuno il suo eheheh.
Rggb, dipende per quali dispositivi mobili devi programmare. Come ti è stato detto, soprattutto oggi come oggi, l'OS incide molto anche sui dispositivi mobili, a differenza del passato dove per lo più programmavi in java e volendo per windows mobile andando sulla fascia degli smartphone. Adesso invece per iOS devi usare Xcode e lavorare su un mac (se devi pubblicarle nel market ufficiale le applicazioni, è d'obbligo), per Android l'accoppiata Eclipse + il loro SDK è sicuramente la miglior soluzione e quasi l'unica, ecc.
, anche per grossi progetti, quante righe di codice scriverete mai in un makefile?Lavorare tutto li dentro, non implica parlare di IDE. È il poter lavorare tutto li dentro che mi fa chiedere già: perchè usare un IDE? Il fatto che qualcosa venga creato, non implica necessariamente una sua così reale utilità (mi viene in mente a tal proposito anche il discorso del perchè dei tanti DE, ma vabbè, non andiamo così oltre). Forse anche voi non riuscite a vedere la comodità di lavorare in questo modo perchè siete abituati principalmente ad un IDE.
Per le librerie, in genere una volta installate, basta usare l'apposito attributo che le richiama dinamicamente ed hai fatto, non hai altro da scrivere, quindi la vedo una cosa sicuramente più immediata (senza dovergli "insegnare" dove le librerie sono e senza scrivergliele).
Trovo anche che a volte si perda più tempo nel muoversi con i click, che scrivere in un terminale senza staccare mai le mani dalla tastiera.
Col mio Vim configurato a puntino (come già scritto in un post precedente, volendo si può anche compilare ed eseguire il proprio programma senza uscire da esso), gcc e gdb tanto per cominciare, dormo sonni tranquilli. Poi se vogliamo, diciamo che messi insieme questi strumenti formano uno pseudo-IDE? A maggior ragione, perchè usare un IDE allora (che poi questi IDE son sempre basati su detemrinati strumenti di base)
In definitiva un IDE lo vedrei come un ambiente per facilitare lo sviluppo a chi non ha un certo background di conoscenze richieste altrimenti (questo può essere un bene per far affacciare alla programmazione anche i meno esperti, un male perchè diventa o può diventare una sorta di abitude a "cerchiamo di facciamo sempre più imparando sempre meno", che per me proprio non esiste).
Vabbè, alla fine ad ognuno il suo eheheh.
Rggb, dipende per quali dispositivi mobili devi programmare. Come ti è stato detto, soprattutto oggi come oggi, l'OS incide molto anche sui dispositivi mobili, a differenza del passato dove per lo più programmavi in java e volendo per windows mobile andando sulla fascia degli smartphone. Adesso invece per iOS devi usare Xcode e lavorare su un mac (se devi pubblicarle nel market ufficiale le applicazioni, è d'obbligo), per Android l'accoppiata Eclipse + il loro SDK è sicuramente la miglior soluzione e quasi l'unica, ecc.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo