tags:

views:

496

answers:

6

I find long sequences of standard includes annoying:

#include <vector>
#include <string>
#include <sstream>
#include <iostream>

Considering these header files change only very rarely, is there a reason why I should not make a "std.h" file #including all std headers and just use that everywhere?

+18  A: 

Including unnecessary header files will increase compile times.

Brian Ensink
+6  A: 

You might like to add these to your project's standard, precompiled header file: if your project has a standard, precompiled header file, and if your files aren't supposed to be reusuable in other projects which might have a different standard header file.

ChrisW
If other projects aren't using the same standard header files, they really do need to be kept separate.
David Thornley
You can (and should) have a separate precompiled header file per project.
Eddie Parker
Because different projects may have different precompiled headers, I wouldn't rely on anything in particular being included into the project's precompiled header, if the source file is supposed to be used in more than one project.
ChrisW
Instead, if a source file will be used in more than one project, then it should *explicitly* include whichever header files (including 'standard' header files) it needs.
ChrisW
A: 

This would also increase the size of your object files, which probably isn't a big deal these days.

Edited per comments that the binary would not actually be larger

JohnMcG
Doesn't the linker eliminate unused code when linking into a binary?
Yes it does, this isn't a valid point for that reason.
workmad3
But wouldn't code from headers that is never used be included?
JohnMcG
Yes the preprocessor will include it, the compiler will compile it, and the linker will strip it off I believe ;)
Also - <vector> is a header for std::vector<T>. Templates generate code when instantiated. If vector is not used, there's no code generated, so the linker won't even need to strip it.
MSalters
+1  A: 

If you're not actually using it, it should not be included.

Rob K
A: 

It reduces your code readability (oddly enough :)). By including them all in one header file, you can no longer tell just by looking at the top of a file what translation units are including iostreams (and therefore doing IO), fstream (and doing file access) etc.

I'd suggest using an IDE that allows folding of include statements, like eclipse, and have it automatically fold the includes. That removes them from your view while still making the dependencies clear.

workmad3
Hmm that's not a problem :) If not from the class name, then at least from the documentation the class's purpose must be apparent. Thanks though!
+4  A: 

I hate to create a new answer for this, but I basically want to put both Brian Ensink and ChrisW's answer together:

First off, as Brian mentioned, your compile times will skyrocket as it's including tonnes of files every time it compiles. Luckily it looks like it's standard includes, so they shouldn't be changing all that often, but it'll still suck.

You can mitigate this by buildnig a precompiled header that'll only be re-compiled when you do a full rebuild, toast the PCH file, or change something included in it - but that's why PCH files normally only have system wide includes, or things that don't change that often.

Eddie Parker