Lots of header files

[DrChill]

I was wondering if having this many header files is a good idea.

#include <iostream>
using std::cout;   using std::endl;
using std::string;
#include <string>
#include <sstream>

#include "SDL/SDL.h"
#include "SDL/SDL_image.h"
#include "SDL/SDL_ttf.h" 

#include "globals.h"
#include "shape.h"
#include "functions.h"
#include "timer.h"
#include "text.h"
#include "button.h"

#include "score.h"
#include "paddle.h"
#include "ball.h"    
#include "gamestates.h"                             

Mainly the ones I made myself, I am also making Pong game.

Also, if it is normal professionally to have this many I would like to know that as well.

[moorecm]

Just include what you need and call it a day. One thing to watch out for, though, is intermixing using detectives with the includes. The compiler first processes source files by using the C preprocessor to expand included files into a single "translation unit". This means that the using directives apply to the contents of the headers in the current translation unit.

[Disch]

#include "globals.h"

Probably not a good idea. =P

If you don't want to go through this jumble for multiple cpp files, you can have "group" headers.... like headers that just include common headers of a specific category.

For example, Score, Paddle, Ball, and GameStates will probably be used together a lot of the time, so you might want to make a group header:

// gamecommon.h

// - put include guard here

#include "score.h"
#include "paddle.h"
#include "ball.h"
#include "gamestates.h" 

Then you can just #include "gamecommon.h" in your cpp files instead of including each one seperately.

Those SDL headers might also go well in a group header.


This can be a timesaver, but it also can be over-abused easily. Don't get carried away and start putting every single header in a single group file. Try to keep the groups reasonable.

[tummychow]

Really, as long as you aren't including anything you don't need, you've guarded all those headers and you can explain to yourself and others (theoretically) what each one is for, you can include as many headers as you like. Nesting the headers down into a few groups will be more efficient for you, but it might obfuscate the headers to an outside reader. If it's just your stuff anything goes, really. (As long as you don't encourage yourself to do stupid stuff but that doesn't seem particularly dumb to me.)

[helios]

Many source files+many include files=endless compilation time.
If you have too many headers being included it's probably better to use precompiled headers to avoid recompiling the same lines over and over again. I have a 20+ kLOC project with a compilation size of 1.5 MLOC. Yeah, it can easily blow up like that.

[DrChill]

Ok, thank you for the replies.

I probably won't group due to obfuscation, although I am the only one who has seen my game.

@helios

Many source files+many include files=endless compilation time.

I thought that when you compiled the header files sort of tagged on the top? I need to do research on how the compiler works, not just the usual, but down to the specifics.

I have a 20+ kLOC project with a compilation size of 1.5 MLOC. Yeah, it can easily blow up like that.

First look at what you typed: O.O
How does the compiler do header files?

Also do you include comments in LOC count?

[chrisname]

How does the compiler do header files?

Essentially, it just copies the contents of the header file to the including file, replacing the #include with the entire content of the file. Some compilers (actually it's the preprocessor that does it) probably have different methods, but in the end you get the source code of the header file in your source file.

[helios]

How does the compiler do header files?

It's just a literal copy-paste. The problem is that if your inclusion graph is a complex as mine (I swear, I never managed to finish drawing it, despite my several attempts) it's possible that every source file ends up including every header, which includes your headers, the language headers, and any third party headers you're using. Since everything is including everything, and because each source file is an independent compilation unit, you end up compiling all your headers once per source file.

Suppose you have 10 sources and 10 headers, each with 1 kLOC, and each source includes every header. The project as a whole consist of only 1000*10+1000*10 LOC (20 k), but because each header is compile 10 times, the compiler has to compile 1000*10+1000*10*10 LOC (110 k). This is of course, a mild example. Once you factor in language and system headers, it becomes really huge (windows.h is humongous).

Also do you include comments in LOC count?

I used a utility called cloc which I believe counts only "actual" lines of code. I do know it excludes empty lines and comments from the count.

[chrisname]

@helios,
How long does this project take to compile?

used a utility called cloc

I've used cloc too; it's pretty cool.

[DrChill]

I only use one source file (is that bad too?) and use headers as more of a organizer.

Also I wish I had a small elf that followed me around and told me if I was developing a bad programming habit. Is there any article on such things (hopefully not just someone griping)?

[helios]

On my computer, around a minute using either VC++ or GCC. It would be faster if it was possible to build more than one source at once.
ICC takes ten times as long, but most of that time is spent optimizing before linking.

EDIT: Depends on the size of the project. Splitting into several files is mostly a matter of organization and convenience, as trying to edit a very large file is cumbersome. Notepad++, for instance, becomes sluggish after one or two million characters.
In some cases, a single file is better, though. One of the things I like about SQLite is that it's a single C file that can be easily included into any project.

[firedraco]

Speaking of header inclusion, would doing this:

#ifndef STUFF
#define STUFF
#include "stuff.h"
#endif 

give less lines of code than:

#include "stuff.h"
//with the ifndefs/stuff inside stuff.h 

I think the former gives less but I think it would depend on if the compiler checks the ifndefs before doing the includes (of course this would probably require way more stuff since you would still need to include the ones *not* inside the ifndef)

[helios]

The former preprocesses faster because the preprocessor doesn't have to fetch the file needlessly. I would prefer to take a little longer to compile than to do something like that, though.

[chrisname]

In some cases, a single file is better, though. One of the things I like about SQLite is that it's a single C/C++ file that can be easily included into any project.

Maybe on every compilation, you could run a script from your Makefile that generates a single source file from all of the source files and header files to make preprocessing easier on the compiler. Then the new source file is included with the release to make it easier to include the program with your own... or you could just use pre-compiled object files, of course.

ICC takes ten times as long, but most of that time is spent optimizing before linking.

If ICC is the Intel C/C++ Compiler, then how good are those optimizations? I'd imagine they're pretty damn good. Is it closed source or open?

[helios]

Maybe on every compilation, you could run a script from your Makefile that generates a single source file from all of the source files and header files to make preprocessing easier on the compiler.

wat
I think you're describing what a precompiled header is, very poorly.

If ICC is the Intel C/C++ Compiler, then how good are those optimizations?

An image crossfade transition effect (where you put an image on top of the other and increase the alpha of the top layer until it is completely opaque) implemented in software went from ~50 fps to ~70 fps, IIRC. I'd say you should seriously consider whether the very increased compilation time is worth the extra speed.

Is it closed source or open?

It's commercial.

[chrisname]

I think you're describing what a precompiled header is, very poorly.

Never mind...

~50 fps to ~70 fps

But that's a huge difference!

It's commercial.

Doesn't answer my question at all. Open source programs can be commercial too. I'll assume closed is implied.

[DrChill]

What are you designing if you don't mind me asking?

[helios]

But that's a huge difference!

I suppose. Like I said, you should judge the speed vs. space (I forgot to mention. Binary size also goes up) and compilation time tradeoff for each project. A large project will probably see more benefit in compiling only the most critical parts like this.

Open source programs can be commercial too.

I don't know what came over me.
Yes, it's proprietary.

What are you designing if you don't mind me asking?

You mean me? An engine.
Also, not designing. Cloning (and enhancing). It's actually quite a lot of work when there's practically no documentation. I'm convinced one compression algorithm used was pulled out of the original coder's derriere. Suffice it to say, Google yields nothing relevant for "SPB" or "SPB compression".

[chrisname]

I don't know what came over me.

There's that satire again :)

Yes, it's proprietary.

Oh... I might use it for my emulator (I'm starting again from scratch because I lost the source) when I do a 0.01 release (if is probably more appropriate than "when" here) because that will want to be as optimized as possible... but probably not for much else.

An engine.

A what engine? A game engine? A motor engine?

[helios]

A game engine? A motor engine?

Yes.