/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
[C] Headerfiler
Fra : Mikael W. Bertelsen


Dato : 10-08-03 12:39

Er der nogen der kan henvise til en dokument der præcist og entydigt
beskriver hvad der skal i en headerfil og hvad der skal i en c-fil?

Jeg tænker på hvad der skal i headerfilen af variable og definitioner oa, og
dermed også hvad der skal blive i c-filen.

Er ovenstående evt. en del af nogle coding styles?

På forhånd tak.

/Mikael

 
 
guppy (10-08-2003)
Kommentar
Fra : guppy


Dato : 10-08-03 14:56

Der er ikke nogen standart for det, så et præcist og entydigt svar får du
nok ikke, men her er der da lidt om det:
http://www.gamedev.net/reference/programming/features/orgfiles/

"Mikael W. Bertelsen" <spam@tuxpower.dk> wrote in message
news:bh5b0d$sst3c$1@ID-177155.news.uni-berlin.de...
> Er der nogen der kan henvise til en dokument der præcist og entydigt
> beskriver hvad der skal i en headerfil og hvad der skal i en c-fil?
>
> Jeg tænker på hvad der skal i headerfilen af variable og definitioner oa,
og
> dermed også hvad der skal blive i c-filen.
>
> Er ovenstående evt. en del af nogle coding styles?
>
> På forhånd tak.
>
> /Mikael



Mikael W. Bertelsen (10-08-2003)
Kommentar
Fra : Mikael W. Bertelsen


Dato : 10-08-03 16:37

guppy wrote:

> Der er ikke nogen standart for det, så et præcist og entydigt svar får du
> nok ikke, men her er der da lidt om det:
> http://www.gamedev.net/reference/programming/features/orgfiles/

Mange tak for linket!

Jeg vil kigge på det.

/Mikael

Bertel Lund Hansen (10-08-2003)
Kommentar
Fra : Bertel Lund Hansen


Dato : 10-08-03 15:07

Mikael W. Bertelsen skrev:

>Er der nogen der kan henvise til en dokument der præcist og entydigt
>beskriver hvad der skal i en headerfil og hvad der skal i en c-fil?

Man bruger den slags til at lave en modulopdeling. Princippet er
at h-filen er offentlig og c-filen er hemmelig. Så i h-filen skal
der stå de erklæringer, funktioner og evt. variable som
programmøren må bruge i sit hovedprogram. I C-filen står den
'hemmelige' kode og de interne variable som han ikke må pille i.

F.eks. kan man forhindre overløb ved arrays ved kun at eksportere
metoder til at ændre tælleren og så holde den egentlige tæller
hemmelig.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Mikael W. Bertelsen (10-08-2003)
Kommentar
Fra : Mikael W. Bertelsen


Dato : 10-08-03 16:44

Bertel Lund Hansen wrote:

> Mikael W. Bertelsen skrev:
>
>>Er der nogen der kan henvise til en dokument der præcist og entydigt
>>beskriver hvad der skal i en headerfil og hvad der skal i en c-fil?
>
> Man bruger den slags til at lave en modulopdeling. Princippet er
> at h-filen er offentlig og c-filen er hemmelig. Så i h-filen skal
> der stå de erklæringer, funktioner og evt. variable som
> programmøren må bruge i sit hovedprogram. I C-filen står den
> 'hemmelige' kode og de interne variable som han ikke må pille i.
>
> F.eks. kan man forhindre overløb ved arrays ved kun at eksportere
> metoder til at ændre tælleren og så holde den egentlige tæller
> hemmelig.
>

Ja, ok, jeg havde ikke lige tænkt på det i den retning (hemmelig/offentlig),
selvom det i realiteten er det jeg gør.

Jeg kan efterhånden konkludere at der ikke er nogen fast standard inden for
dette område, så at få sat ovenstående ord/beskrivelse på er kærkommen.

Tak for indsatsen!

/Mikael


Niels Teglsbo (10-08-2003)
Kommentar
Fra : Niels Teglsbo


Dato : 10-08-03 21:53

Bertel Lund Hansen <nospamfor@lundhansen.dk> wrote:

> Man bruger den slags til at lave en modulopdeling. Princippet er
> at h-filen er offentlig og c-filen er hemmelig.

Hvis man i stedet taler C++ kan det godt være lidt besværligt.

Man skal have de offentlige metoder erklæret, så derfor må man også erklære
klassen, og når man erklærer den, er man nødsaget til også at erklære de
private metoder og variable.

Fx:

class A {
public:
   int increase();
private:
   int getCount();
   int counter;
}

En måde at slippe for det, er at lade den implementerende klasse (B)
nedarve den implementerede klasse (A). Så skal man bare have en factory til
at give et objekt af type B, men det kan jo være en funktion i A.

Er der en smart måde at gøre det på?

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

Jonas Meyer (10-08-2003)
Kommentar
Fra : Jonas Meyer


Dato : 10-08-03 22:58



Niels Teglsbo (10-08-2003)
Kommentar
Fra : Niels Teglsbo


Dato : 10-08-03 23:41

Jonas Meyer <meyer@diku.dk> wrote:

> > Er der en smart måde at gøre det på?
> "the pimpl idiom"
> http://www.gotw.ca/gotw/024.htm
> Det er stadig lidt besværligt at gøre(en del tastearbejde),
> men der er mange fordele ved metoden.

Pimpl-idiomet har faktisk lidt til fælles med det jeg foreslog (mon også
det kaldes noget?).

I Pimpl har man metoder, der kalder andre metoder. I det jeg foreslog har
man virtuelle metoder.

Pimpl har to forskellige objekter og et behov for selv_-pointer engang i
mellem, men til gengæld kan man nøjes med konstruktøren til oprettelse. Med
mit foreslag skal man have en factory-metode, men så har man til gengæld
kun ét objekt, og en factory kan være en fordel af andre grunde.

Jeg har forresten brugt pimpl-idiomet (uden at kende navnet selvfølgelig),
det var et socket, der havde et forbindelsesobjekt.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408924
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste