🚀 go-pugleaf

[knip]
> Wow, ik denk dat ik het hier verkeerd voor heb.  Eerst even een vraagje
> voor de duidelijkheid: wat veronderstel jij dat er in je headerfiles
> staat?  Enkel hoe de functies er uit zien (zonder body) of m�t de body
> van de functies er bij?  Als je veronderstelt dat in je headerfiles ook
> de body van de functies uitgewerkt staat kan ik in je redenering komen.
> Als je echter in je headerfiles enkel de  beschrijving (zonder body) van
> je functies zet, moet ik volgens mij toch die #include "sub.c"
> schrijven.  Als leidraad gebruik ik 'Practical C Programming' van
> O'Reilly en op pagina 305 heeft men het toch over 3 soorten files:

Ik heb het vermoeden dat je niet weet hoe een linker werkt. Jij
verondersteld dat de compiler alle .c files gelinkt moet heeft staan in 1
main bestand, maar dat is belist niet waar. Voorbeeld:

main.c  <--- hoofd bestand
sub.c <--- sub bestand
sub.h <---- header voor sub bestand

main.c include sub.h. Sub.c include eveneens sub.h.

Hoe compileert de compiler dit nu? Eerst wordt main.c geinclude. Main.c
importeert de definities van de functies in sub.h. De compiler weet nu dus
welke functies er in sub.c zitten, zonder die file te includen. Sub.c wordt
gecompileerd met de zelfde definities van de functies. Main.c en sub.c weten
nu beide van het bestaan van de functies af.

Aan het eind van het compilatieproces hou je main.obj en sub.obj over. Beide
files hebben de definities voor elkaars functies in zich. Nu gaat de linker
aan de slag, vindt de overeenkomende functie definities en koppelt ze aan
elkaar.

Ik hoop dat het zo duidelijk is.

Floris