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.
