reverse_graph.hpp breaks ADL get
- Langage dominant
- C++
- Étoiles
- 392
- Forks
- 239
- Merge moyen
- 1 j 11 min
- PR mergées (30 j)
- 20
Description
Including `reverse_graph.hpp` defines a `get` overload inside the `boost::detail` namespace:
```
namespace detail {
template
struct underlying_edge_desc_map_type {
E operator[](const reverse_graph_edge_descriptor& k) const {
return k.underlying_descx;
}
};
template
E
get(underlying_edge_desc_map_type m,
const reverse_graph_edge_descriptor& k)
{
return m[k];
}
}
```
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::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::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.
----
found from https://stackoverflow.com/questions/52239778/bgl-call-to-strong-components-fails-to-compile-when-random-spanning-tree-hpp-is
Guide de contribution
Ouvrir le guide de contribution
Évaluation
Cette issue n'a pas encore été évaluée.