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.
And includes the optional header that was transitively included by the
spirit header before. Hopefully this will speed up compile times, as the
RouteParameters header is used in a lot of translation units.
`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.
so that proxy server don't try to reuse the connection. Given that
osrm-routed does *not* support keepalive the Connection: close response
header should be set.
- 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).
