Antwoord.

Het compilatieproces van een C-programma bestaat uit verschillende fasen: preprocessing, compilatie, assemblering en linking. Historisch gezien maakte deze indeling het mogelijk om verantwoordelijkheden tussen tools te scheiden en het onderhoud en de configuratie van het buildproces te vergemakkelijken.

Probleem: Als men niet begrijpt hoe elke fase werkt, kan men fouten tegenkomen zoals 'undefined reference', code duplicatie, onduidelijke bugs door verkeerd gebruik van macro's en problemen bij het schalen van de code over meerdere bestanden.

Oplossing: Men moet begrijpen dat elke fase een specifieke functie uitvoert: de preprocessor verwerkt de #define-, #include- en andere directieven, de compiler vertaalt de C-code naar assembler, de assembler naar machinecode, en de linker voegt alle objectbestanden en bibliotheken samen in het uiteindelijke uitvoerbare bestand.

Codevoorbeeld:

Fragment van de broncode:

#include <stdio.h>
#define PI 3.14

int main() {
    printf("%f
", PI);
    return 0;
}

Voorbeeld van het aanroepen van gcc met expliciete fasen:

gcc -E program.c       # Preprocessing
gcc -S program.c       # Compilatie (tot assembler)
gcc -c program.c       # Assemblering (tot objectbestand)
gcc program.o -o prog  # Linking

Belangrijke kenmerken:

Maakt het mogelijk om grote projecten uit afzonderlijke modules samen te stellen.
Vergemakkelijkt hergebruik van code en het aansluiten van bibliotheken.
Fouten met betrekking tot ontbrekende functies/symbolen verschijnen alleen tijdens de linkingfase.

Vragen met een twist.

Wat doet de #include "file.h" directief tijdens de compilatie?

#Include voegt de inhoud van het bestand direct in op de plek van de aanroep tijdens de preprocessing, vóór de compilatie begint. Als hetzelfde bestand twee keer wordt opgenomen, kan dit leiden tot meerdere definities van objecten of fouten tijdens de linking.

Is de definitie van een functie in één bestand altijd voldoende voor gebruik in een ander bestand?

Nee, een declaratie (prototype) in de headerfile of ten minste een extern-declaratie is nodig. Anders kunnen er fouten optreden zoals 'implicit declaration of function' of 'undefined reference' tijdens de linking.

Kun je variabelen die als static zijn gedeclareerd in een ander bestand gebruiken?

Nee. Static beperkt de scope van de variabele of functie tot het huidige bestand. Dit betekent dat dergelijke symbolen niet zichtbaar zijn voor de linker in andere objectbestanden.

Typische fouten en anti-patronen

Vergetelheid om bescherming tegen dubbele inclusie (#ifndef/#define/#endif) in de headerbestanden op te nemen.
Poging om dezelfde functie in meerdere bestanden te definiëren.
Onjuist gebruik van static/extern.

Voorbeeld uit het leven

Negatief geval

Een nieuwkomer implementeert een functie met dezelfde naam in twee bronbestanden. Tijdens de linkingfase ontstaat er een vreemde fout: 'multiple definition of function'.

Voordelen:

Eenvoud: je kunt snel code toevoegen zonder projectstructuur te organiseren.

Nadelen:

Moeilijke debugging van linkerfouten, onduidelijkheid over de oorzaak van de opgetreden problemen.
Project is moeilijk op te schalen.

Positief geval

Het creëren van .h-bestanden alleen voor declaraties, .c-bestanden voor definities. Gebruik van #ifdef voor bescherming van headerbestanden. Alle bestanden worden via de linker samengevoegd tot het eindproduct.