Programmeren in C/De compiler: verschil tussen versies

Uit Wikibooks
Verwijderde inhoud Toegevoegde inhoud
Aleichem (overleg | bijdragen)
k typo
Aleichem (overleg | bijdragen)
Regel 9: Regel 9:
=== Compilers ===
=== 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 aanta 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?
* Houdt de compiler zich aan de C-standaard die het beweert te implementeren?

Versie van 20 jul 2007 09:28

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. De output van deze stap kan veelal met
  2. De C-Compiler zelf interpreteert de output van de C-Preprocessor, interpreteert deze, genereert foutmeldingen en waarschuwingen als dat nodig is en creeert 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, etc. 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 Envoronments (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 efficiente 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 gehanteert? 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 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 geintegreerd. 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.