We were stuck on the 4.5.0 tag from develop, since we searched for the
latest tag, but release tags are done on the master branch.
This commit rips out all the code for deriving the version on git tags.
Instead, we define major, minor, and patch versions in the CMakeLists
and then pass it on to:
- the `libosrm.pc` `pkg-config` file
- a `version.hpp` header that makes use of the preprocessor's string
concatenation to provide an easy way for generating version string
literals such as "v4.8.0".
That is, in the source code please now use the following defines:
#define OSRM_VERSION_MAJOR "@OSRM_VERSION_MAJOR@"
#define OSRM_VERSION_MINOR "@OSRM_VERSION_MINOR@"
#define OSRM_VERSION_PATCH "@OSRM_VERSION_PATCH@"
#define OSRM_VERSION "v" OSRM_VERSION_MAJOR "." OSRM_VERSION_MINOR "." OSRM_VERSION_PATCH
With C++11 the stdlib gains:
- `std::stoi` function family to convert from `std::string` to integral type
- `std::to_string` to convert from number types to `std::string`
The only reason for hand-writing the conversion code therefore is
performance. I benchmarked an `osrm-extract` with the hand-written code
against one with the stdlib conversion features and could not find any
significant difference (we switch back and forth between C++ and Lua,
shaving off a few us in conversion doesn't gain us much).
Formatting arithmetic types in the default format with given precision
requires streams, but is doable in a few lines of idiomatic stdlib code.
For this, there is now the following function template available:
template <Arithmetic T, int Precision = 6>
inline std::string to_string_with_precision(const T);
that requires integral or floating point types and returns a formatted
string in the defaukt format with the given precision applied.
In addition this completely rips out Boost.Spirit from the `casts.hpp`
header, resulting in faster compile times.
Boom!
References:
- http://en.cppreference.com/w/cpp/string/basic_string/stol
- http://en.cppreference.com/w/cpp/string/basic_string/to_string
- http://www.kumobius.com/2013/08/c-string-to-int/
This switches out the `<variant/optional.hpp>` implementation of the
optional monad to the one from Boost.
The following trick makes sure we keep compile times down:
- use `<boost/optional/optional_fwd.hpp>` to forward declare the
optional type in header, then include the full blown optional header
only in the implementation file.
- do the same for the files we touch, e.g. forward declare osmium types,
allowing us to remove the osmium header dependency from our headers:
`namespace osmium { class Relation; }
and then include the appropriate osmium headers in the implementation
file only. We should do this globally...
References:
- http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/index.html
- https://github.com/osmcode/libosmium/issues/123
This caches iterators, i.e. especially the end iterator when possible.
The problem:
for (auto it = begin(seq); it != end(seq); ++it)
this has to call `end(seq)` on every iteration, since the compiler is
not able to reason about the call's site effects (to bad, huh).
Instead do it like this:
for (auto it = begin(seq), end = end(seq); it != end; ++it)
caching the end iterator.
Of course, still better would be:
for (auto&& each : seq)
if all you want is value semantics.
Why `auto&&` you may ask? Because it binds to everything and never copies!
Skim the referenced proposal (that was rejected, but nevertheless) for a
detailed explanation on range-based for loops and why `auto&&` is great.
Reference:
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
* Adds a data structure, RasterSource, to store parsed + queryable data
* Adds bindings for that and relevant data structures as well as source_function and segment_function
* Adds relevant unit tests and cucumber tests
* Bring-your-own-data feature
Apply `clang-modernize` (based on Clang 3.6) transformations to the
codebase while making sure to support Clang>=3.4 and GCC>=4.8.
We apply the transformations in parallel to speed up the quite
time consuming process, and use our `clang-format` style file
to automatically format the code respecting our coding conventions.
We use the following self-explanatory transformations:
* AddOverride
* LoopConvert
* PassByValue
* ReplaceAutoPtr
* UseAuto
* UseNullptr
This required a `compile_commands.json` compilation database, e.g.
ccmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=1
for CMake or check Bear for a Makefile based solution (or even Ninja).
git ls-files -x '*.cpp|*.h' | \
xargs -I{} -P $(nproc) clang-modernize -p build -final-syntax-check -format -style=file -summary -for-compilers=clang-3.4,gcc-4.8 -include . -exclude third_party {}
Boom!
References:
* http://clang.llvm.org/extra/clang-modernize.html
* http://clang.llvm.org/extra/ModernizerUsage.html
The error may not be the first item in the stack while we're inside the error handler. ::from_stack() works OK outside the error callback, but not inside.
