02. april 2005 - 17:07Der er
5 kommentarer og 1 løsning
En header til mange cpp filer
Hej eksperter
Jeg er begyndt at lege lidt med at få en gennemgående kodestil, og søger derfor inspiration i andres koder. Pt kigger jeg på koden til borwseren links.
Nu har jeg ikke nogen erfaringer med store projekter så jeg har svært ved at sige om noget det vil være dumt i denne sammenhæng.
Programmøren bag links har gjort det at han har en header fil ved navn links.h Heri står alle funktionerne mm så erklæret. Funktionerne er dog ikke i samme .c fil men derimod delt ud i url.c connect.c mm. Selv har jeg i de små ting jeg selv lavede altid haft en headerfil pr .cpp fil.
Når jeg sidder og kigger på det lige nu vil jeg mene at det er en god ide, fordi det jeg synes det giver et godt overblik over alle funktionerne filerne mm. Men som sagt jeg kan ikke sætte det ind i et større projekt og være kritisk.
Er der en, der har erfaringer med større projekter, der gider fortælle mig om hvorvidt det er en smart måde at gøre tingene på?
I "gamle" C dage ville man dele sit program op i nogle logiske blokke, for hver del ville man lave én headerfil, der skulle inkluderes af brugerene af blokken. I C er der en rimelig ren afgrænsning mellem implementation (code) og interface (header-fil).
I C++ er der typisk ikke nogen ren grænse mellem implementation og interface, da interfacet typisk er en class, og class'en inkluderer også erklæringer af private funktioner og variable, som ikke er interface men implementation. Derfor er C++ headerfiler normalt meget større end C headerfiler, og man skal også typisk inkludere meget mere i C++, da man skal inkludere typedefinitioner for private members.
Dette kunne tale for at man bruger én headerfil pr. flere C-filer men en headerfile for hver C++ fil.
Man bør også overveje at adskille implementation og interface i C++, det kan gøres ved at lave en "virtual base class" (dvs. en class med kun virtuelle funktioner), som er den class der ses af brugerene, og så lave en nedarvning af denne base class til implementation. Dette kan/bør kombineres med en "factory".
Jeg foretrække at se en header som et interface til en blok af funktionalitet, og ikke til en class.
.h og .lib/.a ses af ham der skal bruge din kode og for ham er det vigtigt at der kun er en enkelt - han skal bruge en klump funktionalitet - og det er mest logisk at det er samlet
.c/.cpp filerne skal kun bruges udvikleren/udviklerne af klumpen - og han/de har derfor frihed til organisere de filer som man finder mest optimalt. Hvis der kun er 100 linier totalt kan jeg ikke se nogen grund til at dele dem op i mere end en fil selvom det er flere klasser. Men store filer på f.eks. 2500 linier er trælse at arbejde med.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.