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".

Illustration: Privatfoto

](http://www.version2.dk/modules/xphoto/cache/64/2064_1000_1000.png)

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.

](http://www.version2.dk/modules/xphoto/cache/66/2066_2275_2275.png)

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 = 2
a;
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=")

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Poul-Henning Kamp Blogger

TAGS blev oprindeligt opfundet til vi(1) og relevante operativsystemer har det naturligvis indbygget så man ikke skal installere virtuelle operativsystemer som emacs for at kunne bruge TAGS.

Poul-Henning

PS: Af en eller anden grund lyder dit PPS for mig som noget Bettemus ville sige til Garfield.

PPS: Men det er da rart at du har ambitioner :-)

  • 0
  • 0
#2 Martin Toft Bay

Spændende indlæg :-) colorgcc skal jeg da helt klart prøve. Det piner mig lidt, at kampen altid er mellem emacs og vi, hvor jeg synes vim har en større chance for at "forsvare" sig overfor emacs. Det kan selvfølgelig skyldes, at vi=vim i mange Linux-distributioner... Og hvis man er af den opfattelse, så bør man nok prøve en ægte vi ;-)

Der er en fejl i linket til CodeBlocks ("tp//" skal vist fjernes).

  • 0
  • 0
#4 Peter Toft

Tak Martin med det flotte efternavn. URL rettet.

Colorgcc er super rart! Emacs og vi - tja, det er to meget forskellige ting designmæssigt - begge har sin ret ligesom f.eks. nano nedit og andre.

P.S. Jeg er en dag ældre i dag og ikke ret sur :)

  • 0
  • 0
#6 Esben Damgaard

Jeg må give dig ret i at CodeBlocks virker meget lovende, og udviklingen går med et ganske fint tempo. Det er dog stadig umodent, men lige tilpas til det D-programmering jeg laver engang i mellem. Udviklerne er også hurtige til at rette bugs, så det er bare med at sende dem ind. Det er helt sikkert et program jeg vil holde øje med.

  • 0
  • 0
#7 Kenneth Geisshirt

Flymake er et ganske godt minor mode til Emacs. På min Ubuntu 8.04 med Emacs 22 virker det rimeligt. Perl-kode virker perfekt, og jeg har fået C-kode til at virke. Tricket er at have en Makefile med et særligt target:

check-syntax: gcc -o nul -S ${CHK_SOURCES}

Jeg har stadig ikke fået Flymake til at virke med LaTeX - endnu.

/kneth

PS. Jeg har opgivet flamewars med vi(1)-brugere - de er fortabte. PPS. Men jeg gider godt at tage en flamewar med XEmacs-brugere :-) PPPS. Jeg kan kun anbefale vi(1)-brugere at læse Kims bog "Hacking Vim" - http://www.packtpub.com/Vim/book

  • 0
  • 0
#8 Kenneth Geisshirt

Jeg glemte de andre godter ;-)

org-mode til Emacs er genialt til at organisere notater. Især at det er muligt at folde ind og ud vha. TAB.

Pto nævner at han bruger TAB til indryk (indent) af sin kode. Jeg hører til dem, som mener at TABs i kode er ondt, så jeg har sat følgende i min .emacs: (setq-default indent-tabs-mode nil)

Når jeg rigtig skal more mig, bruger jeg ERC til at chatte i IRC - men det hører nok til den mere aparte morskab.

  • 0
  • 0
#9 Dennis Krøger

Pto nævner at han bruger TAB til indryk (indent) af sin kode. Jeg hører til dem, som mener at TABs i kode er ondt, så jeg har sat følgende i min .emacs: (setq-default indent-tabs-mode nil)

Eh, når man bruger tab-tasten i Emacs, indsætter den som standard enten spaces eller tabs så det passer til den valgte c-style (om det bliver spaces eller tabs er også afhængigt at c-style).

  • Men alle og enhver ved jo at tabs er spaces langt overlegent, og at GNU c-style spiser små børn som mellemmåltid. ;p
  • 0
  • 0
#10 Kenneth Geisshirt

Eh, når man bruger tab-tasten i Emacs, indsætter den som standard enten spaces eller tabs så det passer til den valgte c-style (om det bliver spaces eller tabs er også afhængigt at c-style).

Nu koder jeg nok mest Perl og Javascript for tiden, og kode-standarden i min arbejdsgruppe er 4 spaces og ikke 1 tab.

Kodestil (eller code standards) er jo også et herligt emne at kaste sig ud i. Skal f.eks. { stå på samme linje som if eller skal det står på næste linje?

  • 0
  • 0
#12 Thomas Ammitzbøll-Bach

Da jeg lærte C, var det stringent undervisning efter K&R, og derfor falder K&R stil mig mest for.

Der er nogle fordele ved trække venstre-tuborgen op, nemlig at en større del af logikken kan ses på skærmen af gangen. En anden fordel er, at man sjældent laver den tanketorsk, at får placeret et semikolon som afslutning på en if- eller en while-linie, der som bekendt er en skidt ting.

Personlig er jeg tilhænger af indrykning med TAB. Årsagen er, at man individuelt kan arbejde med 2, 3, 4, 8 eller 19 tegncellers visning, uden at det påvirker andre end en selv. (Som man siger: Det er jo ikke TAB'ens størrelse, det kommer an på)

Personlig synes jeg, at der er langt mere interessante stil-diskussioner end det typografiske: Må man returnere fra en betingelse eller skal alle returneringer ske fra en returlinie? Skal variable tildeles alene i if- eller else-delen, eller tildeles den inden og kan ændres i en efterfølgende if-del? Er en betinget break som midtvejsudbrud af en while-løkke helt ok, eller skal det helst undgås? Når man kommer ud i de diskussioner, så falmer de typografiske diskussioner noget, alene af det at omformatering kan gøres maskinelt på et øjeblik.

Jeg har brugt både Emacs og vi(m), men jeg er landet i at kun bruge Vim, da jeg kun kan rumme en editor i mit lille hovede, og der er alt for mange Unixer og unixoider, der ikke har Emacs. Men klart Emacs, hvis man fortrinsvis har det samme miljø. Hvem kan klare sig uden en editor med mailreader, webbrowser og psykoterapeut? Det er jo det, de unge vil ha'...

Thomas

  • 0
  • 0
#13 Frederik Ellehøj

Hej Peter.

Jeg tror dine problemer med at få flymake til at virke stammer fra colorgcc. Tilsyneladene kan colorgcc ikke lide relative stier, og det giver problemer for flymake. Prøv at slå colorgcc fra, og se om det ikke hjælper.

  • 0
  • 0
Log ind eller Opret konto for at kommentere