How Can I Know Which Boost Graph Properties are Available in a Template Adjacency List?

Question

Consider the following two adjacency lists:

#include <boost/graph/adjacency_list.hpp>

using Graph_1 = typename boost::adjacency_list<boost::vecS,
                 boost::vecS,
                 boost::directedS,
                 boost::no_property,
                 boost::property<boost::edge_weight_t, double> >;
Graph_1 graph_1(0);

struct VertexBundle { int some_int; };
struct EdgeBundle { double weight; };
struct GraphBundle { std::string name; };

using Graph_2 = typename boost::adjacency_list<boost::listS,
                 boost::listS,
                 boost::undirectedS,
                 VertexBundle,
                 boost::property<boost::edge_index_t, double, EdgeBundle>,
                 GraphBundle>;
Graph_2 graph_2(0);

They differ in their containers, directed category, and the properties defined for vertex, edge, and graph.

Now, for example with boost::detail::is_directed( boost::graph_traits<Graph>::directed_category ) I hold a boolean whether the graph of type Graph is directed or not, as taken from this SO question .

But how can I read out other information about the Graph Type's properties, especially which internal/bundled properties the graph has defined?

I found this boost docs page on graph_traits , but I'm not quite getting the hang of it. To beginners, the boost graph docs are a bit hard to read...

I'm thankful about any hints!

Answer 1

I already showed most of this here .

However I do notice that I made a mistake: I specialized boost::graph_property<Graph, Tag> where it should have been boost::property_map<Graph, Tag> . See https://www.boost.org/doc/libs/1_64_0/libs/graph/doc/property_map.html

You can either SFINAE on that or the result of get(property_tag_t{}, graph) .

---

It looks like property_map might not even be very sfinae friendly - perhaps it hard-fails on eager instantiation of details. Mmm. That would mean you "can't" - you'll just have to always take parameters for any optional property-maps and default them to the library implementation. That way, if people fail to provide one when they should, it will croak with a hard compiler error

I'm happy to be proven wrong here, but I fear that BGL is showing its age here. I'm not sure whether c++20 std::detected<> has anything new/better here. Intuitively, I think, no, because it would require a core language change surrounding the extent of Sfinae.