Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I've got a file such as this:
#ifndef STDINCLUDE
#define STDINCLUDE
#include <memory>
#include <stdexcept>
#endif
I want this file to be included in every header file, because I use stuff from those headers so much. Is it preferable to include this via compiler options (-I stdinclude.hpp), or should I physically include them in each header? (#include <stdinclude>). Note that I am attempting to be cross-platform-minded. I use cmake to serve atleast Unix and Windows.
For many compilers, including gcc, the -I option specifies a directory to search for include files, not an individual file. I don't know of an option to include a single file. For one thing, such an object would not specify where in the source to place the #include directive.
Even if there were such an option, I would not recommend using it. The choice of which headers to include is information that should be in the source file. If you were to specify it on the command line, you'd be decoupling that information from the source file (presumably it would be in a Makefile or something similar), which would make the source code more difficult to understand and maintain. And anyone trying to port your software to a different build system would have to port that option separately.
Presumably most of your source files include headers other than stdinclude.hpp. Including that one file via a compiler option, and everything else via explicit #include directives, is arbitrary and potentially confusing.
By having an explicit
#include <stdheader.hpp>
or, since it's part of your project:
#include "stdheader.hpp"
you let the reader know that your code uses something defined in that header.
If that's all there is to your stdheader.hpp file, you might even consider dropping it and having each source file use
#include <memory>
#include <stdexcept>
directly. That way, your readers will know exactly what's being #included, and won't have to know or care what's in stdheader.hpp. That's a pretty good benefit for one extra line per file. If stdheader.h becomes more elaborate, using it might make more sense.
It's a good idea to #include whatever files a source file relies on. If you have a standard set of headers to be included in every file, #include them all in a single header file like your stdinclude.hpp. That way, you only have to edit one file when you change the set of standard headers.
That said, you don't want to have to compile each of those header files in the standard set every time you compile one of your source files. Most compilers provide a mechanism for creating a precompiled header for just this reason. A precompiled header lets you avoid having to compile the same header files over and over, significantly reducing the build time for your project.
Ideally for a cross platform code i would try to keep things simple (there are many out there to get more ideas)
#ifdef Linux
#include <stdio.h>
#elif WIN32
#include <something.h>
#else
#error "Which OS?"
#endif
Given this i will now give -DLINUX or -DWIN32 on command line.
What is the critical difference?
As the code evolve, many more files gets added or removed under the includes, but keeping this approach, the guy who compile doesn't have to remember editing such includes.
Ideally, all includes must be written statically only. But switching can be done more as functionality (different module, os, dependencies) rather than individual mess.
