csr_out_edge_iterator and csr_in_edge_iterator are part of the
boost::detail namespace, so they need to explicitly qualify
iterator_core_access in their friend declarations. Note that
csr_edge_iterator already gets this correct.
Works fine with c++11, thanks!
System: (K)Ubuntu 16.04 LTS
Compiler: g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Try to 'g++ -c' the four SGB examples girth.cpp, miles_span.cpp,
roget_components.cpp, and topo-sort-with-sgb.cpp.
(1) SGB 2002-01-30 changed the 'Associated Press scores' from 'ap0' and
'ap1' to 'ap'. This preprocessor macro (sic!) collides with numerous
function parameters in 'named_function_params.hpp'. '#undef'ining the
macro doesn't break the BGL examples.
(2) girth.cpp fails because of a missing 'null_vertex()' function.
(3) roget_components.cpp invokes 'strncmp()' from the C library.
(4) topo-sort-with-sgb.cpp hickups because of a missing 'vertices()'
function. Following roget_components.cpp and putting the collective
SGB header up front fixes this.
* trac 11374: find_flow_cost() not working with bundled properties.
When using bundled for Weight and Cost properties, find_flow_cost() coudln't work because the properties had been "hard coded" instead of using generic types.
Fixes https://svn.boost.org/trac/boost/ticket/11374
* trac 12038: max-flow algorithms not working with named parameters.
The named parameter "Capacity" was not working. I just had to reverse the order of get_param_type parameters.
Here are the max-flow algorithms that are curretly not working with the named parameter "Capacity":
- edmonds_karp_max_flow,
- push_relabel_max_flow,
- boykov_kolmogorov_max_flow.
Fixes https://svn.boost.org/trac/boost/ticket/12038
* trac 11374: find_flow_cost() not working with named parameters and bundled properties at the same time.
When using bundled properties as well as named parameters, there was an error.
What happened is that the "named parameters" version of find_flow_cost() was not using a generic return value, hence the error.
Also, the return value_type was using edge_capacity_value instead of edge_weight_value (which is the type of a flow cost).
I fixed it using the trick used for edmonds_karp_max_flow(): add `edge_weight_value` to named_function_params.hpp.
* Unit test find_flow_cost() with bundled properties & named params.
-> unit tests for trac 11374
I used the existing min_cost_max_flow_utils.hpp, but I had to make the graph of getSampleGraph() more generic.
In the first place, I wanted to make a compile-only test but I also made
the test runnable so we check that
- find_flow_cost works() correctly with bundled properties
- successive_shortest_path_nonnegative_weights() also works with bundled properties
To run this test, this is a bit painful...
I had to run the entire graph-related tests.
- I commented the other tests except for graph in ./status/Jamfile.v2
- in this same dir, I ran `../b2`
One issue though: csr_graph_test seems to be broken on my boost copy, I may have an issue with updating the submodules or something...
* Unit test edmond_karp_max_flow with named params & bundled properties.
-> unit tests for trac 12038
As the previous commit, I rely on min_cost_max_flow_utils.hpp.
And I also made a runnable test instead of a simple "compile-time" test.
* Indented with 2 spaces instead of tabs
Thanks for the patch!
Pass the indexMap parameter through to the dominator_visitor and use it
instead of get(vertex_index, g). This allows this algorithm to be used
for graphs without a vertex_index property.
Addresses bug #11742.
This appears to be fixed, we may have to patch this to ensure there's no backward compatibility issues with older compilers. Thanks for the bug report and patch.
The bug that it never gets called with the current construction remains.
The C++ standard deprecates use of <stdio.h>, <stdlib.h> etc., and suggests using <cstdio>, <cstdlib> etc.
Some trailing whitespace removed in affected files because of a setting in my editor
dead code surrounded by #if 0 ... #endif removed
* Fix labeled_graph constructors
* Wraparound bug leads to out-of-bounds addressing.
Seems obvious that `> 0` was meant (seeing the comments).
Also, if `vertices_size_type` is unsigned - which it usually (always?) is - the loop condition was never false.
* Finally, one constructor didn't properly initialize the graph property
* Copy vertex property on add_vertex
Tested with clang on El Capitan, thanks!
array_binary_tree_node::children_type::iterator pretends to be a bidirectional iterator but does not define operator--, which results in compile breaks with Visual C++ 2015.
