repeated #includes- bad architecture?

You could have the sprite.h or whatever include ddraw.h and windows.h, but depending on sprite.h to include those two is usually a worse decision. Just include ddraw.h and windows.h for every file that uses sprite.h, since they'll most likely be using ddraw stuff anyway. Get over the fear of including tons of headers.


There are times when you can depend on a header to include another. For example, if light.h has a class that derived from node defined in node.h, then you need not include node.h prehand. But, the moment you use node.h in the module, it's best to include it explicitly. It's all up to your interpretation on what's a good dependancy and what's not. But be careful, because if things change a lot, you'll have a handful of headaches.

[edited by - aggregate on October 31, 2002 5:58:07 PM]

ok thats kinda what i was thinking...doesnt including things over and over again increase the overhead though? or is it insignificant. I mean I'm kinda under the impression that windows and ddraw are pretty big includes...am i falsely worried?

also- it seems like there should be another way since im only using two structs/types, and not any functions...isnt there something similar to forward declarations with classes that i could do here?

[edited by - bjmumblingmiles on October 31, 2002 6:17:47 PM]

Depends on your tools, really. It''s not a problem with C, but with C++, yes, lots of overhead. Most tools have some half-decent caching/state checking to see if they need to reinclude anything. Inclusion guards prevent unneeded processing the next time around, anyway.

1) You should not include the direct draw files if you are not directly using anything from them. Your sprite file uses them/includes them, and that is enough. Just include your sprite file.

2) You can include them if you want, and that will not do anything as far as size (multiple includes).

Extra includes adds some overhead at compile time, but you won''t notice any difference in executable file size or memory use from extra includes. Think about it. There are hundreds of functions in most libraries but what if you only use one or two of them? The compiler only includes what you need.

all that the #include files are for is for type/function/data declarations.

in a very real sense, they''re just templates, cookie cutters.

No actual CODE gets produced until you compile a .c/.cc/.cpp/etc... source file.

headers serve source files. They are a mechanism to avoid having to rewrite the same declarations over and over again.

yeah i know they are just declarations...but some of the standard headers are pretty big and that was my concern...i was under the impression that compilers expand includes to the contents of that file...but these posts have told me otherwise, i suppose. It just seemed like a waste to include windows.h so i could use LPCTSTR''s.

I was under the impression that compilers expand includes to the contents of that file...but these posts have told me otherwise, i suppose.

No, you're correct. They get expanded at compile time just as if you typed it all right there in the source, but it has no impact on your compiled program. You can write millions of function declarations without any function bodies, the compiler won't care. You can even #include "Source.cpp", ha, but I wouldn't recommend it

But, more header includes slows your compiling, so less is better.

[edited by - Jiia on October 31, 2002 7:46:16 PM]

You can often greatly improve compile speeds by using precompiled headers - every file #includes "precompiled.h", which contains all the biggies.
It''s convenient and quick, but you get big .pch files, and your namespace is filled with crap.
2 gotchas with VC++, though: make sure the pch is created exactly once (have precompiled.cpp (includes precompiled.h) create the header, and all other project files use it), and make #include "precompiled.h" the very first thing in each file (anything before is ignored).