[VC8] geen impliciete, transitieve includes

[Verwijderd]

Hallo!

Stel je hebt een file "a.h" die "windows.h" includet, en een file "b.h" die "a.h" includet. Kan je op 1 of andere manier in Visual Studio 2005 forceren dat "b.h" geen functies gedefinieerd in "windows.h" kan gebruiken, tenzij "b.h" zelf "windows.h" expliciet includet? Ik wil met andere woorden dat includes niet impliciet transitief afgehandeld worden.

Dank!

[TheNameless]

Nee dat gaat niet. Iig niet voor zo ver ik weet.

Er is wel een mogelijkheid om b.h niet windows.h te laten includen door een zogenaamde "compiler firewall", of Pimpl Idiom.

Zoek daar eens op op google

[MSalters]

Tuurlijk wel voor het specifieke geval. Kijk wat de header guard voor windows,h is, en #define die voordat je a.h include. Je kunt het alleen niet generiek doen.

Als de auteur van a.h geen prutser is, dan is de include van windows.h nodig. Je mag aannemen dat a.h niet compileert zonder windows.h of, en dat is erger, het compileert wel maar levert stil het verkeerde resultaat. Je hebt dus een kans dat de truc die ik gaf een bug introduceert.

Overigens zou je met een generieke oplossing windows.h breken - het grootste deel van de definities krijg je van de headers die windows.h op zijn beurt weer #include

[TheNameless]

Ja oke, die truck werkt. Maar als je dat soort trucks wilt gaan uithalen, dan ben je verkeerd bezig IMHO

Als je wel je windows.h wilt includen in a.h, maar het niet nodig hebt in een file die a.h wilt gebruiken dan is er mijns inziens iets verkeerd aan je ontwerp.

[ Voor 19% gewijzigd door TheNameless op 19-10-2006 21:59 ]

[Verwijderd]

De reden waarom ik dat wil is dat ik controle wil hebben over mijn includes en exact wil weten welke functies nu door welke files worden opgeroepen. De includes moeten dus voor elke file kloppen.

Hoewel in het voorbeeld "windows.h" wordt vermeld, heeft het niets met deze file in het bijzonder te maken.

[kdekker]

Als zou je je design zo maken dat elke c/c++ file eerst alle benodigde systeem header files includeert (in de praktijk sleept windows.h een enorme kerstboom met zich mee), dus alle include <xxx> directives, daarna alle eigen includes (include "yyy" directives) dan heb je iets meer sturing, maar niet meer dan dat.

Zodra functies uit a.c functies uit b.c aanroepen (dat is de reden ook dat je b.h includeerde), en b.c weer iets uit [c-z].c (whatever), dan heb je toch op link time weer een spagheti bos aan dependencies (en daarvoor hebben we de linker die dat oplost c.q. errors meldt).

Al met al snap ik de reden niet waarom je perse de controle wilt houden over welke file welke functie uit andere source file gebruikt. Bij iets meer files raak je toch het overzicht fout. Wel is het dan een goede praktijk om per source file een aparte header file te hebben, en eventueel een basis header file maken (voor bijv. een statische archive/library) die al die losse header files includeert.

[MSalters]

Verwijderd schreef op vrijdag 20 oktober 2006 @ 12:11:
De reden waarom ik dat wil is dat ik controle wil hebben over mijn includes en exact wil weten welke functies nu door welke files worden opgeroepen.

VC8 kan dat gewoon netjes indented printen, als het alleen gaat om het overzicht (kan overigens in een serieus project oplopen tot 2000+ header regels). Maar "controle" moet je niet willen hebben. Er is geen speciale reden waarom je alleen de #include "a.h" zou willen "controleren". Met net zoveel reden zou je elke #define, elke typedef, ja, zelfs elke letter apart in een header moeten "controleren". #include is niet zo speciaal.