Programmeren in C/De compiler: verschil tussen versies

Uit Wikibooks
Verwijderde inhoud Toegevoegde inhoud
GeeKaa (overleg | bijdragen)
kGeen bewerkingssamenvatting
Pjetter (overleg | bijdragen)
sub
Regel 36: Regel 36:
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. Heet gebruik van afzonderlijke componenten biedt vaak veel meer vrijheid.
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. Heet gebruik van afzonderlijke componenten biedt vaak veel meer vrijheid.


<!-- ----------- Hieronder onderhoudsmeldingen -------------- -->
[[Categorie:Programmeren in C|De compiler]]
{{sub}}

Versie van 22 mei 2008 11:53

Programmeren in C

Inleiding
  1. Inleiding Redelijk ontwikkeld. Revisiedatum: 23 oktober 2007
  2. De compiler Redelijk ontwikkeld. Revisiedatum: 23 oktober 2007

Bewerkingen

  1. Basis Goed ontwikkeld. Revisiedatum: 23 oktober 2007
  2. Stijl en structuur Redelijk ontwikkeld. Revisiedatum: 23 oktober 2007
  3. Datatypes Goed ontwikkeld. Revisiedatum: 11 november 2007
  4. Berekeningen In ontwikkeling. Revisiedatum: 23 oktober 2007
  5. If en loops Goed ontwikkeld. Revisiedatum: 23 oktober 2007
  6. Arrays en pointers Redelijk ontwikkeld. Revisiedatum: 24 oktober 2007
  7. Functies Goed ontwikkeld. Revisiedatum: 23 oktober 2007
  8. File handling In ontwikkeling. Revisiedatum: 23 oktober 2007

Overige

  1. Bestanden Redelijk ontwikkeld. Revisiedatum: 23 oktober 2007
  2. C-Preprocessor (CPP) Redelijk ontwikkeld. Revisiedatum: 23 oktober 2007
  3. Struct
  4. Expressies

Zoals elke andere computer-taal wordt C niet direct door de computer begrepen, maar moet eerst vertaald worden. In het geval van C. Dit proces vind plaats in drie stappen.

  1. De C-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.
  2. De C-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.
  3. De Linker neemt deze object files en een of meerdere 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 onder water verdwijnen 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 niet met een, maar met (minimaal) twee nauw verweven computertalen te maken, waarbij de ene (de C-Preprocessor) de uiteindelijke broncode voor de eigenlijke C-Compiler samenstelt.

Compilers

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 vertaalt 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-code 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 bvan het uiteindelijke programma is dit een alles behalve overbodige luxe.

Enkele bekende compilers zijn:

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.
  • Een Builder zoals make, een programma dat beslist welke bronbestanden moeten worden gecompileerd.
  • Een Archiver zoals ar, een programma dat diverse object bestanden verzamelt in een library voor later gebruik.
  • 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. Heet gebruik van afzonderlijke componenten biedt vaak veel meer vrijheid.

Informatie afkomstig van https://nl.wikibooks.org Wikibooks NL.
Wikibooks NL is onderdeel van de wikimediafoundation.