Ambiente di sviluppo per C

Alla ricerca di idee sulla creazione di un ambiente di sviluppo conveniente e produttivo per lo sviluppo C. Ho trovato molto utile l' editing in C con Vim, ma vorrei ottenere un campione più ampio di suggerimenti.

• Emacs / Vim / Eclipse / ... - Personalmente sono un utente Emacs. Se trovi che le sequenze di controllo stancano il tuo mignolo, basta solo Viper-Mode. Emacs è così ben integrato in unix, rendendo molto semplice il controllo di tutto da un'unica posizione. Anche Vim fa un buon lavoro qui, ma trovo che Elisp sia un linguaggio di estensione molto più potente di Vim Script. Si potrebbe parlare per ore di tutti i modi per impostare Emacs per lo sviluppo C. La modalità Flymake è stata menzionata ed è un super inizio per le cose. Non ho familiarità con Eclipse, non trovo che lasci abbastanza spazio sul mio schermo per il codice, né mi piace quanto sia gonfio (gli utenti di Vim diranno la stessa cosa su Emacs). Sono anche ingiustamente parziale nei confronti di qualsiasi cosa scritta in Java, per motivi puramente estetici.

• Ctags - Tagga le tue funzioni C (o molte altre lingue) in modo che Vim o Emacs o qualsiasi altra cosa possa fare un po 'di collegamento ipertestuale nei tuoi file. Supponiamo che tu vada in giro e vedi una funzione e ti gratti la testa dicendo "Cosa fa di nuovo quello? La denominazione è un po 'vaga". Plink-plank-plunk, puoi fare zapping direttamente alla sua definizione.

• Cmake / Gnu-Autotools - Make è fantastico, ma a un certo punto devi astrarre un po 'le cose in modo che il tuo progetto possa costruirsi su tutti i tipi di sistemi per i quali non hai modo di testare. Se hai solo bisogno di persone per costruire il tuo codice su un * nix, Autotools è fantastico, ma, in realtà, dovresti comunque familiarizzare con Cmake. Il team di Cmake crea il codice in ogni possibile configurazione e si assicura che non si debba affrontare il mal di testa. Se vuoi che il tuo progetto venga facilmente raccolto, acquista altri, uno di questi strumenti è cruciale.

• Git / Mercurial / Subversion / ... - Potresti passare mesi a cercare software per il controllo delle versioni, ma probabilmente dovresti semplicemente andare con Git. È solido, distribuito, il kernel @ $! #% E Linux viene tracciato con esso. Se è abbastanza buono per Linus, deve essere abbastanza buono per te. Sento anche cose positive su Mercurial, apparentemente G ** gle le usa, quindi probabilmente non è male. Ad alcune persone sembrano piacere Subversion e CVS e quant'altro. Non mi piacciono perché sono monolitici, il che per me è molto scomodo e limitante.

• Stumpwm / wmii / XMonad / ... - A un certo punto ti renderai conto che qualsiasi cosa tu possa fare per mantenere il tuo flusso di lavoro migliorerà notevolmente il tuo output. Uno dei modi migliori per impedire al cervello di rompere il suo contesto è quello di passare ai gestori di finestre affiancate da TASTIERA. Sono un fan personale di StumpWM , l'Emacs dei gestori di finestre. Completamente implementato in un processo Common Lisp al volo personalizzabile, tutto ciò che ti ritrovi a fare ripetutamente può essere bandito in funzioni e associato a comandi. Roba fantastica. Non ne so molto di nessuno degli altri, ma forse un'ulteriore elaborazione è meglio lasciare ad un altro thread. UTILIZZARE LA TASTIERA MOLTO POSSIBILE.

• GDB - Non ho familiarità con altri debugger, ma questo sembra essere lo standard di fatto.

• Valgrind - Non conosco nient'altro che faccia ciò che fa così bene. Valgrind è cruciale per tutte quelle fastidiose cacce di profiling / perdita di memoria che vuoi continuare. Non puoi semplicemente scrivere codice con malloc / calloc senza Valgrind.

Ho persistito con Vim per un po ', vale la pena conoscere le basi di VIM poiché troverai sempre una scatola UNIX da qualche parte che ha solo quello, ma ho provato Emacs e non ho guardato indietro. Eclipse è un'alternativa "moderna", ho tutte e tre le cose sul mio sistema!

È una preferenza personale, quindi non credo di poter fare molto di più che dirti quello che uso. Ho Emacs impostato con la modalità Flymake , che periodicamente compila il file su cui stai lavorando e analizza l'output del compilatore per capire quali errori hai commesso. Rileva gli errori / avvisi nel buffer e mostra il messaggio di errore del compilatore associato

Uso Kate (testo) gcc / avr-gcc e make, con Git come VC. Faccio principalmente cose integrate in c e lato computer in Python.

Se stai sviluppando C in Unix / Linux, devi assolutamente usare Cscope se il progetto ha dimensioni significative.

Cscope è uno strumento di sviluppo per la navigazione del codice sorgente - passa alla foobardefinizione della funzione, trova tutti i luoghi in cui si foofa riferimento alla variabile , trova tutti i file inclusi bar.h, cambia tutte le occorrenze barin in baz, ecc.

Inoltre, hai menzionato Vim nel tuo post ... ecco un tutorial sull'uso insieme di Vim & Cscope.

Puoi usare il pacchetto Netbeans C / C ++ che funziona con G ++ / GCC:

netbeans.org/features/cpp

il mio preferito è exVim . Ha un sacco di plugin VIM che lo rende molto facile da usare con una base di codice di grandi dimensioni. Prenderò circa 1 giorno per apprenderne le caratteristiche ma ne varrà la pena.

Modifica C con Vim nella console. Impiego makefile e ho un numero di compilatori per testare il mio codice, tra cui gcc, clang (LLVM) e icc. Altre cose che considero parte del mio ambiente di sviluppo: l'uso di grep, debugger e valgrind. Un linguaggio di scripting per build più complicate. Git per il controllo della versione.

Più importante nella mia mente di quello che usi per modificare il codice è come strutturi il tuo codice. Come spiegarlo è probabilmente una domanda per Stack Overflow, ma, come mi hai chiesto, spesso ho una directory separata per il codice oggetto non per la distribuzione e un'altra cartella per il binario risultante (y | ies). Ho una cartella di test che contiene più file C che usano tutto il codice generico che sto scrivendo e questi valgrind, insieme al file di progetto finale.

Puoi provare Motor IDE . È basato sulle maledizioni, quindi dovresti sentirti come a casa (tm). È anche un po 'triste perché non viene mantenuto per 5 anni, quindi qualcosa potrebbe essere rotto. Anche se ancora - credo che valga la pena provare.

Uso gedit con terminale incorporato.