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 tree.
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. Bad: | |-apples | |-apple.h | |-oranges |-orange.h apple.h: #include "../oranges/orange.h" // why the dependency? Good: | |-common | |-oranges | | |-orange.h | |-apples |-apple.h apple.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.