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
This improves preprocessing times in favour of worse query performance.
Core size can be set over the --core parameater, default is the old
behaviour to fully contract the graph.
This reverts commit 8ade26b4a4.
One of the assertions triggers when run on an extract of Serok. Since
this code does not fix any bugs, I'll just revert this for now.
This definetly needs investigation.
Moved the GeometryCompressor's free_list_maximum into a member variable of the class.
(+UniqueNumber() commented out since it is not being used anywhere in all of OSRM)
There was absolutely no need for free_list_maximum to be a static variable and it caused major issues in my code.
Short description:
- I ran osrm-prepare's Prepare().Process(..) function in my own code multiple times for multiple files
=> After the first file is done, free_list_maximum is still on the same size, but a new GeometryCompressor will start at a size of 100 again.
=> Indices broken.
