Kodernes opbygning

Tags:    c++

Jeg har fået en vane med kun at have én cpp fil der inkludere én main header fil, der så inkludere de enkelte moduler der repræsenteres med en header fil hver. Personligt synes jeg det giver en mere overskuelig kode da man derved kan indsætte klassernes funktioner direkte i header filen i stedet for at have dem i en seperat cpp fil.

Er der nogen ulemper ved denne metode?

// Your brain is your weapon, do not waste it!!



8 svar postet i denne tråd vises herunder
0 indlæg har modtaget i alt 0 karma
Sorter efter stemmer Sorter efter dato
Er der nogen ulemper ved denne metode?


På den måde skal du oversætte hele programmet hver gang. Hvis dit program bliver stort kan det blive et problem.

Du har heller ikke meget indkapsling på den måde, alle vil vide alt om alle andre.

Men til små projecter er det en rimelig metode.



Du har heller ikke meget indkapsling på den måde, alle vil vide alt om alle andre.


Hvordan du stiller koden op har da intet med den endelige kode at gøre? Alt det der er private vil stadig være private osv... Tror ikke helt jeg er med på hvad du mener :S

// Your brain is your weapon, do not waste it!!



Hvis man bruger "virtuelle base class'er" og "virtuelle constructoer/class factories" vil man kunne lave en indkapsling.

Ideen er at man i foo.h har:
Fold kodeboks ind/udKode 


Og i foo.cpp:
Fold kodeboks ind/udKode 

main.cpp kunne være:
Fold kodeboks ind/udKode 

Så vil main.cpp kun kende FooInterface, og ikke Foo, og dermed heller ikke Foo's private.

Ofte vil man også have class'er der kun er kendt af dele af programmet. Hvis man f.ex. har et typisk skole eksempel med læsfil, process/GUI, skrivfil, vil process/GUI ikke have brug for at kende til filer, og læsfil og skrivfil vil ikke behøve at kende til GUI.



Hmm.. Det ser jo meget godt ud, men har alligevel lidt svært ved at sætte mig ind i hvad 'extern' gør, helt nøjagtigt. Du bruger den når du definerer funktionen, men gør ikke udtrykket til en del af klassen. Derfor ser jeg det som en hel normal definition da det jo er ganske normalt at definere noget i en header, og så have funktionen i en anden cpp fil. Hvordan er det lige 'extern' spiller ind?

// Your brain is your weapon, do not waste it!!



Da også absolute nemmere kode at læse.

--------------------------------------------------
Regards Rasmus Hamberg



extern gør i denne sammenhæng intet. Kompileren ignorerer den.

Jeg bruger extern på funktions prototyper for at markere at de er implementeret i en anden fil.



Da også absolute nemmere kode at læse.


Dér synes jeg så rent faktisk at er mere overskueligt, hvis man har én fil til hver modul af koden - som jeg beskrev tidligere. På den måde skal man ikke lede længe efter det der skal redigeres da definitionerne altid er i toppen, og koden lige nedenunder.

Jeg bruger/brugte det meget til klasser og structs, hvor de implementerede funktioner så bliver indsat længere nede i header filen. "Brugte", fordi jeg ikke kan modargumentere det første der blev sagt af Bertel Brander: "På den måde skal du oversætte hele programmet hver gang. Hvis dit program bliver stort kan det blive et problem."

extern gør i denne sammenhæng intet. Kompileren ignorerer den.

Jeg bruger extern på funktions prototyper for at markere at de er implementeret i en anden fil.


Hmm, lyder lidt spøjst.. Er det ikke en selvfølge at koden er i en anden fil, hvis man altid benytter sig af opdelingen mellem cpp filer og header filer? :P

// Your brain is your weapon, do not waste it!!



Hmm, lyder lidt spøjst.. Er det ikke en selvfølge at koden er i en anden fil, hvis man altid benytter sig af opdelingen mellem cpp filer og header filer?


Ja, og nej.

Man kan godt have prototyper i c++ filer, disse prototyper kan så være for extern eller ikke extern funktioner, og de kan være static.

Variable erklæret i headerfiler er (normalt) extern, så det er vel logisk at funktions prototyper også er extern.

Men som sagt, extern foran prototyper bliver ignoreret af kompileren.



t