Programmeren in C/De compiler: verschil tussen versies

Verwijderde inhoud Toegevoegde inhoud
→‎Welke compiler?: Clang toegevoegd als bekende compiler
Nijdam (overleg | bijdragen)
Geen bewerkingssamenvatting
Regel 1:
{{Programmeren in C}}
== Wat doet een compiler? ==
Zoals elke andere computer-taal wordt ''C'' niet direct door de computer begrepen, maar moet een programma in C eerst vertaald worden naar machinetaal. In het geval van C vindt dit proces plaats in drie stappen, elk gedaan door een afzonderlijk programma:
 
# De ''preprocessor'' interpreteert het bronbestand en voert alle ''preprocessor directives'' uit. Deze opdrachten behelsen het invoegen van andere bestanden (''#include <foobar.h>''), het conditioneel opnemen of weglaten van stukken code (''#ifdef FOOBAR ... #else ... #endif'') en het vervangen van gespecificeerde namen (macro's) door een waarde (''#define FOOBAR 123''). Dit resulteert in een ''stream'' waarin, ten behoeve van de compiler zelf en met name de foutmeldingen en waarschuwingen ''#line'' directives staan omdat de regelnummering in de outputstream geen directe relatie meer heeft tot de bronbestanden.
# De ''compiler'' zelf interpreteert de output van de C-Preprocessor, interpreteert deze, genereert foutmeldingen en waarschuwingen als dat nodig is en creëert een ''object-file'', waarvan het formaat vaak sterk afhankelijk is van de compiler. In deze ''object-file'' staat niet alleen de resulterende machinecode, maar ook de symbolische informatie: namen en (relatieve) adressen van functies en variabelen, niet opgehelderde referenties zoals functienamen die in een andere object-file staan, initialisatiewaarden voor globale variabelen, etcetera. Wat er precies instaat is overigens ook sterk afhankelijk van de compiler.
# De ''linker'' neemt deze object files en een of meerderemeer benodigde bibliotheken (''libraries'') en voegt ze samen tot een programma, waarbij externe verwijzingen naar functies en variabelen worden opgelost en uiteindelijke adressen worden toegewezen aan alle globale variabelen.
 
Hoewel deze stappen vaak onzichtbaar gebeuren bij het gebruik van ''Integrated Development Environments'' (IDE's), is het wel belangrijk deze volgorde te begrijpen, want fouten kunnen soms rare consequenties hebben. De C-programmeur heeft, in tegenstelling tot wat vaak wordt gedacht, met (minimaal) twee nauw verweven computertalen te maken: de preprocessortaal en de C-programmeertaal.
 
== Welke compiler? ==
Er zijn vele compilers op de markt, sommigensommige beter dan anderenandere. De kwaliteit van een compiler kan worden bepaald aan de hand van een aantal criteria, zoals:
 
Er zijn vele compilers op de markt, sommigen beter dan anderen. De kwaliteit van een compiler kan worden bepaald aan de hand van een aantal criteria zoals:
 
* Houdt de compiler zich aan de C-standaard die het beweert te implementeren?
* Kwaliteit van de object-code. Wordt de broncode vertaald in efficiënte of juist heel omslachtige object-code?
* Configureerbaarheid van de compiler. In hoeverre kan de compiler ingesteld worden? Moet hele snelle of juist heel compacte code worden gegenereerd? Welke C-Standaard moet worden gehanteerd? Kan de compiler verschillende formaten voor de ''object-files'' aan? Kan worden ingesteld of de compiler voor elk wissewasje een foutmelding of waarschuwing genereert of alleen bij echte rampzaligheden? Enzovoort, en zo verder.
* Veelzijdigheid, kan de compiler object-codeobjectcode voor verschillende hardware-platformen genereren of slechts een.
 
Hoe zwaar elk van de criteria weegt in de beslissing, is sterk afhankelijk van de toepassing, en het is onmogelijk algemeen geldende richtlijnen te geven. Wel is het belangrijk dat de programmeur zich bewust is van de eigenschappen en kwaliteit van zijn compiler; zelfs de beste broncode levert beroerde programma's op als de compiler van matige kwaliteit of slecht ingesteld is.
 
In veeleisende professionele omgevingen is het vrij gebruikelijk er speciale korte stukken broncode (''test-suites'') op na te houden, zodat de output van verschillende compilers of verschillende instellingen van dezelfde compiler vergeleken kan worden. Gezien het doorslaggevende effect van de compiler op de kwaliteit van het uiteindelijke programma, is dit een alles behalveallesbehalve overbodige luxe.
 
Enkele bekende compilers zijn:
Regel 29 ⟶ 28:
 
== Wat heb je verder nodig? ==
 
* Een goede ''Editor'', waarmee je je programma's kunt schrijven. Wees kritisch en kies de editor die je het beste bevalt. Broncode schrijven is een tijdrovende klus en de meeste tijd zul je waarschijnlijk besteden in de editor. Dingen als ''syntax-coloring'' en goede zoek-faciliteiten kunnen veel tijd en (vooral) moeite besparen.
* Een ''Source-level Debugger'', waarmee je kunt nagaan wat er precies gebeurt als het fout gaat. En het '''zal''' fout gaan, want zelfs erg goede programmeurs maken fouten.
Regel 36 ⟶ 34:
* Veel geduld, gemoedsrust en frustratiebestendigheid, want programmeren is tijdrovend en de CPU zal altijd doen wat je zegt, niet wat je bedoelt en bovendien zijn (bijna) alle fouten jouw schuld.
 
In een IDE zijn deze programma's in een pakket geïntegreerd. Dit lijkt vele voordelen te bieden, maar IDE's zijn zelden ''portable'', zodat het zeer lastig kan zijn om een programma geschreven in een IDE over te dragen naar een andere, laat staan naar een ''toolchain'' bestaande uit losse onderdelen. Het gebruik van afzonderlijke componenten biedt vaakin veel gevallen veel meer vrijheid.
 
<!-- ----------- Hieronder onderhoudsmeldingen -------------- -->
Informatie afkomstig van https://nl.wikibooks.org Wikibooks NL.
Wikibooks NL is onderdeel van de wikimediafoundation.