Small fixes I didn't want to include in unrelated PRs.
There are a few left in `storage.cpp` but since it's a single function
in 600 lines of code, I didn't want to touch the mess. The others are
safe to remove, cucumber and test run on Finland gives 👍.
rather than being cached in the StaticRTree. This means we
can freely apply traffic data and not have stale values lying
around. It reduces the size of the RTree on disk, at the expense
of some additional data in RAM.
Phew, a lot of classes were affected by this. The rationale for the
changes are as follows:
- When a type X declares any constructor, the default constructor is
not declared, so there is no need for X() = delete there. In fact,
there is brutal difference between those two: deleted members
participate in overload resolution, but not-declared members do not!
- When a type X wants to be non-copyable (e.g. to be only movable, like
threads, unique_ptrs, and so on), you can either do it by inheriting
from boost::noncopyable (the old way), or better declare both (!) the
copy constructor _and_ the copy assignment operator as deleted:
X(X const&) = delete;
X& operator=(X const&) = delete;
We had tons of types with deleted copy constructors that were lacking
a corresponding deleted copy assignment operator, making them still
copyable and you wouldn't even notice (read: scary)!
References:
- http://accu.org/content/conf2014/Howard_Hinnant_Accu_2014.pdf
- http://www.boost.org/doc/libs/master/libs/core/doc/html/core/noncopyable.html
Note: I know, I'm quoting Hinnant's extraordinary slides a lot, but
getting the sematic right here is so incredibly important.
`pow(2, 16)` is not `2 << 16` but rather `1 << 16`.
With this change we cut memory usage in half for the XORFastHash's two
tables. Adapts XORFastHashStorage, memory usage reduction by factor two.
- Throwing an assertion exception for proper stack unwinding, making
sure destructors are called
- On in Debug mode, in Release, enable via:
cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_ASSERTIONS=ON
Current problem that I'm seeing is that some code is not catching
exceptions or worse silently swallowing them. Would like to check the
whole pipeline before merging this in.
Fixes issue #1864. Given the simple set-up:
a --> b --> c
^-----------|
This would translate into an edge based graph (ab) -> (bc),
(bc) -> (ca), (ca) -> (ab).
Starting at the end of the one-way street (ab) and going to
the beginning, the query has to find a self-loop within the
graph (ab) -> (bc) -> (ca) -> (ab), as both nodes map to the
same segment (ab).
Found with
```
daniel@x1c /t/o/i/util> for header in *.hpp
echo -n $header:
ag -iQ $header ../../ --noheading | wc -l
end
...
fixed_point_number.hpp:0
range_algorithms.hpp:0
...
```
Only two. Surprises me to be honest.
But we're cleaning up for quite a bit now.
