Programmazione con emacs invece di un IDE integrato nel debugger [chiuso]

Fondamentalmente, a volte preferisci le cose più strettamente integrate e snelle, a volte vuoi un'integrazione più flessibile con una scelta di parti speranzosamente più ampia.

Suggerimento: il debug a livello di sorgente è disponibile anche tramite gdb .

Ci sono anche vari sistemi di compilazione, alcuni forse superiori a, o più flessibili / estensibili di ciò che è incorporato in VS.

Senza dubbio, avere tutto integrato è spesso conveniente.

In diverse circostanze, è possibile trarre vantaggio dalla possibilità di eseguire un debugger su una macchina remota con due firewall (tramite ssh) o su un piccolo sistema embedded.

Ovviamente non è impossibile integrare vari strumenti in un editor di script; sia Vim che Emacs hanno modalità di interazione con vari debugger, sistemi di compilazione, sistemi di controllo delle versioni, ecc. Alcuni preferiscono questi altri strumenti.

È anche possibile, ovviamente, creare una sorta di sonda di debug remoto o un'interfaccia VCS esotica per un IDE (come VS). Ma questo inizia a diventare sospettosamente simile all'approccio sopra:)

Il punto di forza degli IDE, a mio avviso, è la gestione del codice sorgente superiore: navigazione, refactoring, validazione, supporto di framework, tutto ciò che ti offre una base di codice rappresentata correttamente da AST.

Emacs fa alcune cose molto meglio di altri editor:

1. Ora di avvio. Una delle funzionalità più importanti per un editor è l'ora di avvio. Con IDE è necessario attendere 30 secondi per aprire il progetto e altri 30 secondi ogni volta che si passa a un altro progetto. Emacs si avvia così velocemente che il software di editing è facile.

2. Istanze multiple . Ci saranno più copie di emacs in esecuzione. Non solo ide singolo, ma più copie dell'editor di testo.

3. File di grandi dimensioni. Finirai per avere grandi quantità di codice in un singolo file. Se il tuo editor si rompe quando carica un file di 20kloc, è inutile.

4. Ricerca. Trovare la posizione corretta all'interno del codice deve essere semplice. Il modo giusto per farlo è una corretta ricerca all'interno del file corrente.
5. Navigazione. L'inizio del file è una delle funzionalità più importanti.
6. Goto-line . Quando il compilatore ti dà un errore, ha incluso il numero di riga. goto-line ti permetterà di digitare il numero della linea e trovare immediatamente la posizione corretta nel codice.
7. Buffer. . Sia il file di intestazione che il file .cpp devono essere visibili allo stesso tempo. Buffer di editor multipli con schermo diviso sono essenziali per vedere il codice sorgente.
8. Caricamento di nuovi file. Il passaggio da un file all'altro è raro, ma necessario.
9. Salvataggio. Se il tuo editor perde il codice se modifichi simultaneamente il file da due copie dell'editor, non va bene. Emacs salva il codice correttamente ogni volta.

Gli editor di testo non sono adatti per la compilazione e il debug del tuo codice. Invece, i seguenti strumenti faranno il trucco:

1. La compilazione funzionerà con makefile dal prompt dei comandi. Digitare "make" nel prompt dei comandi farà il trucco.
2. Il debug utilizzerà gdb e valgrind. Entrambi sono utili per ottenere pile di chiamate. Cercando di fare il single-step attraverso il codice è solo una perdita di tempo.
3. Controllo della versione con git.

Nota che questi sono al di fuori dell'ambiente di sviluppo integrato.

Attualmente sto sviluppando software per sistemi embedded e un'applicazione occasionale per PC.

Ho le seguenti applicazioni aperte durante la codifica e il debug:

• XEmacs - Ha delle belle funzionalità che Eclipse non ha. Inoltre non forza un albero dei file su di te.
• Visual Studio - Nice debugger. Può scrivere programmi di console da testare funzioni incorporate.
• Test Parasoft C / C ++ - Un analizzatore statico costruito sul telaio Eclipse lavoro. Può modificare compilare usando il compilatore di destinazione; ma non può accedere al debugger JTAG sul dispositivo di destinazione.
• IAR EWARM - IDE con capacità di parlare con un debugger JTAGJet al nostro piattaforma di destinazione. Debugger decente, integrato nel processore di destinazione lingua, ma manca l'analisi della piattaforma statica.
• Finestra di comando - Per eseguire gli script di analisi statica di Coverity.
• Terminale Cygwin - Unix ha funzioni interessanti come find e grep.
• UltraEdit - utilizzato per modificare i file batch; può stampare la sintassi evidenziata codice sorgente con numeri di linea per stampanti a colori!
• PTC - Sistema di gestione dei codici per il controllo dei file in entrata e in uscita.

Non riesco a trovare "una vera GUI", quindi ho più applicazioni aperte. Trovo Eclipse molto piacevole per Java e un dolore per C o C ++.

Sono anche cresciuto programmando prima che venissero inventati gli IDE. Quindi, si dovrebbe modificare il file, chiudere l'editor, quindi creare utilizzando un sistema a riga di comando (come make).

Molte GUI che ho visto stanno provando a vendere il set di catene di strumenti di un'azienda. O da tutti gli strumenti per ottenere la loro buona GUI o nulla.

In sintesi, sviluppo codice rimbalzando nelle applicazioni. Non esiste un IDE completo che contenga tutte le funzionalità per la programmazione di un sistema embedded e abbia caratteristiche che mi piacciono e alcune delle quali non mi piacciono.