boostorg / boostorg/graph

reverse_graph.hpp breaks ADL get

未关闭
#116 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
C++
星标
392
派生
239
平均合并
1 天 11 分钟
30 天内合并 PR
20

描述

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

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。