As long as I can remember, it's been my practice to write program code
to minimize dependencies on the environment in which it is built. By
environment I mean things external to the code itself like environmental
and command line variables, directory context etc. As part of this I
use rules for header file inclusion:
a) use #include "header.hpp" for files in the same directory as the
current source file.
b) use #include "other directory/header.hpp" for files which are known
to be in a specific place relative to the current file. This shows up
in things like: #include "../include/header.hpp" for tests and examples.
c) use #include for files which
are found by looking in directories listed in "-I" switches and
environmental variables (INCLUDE). I generally try not to depend upon
any environmental variables as I always forget to set them or even how
to set them. Come to think about it. I don't know how my build system
finds the boost libraries. I presume it's through some IDE/Bjam/CMake
setting which I can never remember.
d) use #include <iostream> for standard library components. Presumably
these are routed to some directory relative to the compiler.
So some of my source files look like:
// interval.hpp header for safe numerics library
#include <limits>
#include <cassert>
#include
#include <array>
#include
#include
#include
#include "utility.hpp" // log
#include "checked_result.hpp"
#include "checked.hpp"
and
// example using he safe numerics library
#include <iostream>
#include <limits>
#include
#include "../include/cpp.hpp"
#include "../include/exception.hpp"
#include "../include/safe_integer.hpp"
#include "../include/safe_range.hpp"
This has raised consternation in some quarters - but I don't see
anything wrong with it. It basically means that only the
