Subject: Re: [boost] Header Inclusion practices
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-04-11 18:28:34
On 04/11/17 20:55, Robert Ramey via Boost wrote:
> // example using he safe numerics library
> #include <iostream>
> #include <limits>
> #include <boost/integer.hpp>
> #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 <boost
> libraries are depended on the whole b2 business. I didn't want the
> incubator version of the the safe numeric library to depend on the
> library having been accepted into boost have have b2 run. Also I don't
> like adding the library to boost - and having to change all the headers.
> What if someone want's to run the tests/examples outside of the boost
> As far as I know this question has never been asked before and I'm
> curious to know what others might have to say about this.
I'm not sure I understood the question. But in the example above I would
rather avoid relative paths. The example should assume it's external to
the library, so that the user is able to just copy/paste the code and
start playing with the code. It should also demonstrate how the user is
supposed to use the library, and the user most likely is supposed to add
an include path to the library to compile his code.
Actually, I try to never ever use relative paths in source code, except
for the trivial case #include "header.h", where header.h is in the same
directory. The reason for this is that relative paths obfuscate
dependencies between different parts of the program.
#include "../oranges/orange.h" // why the dependency?
| | |-orange.h
#include <oranges/orange.h> // dependency on a common library
Naturally, when apples are built, an include path is added to common.
This approach also proves useful if for some reason you decide to change
project layout later.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk