Mit C/C++ programmeringsmiljø

Jeg sidder for tiden med en stor klump C-kode, hvor jeg laver masser af pointer-snask fra en masse kilder, hvilket det har gjort, at jeg har tænkt en del over de ting jeg kan spare tid og energi med. Dels har jeg stor glæde af min editor, men jeg har også snøren ude efter hele min build-håndtering og mine måder at finde fejl på. Det vil jeg gerne fortælle lidt om i dette blog-indlæg.

Jeg ved udmærket godt at vi kan tage den sædvanlige flamewar omkring Emacs og Vi, og jeg bruger begge :) Men til at arbejde med C/C++ kode, så foretrækker jeg klart Emacs.

Dels fordi jeg kan rigtig mange af de smarte features i Emacs (ca. 2% G). Det der klart hjælper mig meget er kombinationen med "etags". Jeg kører følgende i roden af min projekt: $ etags -T find . -name "*.[c|h]" | xargs hvorved jeg får en TAGS fil med fuldt index over kodens funktioner og data-strukturer. I emacs kan jeg stille mig på et funktionskald og trykke alt-. (alt og punktum) hverefter kildekoden med definitionen af funktionen hentes ind. Jeg kan således hoppe rundt til samtlige funktionskald på nem vis. Jeg kan også hoppe til definitionen af typedef-strukturer. Meget meget nyttigt.

Jeg har syntaks-visning med min ~/.emacs fil, som I kan hente fra http://pastebin.org/38452, så kode-linier indenteres med et tryk på tabulator-tasten.

Når jeg debugger foregår det ofte i DDD, som er en grafisk front-end til GDB. DDD har to fordele fremfor GDB - man orienterer sig lidt nemmere i koden, og data-inspektion er langt nemmere. F.eks. hvis man vil se en datastruktur løbende, kan man med "graph display" se simple variable eller structs. Det er ret nemt - eneste lettere besværlige del er at man manuelt skal bruge "graph display *a @ 10", hvis man vi se de første 10 elementer et array "a".

Det har i et stykke tid irriteret mig meget at når jeg kørte "make" på mit projekt, så var min Makefile indrettet sådan at den kørte videre fra et katalog til det næste også selvom der var en fejl i et af de forrige kataloger. Dette blev senere rettet ved at indføje "set -e" i den løkke jeg håndterede kataloger, men problemet at spotte fejl gjorde at jeg tænkte meget på at få fejl vist mere tydeligt. Og naturligvis havde andre tænkte samme tanker før mig :) Jeg har haft stor glæde af colorgcc, som er et Perl-script, der netop giver farver på fejl eller advarsler fra gcc/g++. Det gør det markant nemmere at se fejlene. Det kan bemærkes, at jeg på min Ubuntu 8.04 workstation hjemme måtte rette "warning" til "advarsel" i colorgcc-scriptet for at få advarsler vist anderledes end fejl. Grunden er at jeg (åbenbart) har danske fejlmeddelelser. Man kan lave en ~/.colorgcc hvor man tilpasser farver alt efter baggrund i terminalerne.

Min erfaring er at langt de fleste fejl jeg arver fra andre - eller mine egne - er runtime pointerfejl, typisk arrays, der bliver skrevet over grænsen. Når man laver digital signalbehandling, som jeg gør det, så er ens kode plastret til med arrays....

Jeg har tidligere anvendt Insure++ og Purify, men efterhånden anvender jeg stort set valgrind alene. Til eksempel har jeg følgende slemme kode med linienumre.

1: float ex2(float a) 2: { 3: float c; 4: *c = 2a; 5: return *c; 6: }

hvor "valgrind " giver følgende output, der peger direkte på den grimme linie 4 - tak. Masser af tid sparet i praksis...

pto@shogun:~/c/tester > valgrind ./a.out

 
==4837== Memcheck, a memory error detector.
==4837== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==4837== Using LibVEX rev 1804, a library for dynamic binary translation.
==4837== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==4837== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==4837== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==4837== For more details, rerun with: -v
==4837== 
==4837== Use of uninitialised value of size 4
==4837==    at 0x80483EA: ex2 (ex2.c:4)
==4837==    by 0x80483CA: fct (mainlib.c:9)
==4837==    by 0x8048391: main (main.c:6)
==4837== 
==4837== Invalid write of size 4
==4837==    at 0x80483EA: ex2 (ex2.c:4)
==4837==    by 0x80483CA: fct (mainlib.c:9)
==4837==    by 0x8048391: main (main.c:6)
==4837==  Address 0x3f800000 is not stack'd, malloc'd or (recently) free'd
==4837== 
==4837== Process terminating with default action of signal 11 (SIGSEGV)
==4837==  Access not within mapped region at address 0x3F800000
==4837==    at 0x80483EA: ex2 (ex2.c:4)
==4837==    by 0x80483CA: fct (mainlib.c:9)
==4837==    by 0x8048391: main (main.c:6)
==4837== 
==4837== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 11 from 1)
==4837== malloc/free: in use at exit: 0 bytes in 0 blocks.
==4837== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==4837== For counts of detected errors, rerun with: -v
==4837== All heap blocks were freed -- no leaks are possible.
Segmentation fault

Når jeg igennem flere år har kigget på udviklere som har døjet med Microsoft Visual Studio, så har jeg tilsvarende glædet mig over ikke at skulle ind og pille i det syge build-styring, som MVS har. MEN modsat, så tror jeg det er værd at følge CodeBlocks, som virker lovende. Det virker lidt umodent endnu, men projektet har så vidt jeg kan se de rigtige takter til at det bliver godt. Modsat så jeg aldrig rigtig været glad for KDevelop, som lå stille et par år - men nu er gået meget mod at være en KDE udviklingsplatform. Fint - det er bare ikke det jeg laver.

Er der nogen af jer som bruger disse' Eller noget andet'

Jeg vil meget gerne høre hvad I anvender af værktøjer

/pto

P.S. til Kneth - jeps, jeg har stadig ikke fået flymode til at virke under Emacs... P.P.S. men jeg er ikke så gammel og sur som PHK ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")