[C/C++ :: Pre Processor] Het #include statement

[BratMokstrof]

Beetje technische vraag, vandaar dat ik hier maar eens langskom

Wat doet een #include statement exact? Stel ik doe een

code:

#include <stdio.h>

Wat gebeurt er precies?

Ik heb verhalen gehoord waarbij de gehele file op de plaats v/h include statement wordt geplaatst, maar hoe vindt de compiler dan de échte functieomschrijvingen?
Waar wordt de .c file heen-gezet, want die kan (neem ik aan) niet ook daar neergezet worden, omdat je dan geen onderscheid meer kan maken tussen public en private functies.

Tenslotte: ik gebruik in een programma van de lib stdio slechts de printf(...) functie. Worden nu tevens de andere functies ook geinclude, of wordt daar naar gekeken (mogelijkheden tot optimalistatie). Wat gebeurt er met routines uit stdio.c (.c?) die worden aangeroepen door printf (recursief) en wat gebeurt er met routines die niet (al dan niet recursief) worden aangroepen?

[curry684]

BratMokstrof schreef op zaterdag 05 februari 2005 @ 15:16:
Wat gebeurt er precies?

Ik heb verhalen gehoord waarbij de gehele file op de plaats v/h include statement wordt geplaatst

100% correct

maar hoe vindt de compiler dan de échte functieomschrijvingen?

Dat doet ie niet, dat doet de linker.

Tenslotte: ik gebruik in een programma van de lib stdio slechts de printf(...) functie. Worden nu tevens de andere functies ook geinclude, of wordt daar naar gekeken (mogelijkheden tot optimalistatie). Wat gebeurt er met routines uit stdio.c (.c?) die worden aangeroepen door printf (recursief) en wat gebeurt er met routines die niet (al dan niet recursief) worden aangroepen?

De definities worden wel geinclude, maar de linker linkt ze vervolgens niet mee.

[.oisyn]

Header files die je include hebben an sich niets met het linkproces te maken. In die headers staan meestal declaraties en definities die niets anders doen dan de compiler duidelijk maken dat die dingen bestaan, en bijv. met welke parameters ze aangeroepen kunnen worden. Als de compiler dat weet kan hij code genereren voor bijv. een functieaanroep, zonder dat hij nog hoeft te weten waar die functie vandaan komt.

Elke sourcefile die je compileert wordt omgezet in een binary object file, waar zowel code als data instaat, alsmede een hoop informatie aangaande het linkproces (dus bijv. welke functies in de object file staan en op welke plek) en debuginformatie (regelnummers e.d.). Deze object files kun je bij elkaar voegen om zo een grote library te vormen. De linker stopt alle object files bij elkaar en zorgt dat alle gebruikte adressen (van functies en variabelen e.d.) ook naar de juiste dingen wijzen. Waarschijnlijk zullen er nog een aantal symbolen gebruikt worden die niet in die object files gedefinieerd zijn, zoals bijvoorbeeld die referentie naar printf. Hiervoor kijkt de linker in de opgegeven libraries, of daar niet zo'n object file in staat die dat symbool in zich heeft. Als dat niet zo is krijg je meestal een error in de trant van "Undefined external symbol 'Foo' in Bar.obj". Als er wel een object file in zo'n library staat met de juiste symbols, dan wordt ie ook meegenomen in het linkproces, wat weer mogelijk voor nieuwe symbolen zorgt waarnaar gezocht moet worden, en dat gaat zo door totdat alles bij elkaar is gezet.

En het hangt een beetje van de compiler af wat wel en wat niet meegelinkt wordt. De ene compiler linkt op functiebasis, anderen kijken alleen naar hele object files of misschien zelfs hele libraries.

[BratMokstrof]

curry684 schreef op zaterdag 05 februari 2005 @ 15:19:
De definities worden wel geinclude, maar de linker linkt ze vervolgens niet mee.

Wat houdt dat linken precies in? Wat heeft het al dan niet linken (en dan met name niet linken ) voor gevolgen voor het compileren van het geheel?

Hoe bepaalt de linker welke functies worden gelinkt? Of is dat stomweg het recursief vervolgen van paden?

[.oisyn]

Had je mijn post nog gelezen hierboven? Die is op hetzelfde moment gepost als die van jezelf namelijk . Maar om je vraag te beantwoorden: ja, hij begint ergens (zoals gezegd, een compiler kan uitgaan van de lijst met object files die ie mee heeft gekregen, of simpelweg alleen beginnen bij de entry point), kijkt naar alle referenties die daardoor geintroduceerd worden, gaat die referenties ook meenemen die op zichzelf ook weer referenties naar anderen hebben, etc.

[ Voor 64% gewijzigd door .oisyn op 05-02-2005 15:55 ]

[BratMokstrof]

Ja, ik had je reactie gelezen, thnx a lot!! Jullie zijn ook zo snel hier, super

Kon de "delete post" niet vinden, vandaar dat ik hem maar even had laten staan...

Stel ik verander mijn stido.h (even los van of dat wel of niet verstandig is of in dit specifieke geval kan) en verwijder alles behalve de printf (de rest gebruik ik immers niet).

Heeft dit gevolgen (qua handelingen / performance). Of hangt dat dan weer af v/d compiler?

[ Voor 6% gewijzigd door BratMokstrof op 05-02-2005 17:36 ]

[Soultaker]

Als je niet-gebruikte declaraties weghaalt dan zal het compileren ietsje sneller gaan, maar dat is waarschijnlijk verwaarloosbaar. Het linken duurt net zo lang en het resulterende programma is net zo groot en snel als wanneer je het niet had gedaan.

Sowieso moet je nooit gaan zitten prutsen in bestanden die met de compiler meegeleverd worden (en eigenlijk ook niet in de bestanden van externe libraries).

[.oisyn]

Het gaat niet om de files die je include, maar om de inhoud. Ipv dat voorbeeld dat je gaf kun je bijvoorbeeld ook gewoon niet stdio.h includen en simpelweg extern "C" int printf (char * fmt, ...); in je sourcefile zetten, dan kun je 'm ook gebruiken.

Je moet uiteraard wel nog altijd linken tegen de standaard library, maar meestal gebeurt dat automatisch al.

[curry684]

Volgens mij is het handig als topicstarter even gaat lezen wat compilen en linken exact inhouden

[mOrPhie]

.oisyn schreef op zaterdag 05 februari 2005 @ 20:44:
Het gaat niet om de files die je include, maar om de inhoud. Ipv dat voorbeeld dat je gaf kun je bijvoorbeeld ook gewoon niet stdio.h includen en simpelweg extern "C" int printf (char * fmt, ...); in je sourcefile zetten, dan kun je 'm ook gebruiken.

Sterker nog. In GCC hoef je die extern niet eens te maken en werkt printf all the way zonder ook maar iets te includen. Dit geldt niet voor G++. De redenen hiervoor moet ik je verschuldigd blijven.

[curry684]

mOrPhie schreef op zondag 06 februari 2005 @ 00:14:
[...]

Sterker nog. In GCC hoef je die extern niet eens te maken en werkt printf all the way zonder ook maar iets te includen. Dit geldt niet voor G++. De redenen hiervoor moet ik je verschuldigd blijven.

Je bedoelt hiermee te zeggen dat GCC deze code slikt?

C++:

int main()
{
  printf("Hello world!\n");
}

Zo ja zou ik eens een bugreport maken, dat mag absoluut niet

[mOrPhie]

C:

int main()
{
        printf("hoi\n");
        return 0;
}

code:

dennie@neo:~/files/programming/test2$ gcc bla.c
dennie@neo:~/files/programming/test2$ ./a.out
hoi

C dus he. Geen C++.

En zoals ik al zei ken ik de redenen niet en zie dit dus vooralsnog als een feature i.p.v. een bug (waar hebben we dat eerder gehoord ). Ik ben nu ook wel benieuwd geworden.

[Soultaker]

curry684 schreef op zondag 06 februari 2005 @ 00:24:
[...]

Je bedoelt hiermee te zeggen dat GCC deze code slikt?

C++:

int main()
{
  printf("Hello world!\n");
}

Zo ja zou ik eens een bugreport maken, dat mag absoluut niet

Jawel hoor, ELKE fatsoenlijke C compiler slikt die code; het is waarschijnlijk gewoon onderdeel van de standaard. Maar je moet geen C++ codeblok gebruiken (en een C++-style main declaratie), want het werkt alleen in C (en niet in C++).

Dat is waarschijnlijk ook de reden waarom het wel werkt als je gcc gebruikt en niet als je g++ gebruikt, hoewel het verschil tussen die twee me op een aantal punten nogal onduidelijk is.

[madwizard]

Als je het warninglevel hoger zet krijg je overigens wel een melding dat de functie impliciet gedeclareerd wordt:

code:

test.c:3: warning: implicit declaration of function `printf'

Ook in VS.NET werkt het in C gewoon (met warning), en in C++ niet:

code:

test.c(3) : warning C4013: 'printf' undefined; assuming extern returning int

test.cpp(3) : error C3861: 'printf': identifier not found, even with 
argument-dependent lookup

Het extern keyword is geloof ik in zowel C als C++ al default voor de file scope maar blijkbaar is het in C++ wel verplicht in ieder geval een declaratie te hebben. In ieder geval wordt er in C nog een warning gegeven en dat lijkt me maar beter ook .

[ Voor 7% gewijzigd door madwizard op 06-02-2005 01:01 ]

[curry684]

madwizard schreef op zondag 06 februari 2005 @ 00:55:
Als je het warninglevel hoger zet krijg je overigens wel een melding dat de functie impliciet gedeclareerd wordt:

Maar hoe kan ie dit impliciet declareren gezien het feit dat de functie een variabel aantal argumenten heeft? Dat kan eigenlijk alleen indien het een hardcoded verhaal is

* curry684 mompelt iets over ranzigheid en trekt zich terug in z'n C#/C++ hoekje

[madwizard]

curry684 schreef op zondag 06 februari 2005 @ 01:01:
Maar hoe kan ie dit impliciet declareren gezien het feit dat de functie een variabel aantal argumenten heeft? Dat kan eigenlijk alleen indien het een hardcoded verhaal is

Op x86 kan dat omdat de caller toch de stack zelf weer moet opruimen na de functie aanroep, zolang de parameters op zich correct zijn kun je er ook correcte code voor genereren. Alleen dat is weer iets specifieks van het platform. Kan me voorstellen dat het niet met elk platform mogelijk is dus ik betwijfel of het echt in de standaard is opgenomen. Het enige dat je kunt doen is gokken wat het exacte type is en dat aannemen. Of het handig is is een tweede, dit compileert ook gewoon vrolijk om vervolgens direct te crashen:

C:

int main() 
{ 
    printf(1,2,3,4,"hoedje van papier"); 
}

edit:

Incompatibilities Between ISO C and ISO C++ (#C90-impl-func):
C90 allows a function to be implicitly declared at the point of its first use (call), assigning it a return type of int by default. For example:

C:

/* No previous declaration of bar() is in scope */

void foo(void)
{
    bar();  /* Implicit declaration: extern int bar() */
} 

C++ does not allow implicit function declarations. It is invalid to call a function that does not have a previous declaration in scope.

C99 no longer allows functions to be implicitly declared. The code above is invalid in both C99 and C++.

[ Voor 30% gewijzigd door madwizard op 06-02-2005 01:19 ]

[mOrPhie]

madwizard schreef op zondag 06 februari 2005 @ 01:12:
Of het handig is is een tweede, dit compileert ook gewoon vrolijk om vervolgens direct te crashen:

C:

int main() 
{ 
    printf(1,2,3,4,"hoedje van papier"); 
}

In GCC compileert dat dus niet. Met of zonder stdio.h include.

[ Voor 70% gewijzigd door mOrPhie op 06-02-2005 01:23 ]

[Soultaker]

Dan is jouw gcc stuk, denk ik, want hier doet 'ie het precies zoals de standaard voorschrijft.

Overigens heeft gcc wel voorkennis over wat printf precies doet, want hij weet wel te vertellen dat het eerste argument eigenlijk een pointer zou moeten zijn.

[.oisyn]

mOrPhie schreef op zondag 06 februari 2005 @ 00:14:
De redenen hiervoor moet ik je verschuldigd blijven.

De reden hiervoor is dat C minder typesafe is en bovendien geen ondersteuning heeft voor function overloading. Er bestaat dus altijd maar 1 functie met die naam, en dus zal ie altijd de juiste functie erbij kunnen vinden. Daarbij maakt ie wel assumpties over het returntype (altijd int) en de parameters. In dat printf voorbeeld van jou gaat het ook gewoon fout als je 'm bijvoorbeeld zo aanroept: printf ("%f\n", 1.0f); (misschien dat gcc hier overigens wel klaagt of het juist gewoon goed doet, maar da's geen standard behavior).

[ Voor 9% gewijzigd door .oisyn op 06-02-2005 12:26 ]

[MSalters]

Soultaker schreef op zondag 06 februari 2005 @ 01:50:
Dan is jouw gcc stuk, denk ik, want hier doet 'ie het precies zoals de standaard voorschrijft.

Compilers mogen helderziende zijn, als je een programma hebt wat runtime zeker crasht mag een compiler dat al rejecten. Die uitzondering is er om te voorkomen dat een optimizer in de problemen komt als diezelfde code @compile-time wordt uitgevoerd. Compilerbouwers kunnen dus toe met iets als

C++:

try {
  optimize( current_TU );
} catch ( ... ) {
  // I've tested OUR code, so ...
  std::cerr << "Your code is wrong\n";
}

[BratMokstrof]

Het wordt wel erg interessant allemaal nu

Maar weer een beetje on-topic, heb ik nog wel een vraag.

Hoe komen jullie aan die informatie over hoe zo'n pre processor precies werkt?
Ik heb een beteje het net afgezocht, de GCC site bekeken, maar ik word er niet heel wijs uit.

Hebben jullie suggesties waar ik meer (specifieke) info kan vinden betreffende het onderwerp pre-proccesoren van C(++) en dan met name m.b.t. het #include statemetn?

[curry684]

MSDN Library Online as always Als je up one level gaat daar zie je complete uitleg wat de preprocessor doet

Daarnaast doet good old Google het ook leuk

[ Voor 26% gewijzigd door curry684 op 07-02-2005 12:17 ]

[Hermarcel]

Mijn favoriete links:
The C PreProcessor
The C Programming Language

[BratMokstrof]

Google? Nooit van gehoord ...

Maar OK, thnx voor de links, maar dit is de informatie die ik sowieso overal tegenkom. Ik wil juist meer diepgaande info, zoals in de eerste post, wat doet de PP precies!?

.oisyn gaf behoorlijk uitgebreid uitleg, uitleg van een dergelijke diepgang vind ik bij geen van deze links of via Google...

[curry684]

Volgens mij denk je gewoon veel te moeilijk. De preprocessor doet gewoon geen bal en #include is de domste statement van allemaal Dit is echt alles wat er te vertellen is, er is gewoon niet meer aan

[BratMokstrof]

Sja, ik ben in mijn pubertijd nooit lastig geweest en blijkbaar gaat dat nu opspelen ...

Maar als dat alles zou zijn, hoe verklaar ik dan het gedrag van verschil in performance bij een splitsing in de .h files naar een beperkter aantal functies per file? Dat heeft - is mij bekend - invloed op de performance bij GCC, maar waarom dan? Waar zit het verschil hem in en wat gebeurt er ... Ik kan het nergens vinden

[curry684]

Functies opsplitsen in meerdere headers heeft nul invloed op de performance, dat is echt volstrekte nonsens.

Je onderscheidt globaal de volgende stappen:
• Originele sourcecode ragt door de preprocessor. Deze expandeert de #include statements door de files in te voegen, vervangt macro's die met #define zijn gemaakt, en filtert code die door #if en co niet nodig zijn.
• Processed code gaat de compiler in. Deze bakt er een object file van.
• De linker pakt tig object files en bakt er 1 executable/dll/lib/whatever van.

De preprocessor is puur een linguistisch verhaal, en maakt geen verschil voor de compiler. Pas als de code inhoudelijk verandert *kan* dat invloed hebben op de performance, alhoewel de gemiddelde optimizing compiler van 'vrijwel dezelfde code' meestal wel 'identieke assembly' weet te bakken.

edit:
of bedoel je dat het compilen sneller gaat als je meerdere headers hebt? zo ja: dat is redelijk logisch ja, die dingen worden gecached tijdens het compileren

[ Voor 22% gewijzigd door curry684 op 07-02-2005 14:54 . Reden: oeps foute links ]

[ritsjoena]

BratMokstrof schreef op maandag 07 februari 2005 @ 14:43:
Maar als dat alles zou zijn, hoe verklaar ik dan het gedrag van verschil in performance bij een splitsing in de .h files naar een beperkter aantal functies per file? Dat heeft - is mij bekend - invloed op de performance bij GCC, maar waarom dan? Waar zit het verschil hem in en wat gebeurt er ... Ik kan het nergens vinden

In welk deel van het compilatie-proces merk je verschil?
De preprocessor moet de tekst mergen en dat kost een klein beetje extra tijd. (1x versus 10x)
Bij linken moet ook gemiddeld langer gezocht worden voor de juiste link gevonden wordt.

Meer bestanden betekent iets meer overhead, doordat ze wel allemaal beheerd, geopend, gelezen, gemerged etc. moeten worden. Dit extra beetje tijd zal in het algemeen zeer weinig zijn en is al helemaal verwaarloosbaar tov de voordelen van goed modulair schrijven.

[BratMokstrof]

Ik doel op performance winst bij het compilen (sorry als ik me vaag uitdrukte).

Waarom het logisch is dat het splitsen van .h files naar verscheidene kleinere .h files (met weglating van ongebruikte functies) performance winst oplevert, snap ik niet, maar ik ben druk doende de tekst van jouw link (die je volgens mij inmiddels alweer hebt weggehaald ) te lezen.

[.oisyn]

ritsjoena schreef op maandag 07 februari 2005 @ 14:55:
Bij linken moet ook gemiddeld langer gezocht worden voor de juiste link gevonden wordt.

Dit is niet waar, declarations hebben geen invloed op het linkproces. Het is puur voor de compiler om aan te geven dát iets bestaat. Als je dat aangeeft maar vervolgens niet gebruikt doet de linker er ook niets mee (sterker nog, die heeft niet eens informatie over de gebruikte declaraties).

Voor het totale buildproces is het overigens wel verstandig om veel kleine headers te hebben ipv weinig grote, vooropgesteld dat je alleen die headers include die van belang zijn. Hierdoor creëer je kleinere dependencies als je in 1 van de headers iets moet aanpassen. Stel je zou 1 grote header gebruiken voor al je source files, dan betekent dat bij een aanpassing aan die header alle source files opnieuw gecompileerd moeten worden. Als je per header slechts 1 declaratie hebt staan en je verandert een van die declaraties dan hoeven slechts alleen die source files opnieuw gecompileerd te worden die van die declaraties gebruik maken. En dat is ook logisch, de rest verandert niet dus waarom zou je die opnieuw willen compileren?

[ritsjoena]

.oisyn schreef op maandag 07 februari 2005 @ 15:19:
Dit is niet waar, declarations hebben geen invloed op het linkproces. Het is puur voor de compiler om aan te geven dát iets bestaat. Als je dat aangeeft maar vervolgens niet gebruikt doet de linker er ook niets mee (sterker nog, die heeft niet eens informatie over de gebruikte declaraties).

Je hebt gelijk. Ik ging er automatisch vanuit dat de source-files en object-files ook opgesplitst waren, maar dat hoeft helemaal niet. Hoewel dat meestal handiger is dan een opgesplitste headerfile.

Niet gebruikte declaraties worden in beide gevallen niet opgezocht door de linker. Ze hebben dus alleen invloed bij het includen. De invloed op de compilatie-performance komt dus af van de verdeling van gebruikte declaraties over de object files (dwz bijbehorende code). Ik dacht dat die context al duidelijk was.

Daarnaast ging ik ervan uit dat met compileren inclusief linken wordt bedoeld. Dit is niet helemaal juist, maar voor de meeste mensen wel hoe er in de praktijk mee omgegaan wordt.

[curry684]

BratMokstrof schreef op maandag 07 februari 2005 @ 14:59:
Ik doel op performance winst bij het compilen (sorry als ik me vaag uitdrukte).

Waarom het logisch is dat het splitsen van .h files naar verscheidene kleinere .h files (met weglating van ongebruikte functies) performance winst oplevert, snap ik niet, maar ik ben druk doende de tekst van jouw link (die je volgens mij inmiddels alweer hebt weggehaald ) te lezen.

Ja sorry die link linkte het verkeerde concept

Op het moment dat de compiler file X reeds een keer geparsed heeft kan ie 'm de 2e keer makkelijker wegrekenen. Je hebt wat dat betreft zeker met veel includes de kans dat dezelfde include vaker langs komt en dus geskipped kan worden en/of reeds gecached is Veel zal het niet schelen overigens, uiteindelijk blijven het evenveel definities.

[MSalters]

Overigens zij preprocessors berucht buggy, zijn er iets van twee of drie die goed zijn. (GCC, Wave en misschien nog eentje die ik vergeet). Een simpele #include gaat meestal wel goed, maar het wordt lastiger als je een #include doet waarbij de te includen file zelf gespecificeerd wordt door een macro expansie (ja, dat mag). En er zijn nog behoorlijk subtielere interacties. Recursieve macros, bijvoorbeeld.