graph-v2
graph-v2 copied to clipboard
General-purpose C++ graph library
Currently, the users of `breadth_first_search` view need to type the following in order to break from the view iteration: ```c++ for (auto v : bfs) { if (cond) bfs.cancel(graph::cancel_search::cancel_branch); }...
Currently, the breadth-first search stores a vector `colors_` of a three-state (8-bit) `three_colors` enum. The implementation never distinguishes between the black and the gray state. This can be changed to...
`vertex_info` and `edge_info` are class templates for defining aggregates. When passed `void` as a template parameter: * the corresponding aggregate member disappears, * the corresponding nested type is `void`: https://github.com/stdgraph/graph-v2/blob/desc4/include/graph/graph_info.hpp#L41....
The default allocator type for the views is `allocator`, which is strange: the only place where they are used is in the `std::queue
All the breadth-first (and probably other) views `bfs` expose function `size(bfs)` which *does not* return the number of elements in the represented input range. `static_assert(std::ranges::sized_range);` returns `true`. `std::ranges::distance(bfs)` compiles returns...
Algorithm `dijkstra_shortest_distances` (and probably others) allows me to provide a custom `compare` function. It is only constrained (syntactically and semantically) by concept `basic_edge_weight_function`. What are the intended usages? It looks...
`dijkstra_shortest_distances`, unless explicitly overridden, uses `std::function` to store the weight function. This is not desirable. An allocating, type-erasing type for a callback goes against the generic library design. The idea...
1. What is a real-world use case for visitors? 2. Especially for the exotic one, like `on_initialize_vertex`? Looks like, I can call it myself on every graph vertex before calling...
File `graph/graph.hpp` contains a lot of concepts, all of which are marked "For exposition only". The following concepts: * `basic_targeted_edge` * `basic_sourced_edge` * `basic_sourced_targeted_edge` * `targeted_edge` * `sourced_edge` * `sourced_targeted_edge`...
There is something wrong with every usage of concept `_common_vertex_range`, for instance: https://github.com/stdgraph/graph-v2/blob/master/include/graph/graph.hpp#L124 We have ```c++ template concept _common_vertex_range = sized_range && requires(G&& g, vertex_iterator_t ui) { vertex_id(g, ui); };...