If included before other algorithms it can mess up the ADL on get calls from within that detail namespace. E.g. in strong_components.hpp the Tarjan visitor does
if (get(comp, w) == (std::numeric_limits<comp_type>::max)())
This call fails to compile if reverse_graph.hpp had been included before. In fact, the developers probably found this out when they decided to only include the transpose_graph.hpp header /after/ the Tarjan implementation (and before the Kosaraju version that requires it).
The exact mechanics of the bug are not completely clear to me. But I guess it sits on the intersection of ADL and partial ordering. In fact using
using ::boost::get;
if (get(comp, w) == (std::numeric_limits<comp_type>::max)()) // ...
does enable ADL at instantiation time. But I suspect the structural fix would be to avoid declaring a get overload inside the detail namespace.
Including
reverse_graph.hpp
defines aget
overload inside theboost::detail
namespace:If included before other algorithms it can mess up the ADL on
get
calls from within that detail namespace. E.g. instrong_components.hpp
the Tarjan visitor doesThis call fails to compile if
reverse_graph.hpp
had been included before. In fact, the developers probably found this out when they decided to only include thetranspose_graph.hpp
header /after/ the Tarjan implementation (and before the Kosaraju version that requires it).The exact mechanics of the bug are not completely clear to me. But I guess it sits on the intersection of ADL and partial ordering. In fact using
does enable ADL at instantiation time. But I suspect the structural fix would be to avoid declaring a
get
overload inside the detail namespace.found from https://stackoverflow.com/questions/52239778/bgl-call-to-strong-components-fails-to-compile-when-random-spanning-tree-hpp-is