[C/C++] De weg kwijt in mn headers!

[TheBlasphemer]

Help! Ik heb een vrij groot project, met een he-le-boel header files.
Dat is op zich niet zo erg, maar het wil ook dat een heleboel van die headers elkaar referencen, en vaak via-via ook allerlei headers referencen die ze helemaal niet nodig hebben.
Dit alles komt de compile tijd absoluut niet ten goede

Daarom wil ik graag een keertje alles opruimen. Maar om alles handmatig te doen is echt heel veel werk.

Kent iemand misschien een tooltje die me voor elk cpp/h bestand kan laten zien welke files er worden ge-include, zowel direct als indirect? Het zou helemaal mooi zijn als het in de VS2005 IDE werkt.

Ik heb zelf ook al even gezocht, maar met trefwoorden als "indirect header C" kom ik eigenlijk alleen maar troep tegen...

[Refro]

Voor de directe headerfiles kan PC-Lint je op weg helpen is wel betaalware maar elke cent waard. Kan denk ik zowieso geen kwaad om wat extra checks te doen. Als de headerfiles al zo'n zooitje zijn zal de rest ook wel niet erg lekker zijn.

[edit] Indirecte headerfiles blijkt ook te kunnen met PC-lint directe headerfiles niet gebruiken geeft warning 766 indirecte niet gebruiken geeft warning 966. Deze moeten wel beide aanstaan natuurlijk

[ Voor 27% gewijzigd door Refro op 12-11-2007 08:12 ]

[Sebazzz]

Ik gebruik voor header files altijd mijn eigen manier. Ik heb altijd één header file (includer.h) dat alle header files include die ik ooit nodig zal hebben en uiteraard al mijn eigen header files. Het is misschien niet de beste methode, maar wel handig. Het enige wat ik hoef te doen bij ieder cpp en header bestand is

C++:

#include "includer.h"

Best handig

[Refro]

The Triad schreef op maandag 12 november 2007 @ 07:39:
Ik gebruik voor header files altijd mijn eigen manier. Ik heb altijd één header file (includer.h) dat alle header files include die ik ooit nodig zal hebben en uiteraard al mijn eigen header files. Het is misschien niet de beste methode, maar wel handig. Het enige wat ik hoef te doen bij ieder cpp en header bestand is

C++:

#include "includer.h"

Best handig

<sarcasme>Ja en je ziet ook direct zo lekker welke functionaliteit je klasse allemaal gebruikt, dat staat immers boven in je bestand als lijstje van headerfiles. </sarcasme>

[.oisyn]

The Triad schreef op maandag 12 november 2007 @ 07:39:
Ik gebruik voor header files altijd mijn eigen manier. Ik heb altijd één header file (includer.h) dat alle header files include die ik ooit nodig zal hebben en uiteraard al mijn eigen header files. Het is misschien niet de beste methode, maar wel handig. Het enige wat ik hoef te doen bij ieder cpp en header bestand is

C++:

#include "includer.h"

Best handig

Ah ja, met als gevolg dat je je hele project opnieuw moet compileren als je een van de headers wijzigt, wat de hele reden is dat de topicstarter het aantal headers wil terugbrengen tot het minimale, zoals het hoort. "Best handig"

[Sebazzz]

Nee hoor, niet met Visual C++ 2005 Express in ieder geval (ik ga ervan uit dat het voor Windows is, en voor Windows is er maar één goede compiler, vind ik).

[.oisyn]

Leuk dat het op die ene compiler werkt (wat overigens niet waar is want ik maak regelmatig mee dat VC++ ten onrechte denkt dat een sourcefile niet opnieuw gecompileerd hoeft te worden, waardoor je dus gewoon verkeerd gegenereerde binaries krijgt), maar feit blijft dat je gewoon erg fout bezig bent omdat alles depend op alles. En het zal voor jouw hobbyprojectjes sowieso niet uitmaken als alles opnieuw moet compilen, maar als je aan industriële projecten werkt dan zit je al gauw aan één tot meerdere uren durende rebuilds, en daar wordt je echt niet vrolijk van. Ter vergelijking, onze game bestaat momenteel uit 2561 sourcefiles (537000 regels pure code), en een volledige rebuild voor de Xbox360, die toch al niet een al te snelle compiler heeft, duurt op mijn P4 3.2 GHz iets van 3 uur, en loze interdependencies geïntroduceerd door prutsers zijn daar voornamelijk debet aan. Gelukkig krijg ik binnenkort een nieuwe PC en gaan we ook over op IncrediBuild, maar ik zou graag eens wat tijd besteden om net als TheBlasphemer de dependencies eens te optimaliseren.

En heb je überhaupt al eens een andere compiler gebruikt? Kom op zeg, je bent 16, je kan moeilijk zeggen dat je er nou al zoveel versleten hebt om een goed oordeel te vellen . Niets mis met bijv. Intel C++.

[ Voor 18% gewijzigd door .oisyn op 12-11-2007 12:26 ]

[Sebazzz]

Laten we maar weer ontopic gaan voordat ik dit topic kaap

offtopic:
Ja, je hebt gelijk, voor mijn hobbyprojectjes maakt het inderdaad niet heel erg uit, voor grote projecten wel. Maar heb je dan geen krachtige server ofzo die het compileren kan uitvoeren?

Nouja, de enige compilers tot nu toe gebruikt is een oude VS uit '98 geloof ik en VS2005 op Windows, en dat g++ en KDevelop op Linux

[ Voor 20% gewijzigd door Sebazzz op 12-11-2007 12:29 . Reden: Tag typo & edit edit ]

[TheBlasphemer]

Ik denk persoonlijk dat Triad iets als precompiled headers gebruikt van Visual Studio. Voor sommigen is dat heilig, voor anderen (zoals ik) heiligschennis Dat lelijke stdafx.h altijd

Anyway, Ik heb even gelezen over PC-Lint, en het ziet er op zich wel mooi uit, maar het ziet ernaar uit dat hij ook op een heleboel andere errors triggert. Nu is het probleem een beetje dat het project waarvoor ik dit wil gebruiken niet een alleenstaand programma is, maar een add-on die met de meest vreselijke trukjes wel een soort van parasiet op zn host genoemd kan worden
Hiermee doel ik dan op:
- Heel veel gebruik en misbruik van pointers (casten van DWORD naar pointer, pointer naar DWORD, rekenenen, terug naar pointer, etc) (Ja, ik ben ervan op de hoogte dat dit niet portable is, echter mocht het host-programma ooit voor 64-bit herschreven worden, dan zal ik vrijwel alles moeten aanpassen, en is een rewrite waarschijnlijk toch al nodig.)
- Heel veel gebruik van inline assembly
- Heel veel gebruik van Microsoft VC++ specifieke constructies

Ik ben eigenlijk bang dat PC-lint hier ongelooflijk op gaat trippen, en dat ik er daardoor nog steeds vrijwel niets meer kan $239 is een heleboel geld, en als het niet zou werken is het ook nog eens weggegooid geld...

---

Verder heb ik wel (een) antwoord gevonden op mn originele vraag, namelijk de Wave preprocessor (onderdeel van Boost). Hiermee kun je een file laten parsen, en met de -l switch de aangeroepen headers naar een bestand laten schrijven.
Helaas heb ik het idee dat ik voor dit gebruikt de preprocessor een beetje aan het verkrachten ben, en moet ik eerlijk bekennen dat de uitvoer niet bepaald fijn leest, en het ook vrij ingewikkeld is om hiermee nou echt de cleanups te gaan doen die ik wil doen

Heeft iemand anders nog ideeen hoe ik dit (= opruimen van headers, in de hoop dat mn compile tijd dan wat sneller kan) kan gaan oplossen ?

[DataGhost]

The Triad schreef op maandag 12 november 2007 @ 12:27:

offtopic:
Ja, je hebt gelijk, voor mijn hobbyprojectjes maakt het inderdaad niet heel erg uit, voor grote projecten wel. Maar heb je dan geen krachtige server ofzo die het compileren kan uitvoeren?

Nouja, de enige compilers tot nu toe gebruikt is een oude VS uit '98 geloof ik en VS2005 op Windows, en dat g++ en KDevelop op Linux

offtopic:
Het is eigenlijk de bedoeling dat je software schrijft die snel werkt op alle machines, niet dat je lekker lui gaat doen en gewoon meer processorkracht in gaat zetten terwijl dat helemaal niet nodig hoeft te zijn. Een bad practice die ik helaas maar al te vaak langs zie komen. Hetzelfde geldt natuurlijk voor het compileren van je programma. Als het (zoals aangegeven) volkomen overbodig is om *ALLES* opnieuw te compilen, ga je toch geen snellere server inzetten? Zowieso loop je dan weer tegen hetzelfde probleem aan als het project groter wordt.

TS: Zou je niet zelf een programmaatje kunnen schrijven dat alle #include regels doorleest, eventueel ook #defines bijhoudt, van daaruit alsmaar doorgaat en vervolgens een lijst uitprint van referenced headers? Opzich hoef je je toch helemaal niet druk te maken om die inline ASM, casts en dergelijke, of zit ik er nu helemaal naast?
Edit: ik zie trouwens dat je ondertussen zelf al iets gevonden hebt wat min of meer datzelfde doet..
Je zou wellicht kunnen kijken of ctags doet wat je wilt, of eventueel lxr (volgens mij is dat gewoon geschikt voor andere projecten dan de kernel, en je kan daarmee precies zien welke headers er (in)direct GEBRUIKT worden. Ik ben verder niet echt bekend met ctags, maar dat heeft naar mijn weten een vergelijkbare functionaliteit)

[ Voor 14% gewijzigd door DataGhost op 12-11-2007 13:40 ]

[Sebazzz]

offtopic:
Ik denk persoonlijk dat Triad iets als precompiled headers gebruikt van Visual Studio. Voor sommigen is dat heilig, voor anderen (zoals ik) heiligschennis Dat lelijke stdafx.h altijd -- Nee daar kan ik niet mee werken en VS205 biedt dat geloof ik ook niet meer aan Het liefste native, of desnoods wxWidgets oid

[ Voor 7% gewijzigd door Sebazzz op 12-11-2007 13:40 ]

[Plecky]

Ik heb hier overigens in VS2005 (Pro) bij de Project properties onder "Configuration Properties > C/C++ > Advanced" een optie "Show Includes" zitten. Heb je daar iets aan?

[.oisyn]

Ik heb even zitten zoeken, en ik vind het frappant dat hier geen tools voor zijn. Maar wat je evt zou kunnen doen om het te automatiseren (zonder daadwerkelijk de code te analyseren) is alle includes uit al je header en sourcefiles slopen, een verzameling maken van alle mogelijke includes die je kan hebben, en dan voor iedere header en sourcefile de minimale set van includes vinden door domweg te proberen tot je geen compile errors meer krijgt. Het aantal combinaties is echter behoorlijk groot dus dit zal wel aardig wat tijd innemen, dus misschien is het dan handiger om het andersom aan te pakken - de huidige includes weg gaan halen tot het niet meer compileert. Alleen zit je dan wel weer met het feit dat je afhankelijk gaat worden van headers die weer andere headers includen, dus eigenlijk moet je een dependency graph gaan maken en dan beginnen bij headers die alleen nog maar systemheaders includen en zo geleidelijk de graaf afwerken.

[Verwijderd]

Ik weet dat je visual studie gebruikt, maar dit zit standaard in gcc. Aanroepen met -MM en je krijgt keurig alle dependenties in makefile formaat. Dus om alle dependenties van helloworld.cpp te krijgen doe je:

gcc -MM helloworld.cpp

Je krijgt dan keurig

helloworld.o: helloworld.cpp header1.h header2.h

[Refro]

TheBlasphemer schreef op maandag 12 november 2007 @ 13:29:
Ik ben eigenlijk bang dat PC-lint hier ongelooflijk op gaat trippen, en dat ik er daardoor nog steeds vrijwel niets meer kan $239 is een heleboel geld, en als het niet zou werken is het ook nog eens weggegooid geld...

Als elk van de 20 licenties van pc-lint voorkomt dat er 1 bug in het veld komt heeft het zijn geld al opgebracht (hier althans) verder kun je alle andere meldingen uitzetten. Wij zijn ook met heel weinig meldingen begonnen en hebben langzaam de duimschroeven aangedraaid.