Good first issues: start contributing to Boost.Graph here

Welcome! 🥳

This is the landing issue for anyone who wants to make a first contribution to Boost.Graph. Every task below is small, self-contained, and reviewable in one sitting. They are real cleanups we want done, not busywork.

Tasks are grouped into three tiers by the C++ background they actually require, so you can pick one that matches where you are.

Tier 1 needs nothing beyond being able to read code
Tier 3 assumes you know what the old workaround was working around.

Note the ci-integration/drone/pr job is known to be flaky. Do not worry too much if it's the only red job!

How to claim a task

Read CONTRIBUTING.md first: it has the superproject setup, the build and test commands, the naming conventions, and the full BOOST_* macro policy table that several tasks below refer to.
Comment on this issue saying which box you are taking, e.g. "Taking 2.1 on strong_components.hpp". We will tick it here so nobody duplicates work.
Ask questions in the comments. There is no such thing as a question too basic on this issue.

Ground rules

Important

Do not run clang-format or reformat files manually.

Running it on a whole file buries a small semantic change under dozens/hundreds of layout lines. A reviewer then has to read every line to find the real edit. It also bloats git diff and git blame, and keeping changes minimal keeps them revertible 😉
We will soon make a repo-wide formatting PR and integrate clang-format in CI 🚀

One file per PR. Every checkbox below is exactly one file and exactly one PR. This is deliberate: small PRs get reviewed much faster, they are easy to revert if we got something wrong, and they let many people contribute in parallel without stepping on each other. Please do not batch several files together to "save time" as it costs review time. The one exception is a header and its matching test when the change genuinely spans both.
One task per PR. Several files appear under more than one task. If your file needs work from two tasks, that is two PRs. Do not mix a macro cleanup with a rename or a formatting pass.
No behavior change. Everything below should be a no-op at runtime. If you find a bug along the way, that is great: open a separate PR, with a regression test.
The test suite must stay green. ./b2 from libs/graph/test runs everything (~10 min). For a single test: ./b2 cycle_canceling_test. If you struggle with local builds, feel free to run on CI.
The CI matrix is gcc-14 + clang-19 over C++14/17/20/23. C++14 is the floor: no structured bindings, no if constexpr, no inline variables, no single-argument static_assert.
Do not run clang-format. We will soon make a repo-wide formatting PR and integrate clang-format in CI.

Do not touch these files

The SGB (Stanford GraphBase) and LEDA adaptors are only built when SDB / LEDA roots are passed to b2, so nothing in this list is currently verified by CI.

include/boost/graph/leda_graph.hpp
include/boost/graph/stanford_graph.hpp
test/leda_graph_cc.cpp
test/stanford_graph_cc.cpp
example/girth.cpp
example/leda-concept-check.cpp
example/leda-graph-eg.cpp
example/miles_span.cpp
example/roget_components.cpp
example/topo-sort-with-leda.cpp
example/topo-sort-with-sgb.cpp

Tier 1 (no C++ background required)

You need to be able to read code and run the build on CI. That is it. Start here if this is your first Boost PR.

1.1 Triage the `TODO` / `FIXME` comments

Zero C++ required. ~24 comments in include/. Not a PR: a comment on this issue.

Go through the TODO/FIXME/XXX comments in include/ and work out which are stale (already done, or about a compiler nobody uses any more). Comment here with your findings. We will turn the live ones into individual issues and delete the dead ones. Good way to get a feel for the codebase before writing any code.

1.2 Wire up two orphaned tests

Needs: no C++ authoring. One PR each.

These two files exist but are not referenced from test/Jamfile.v2, so they are never built or run. Find out whether they still compile and pass, maybe using Compiler Explorer then either add them to the Jamfile (preferred) or open a PR removing them with an explanation. Either outcome is a useful contribution.

test/bidir_vec_remove_edge.cpp
test/undirected_dfs_visitor.cpp

1.3 `BOOST_FOREACH` to range-based `for`

Needs: range-based for. 19 sites, all in tests and examples: the safest possible first PR.

Watch for the cases that iterate a std::pair of iterators: those need boost::make_iterator_range(...) (see 1.4).

test/incremental_components_test.cpp
test/grid_graph_test.cpp
example/incremental-components-eg.cpp
example/incremental_components.cpp
example/graph-thingie.cpp

1.4 `BGL_FORALL_*` → `make_iterator_range` + range-based `for` (tests and examples)

Needs: range-based for. ~55 expansions across 19 files.

The BGL_FORALL_* macros predate range-based for. We are standardising the whole library on one iteration idiom:

for (auto v : boost::make_iterator_range(vertices(g)))

with #include <boost/range/iterator_range.hpp>.

Macro	Replacement range expression
`BGL_FORALL_VERTICES(_T)(v, g, G)`	`boost::make_iterator_range(vertices(g))`
`BGL_FORALL_EDGES(_T)(e, g, G)`	`boost::make_iterator_range(edges(g))`
`BGL_FORALL_OUTEDGES(_T)(u, e, g, G)`	`boost::make_iterator_range(out_edges(u, g))`
`BGL_FORALL_INEDGES(_T)(u, e, g, G)`	`boost::make_iterator_range(in_edges(u, g))`
`BGL_FORALL_ADJ(_T)` / `BGL_FORALL_ADJACENT`	`boost::make_iterator_range(adjacent_vertices(u, g))`

This is a migration, not a deprecation. iteration_macros.hpp stays, keeps working, and is not being removed. Plenty of downstream code uses it. Do not add deprecation attributes or warnings in these PRs. The goal is that BGL's own code reads one way. Leave iteration_macros.hpp, iteration_macros_undef.hpp and example/iteration_macros.cpp untouched; the last one demonstrates the macros on purpose.

break and continue behave identically. The macro's odd nested-loop shape exists precisely to make break work, and range-for gives you that for free.

1.5 `NULL` → `nullptr`

Needs: knowing why nullptr is better. 11 sites.

example/minimum_degree_ordering.cpp (4)
include/boost/graph/dimacs.hpp (3)
include/boost/pending/stringtok.hpp (1)
include/boost/pending/relaxed_heap.hpp (1)
include/boost/graph/detail/connected_components.hpp (1)
example/implicit_graph.cpp (1)

Skip example/iohb.c — it is C, NULL is correct there.

1.6 Documentation for undocumented headers

Needs: AsciiDoc and patience; C++ only to write one small example. One page per PR.

The docs are AsciiDoc under doc/ (Antora). Several public headers have no page at all. Each needs a short page: what it is for, the synopsis, one compilable example, and a link from the relevant index. Pick one and follow an existing page's structure.

Tier 2 (comfortable with templates)

You should be able to read a function template with three template parameters without flinching. No metaprogramming required.

2.1 `BOOST_STATIC_ASSERT` → `static_assert`

Needs: templates, and understanding what the assertion is checking. 69 sites.

Because we compile as C++14, the message argument is mandatory. You have to write one. A good message says what the user did wrong, not what the condition is: prefer "the graph type must model IncidenceGraph" over "is_incidence_graph<G>::value must be true". Remove #include <boost/static_assert.hpp> if it becomes dead.

2.2 `BGL_FORALL_*` migration in public headers

Needs: dependent types and ADL. ~65 expansions across 28 headers.

Same idiom and same rules as 1.4. The difference: these are templates, so the macros used are the _T variants, which exist only to place a typename in front of the iterator type. That disappears entirely with auto, so _T and non-_T collapse to the same replacement.

Two things to check in your file: whether the loop body mutates the graph (a few algorithms add or remove edges while iterating. Semantics are unchanged, since both the macro and make_iterator_range evaluate vertices(g) once, but it deserves a second look), and whether the file still needs its iteration_macros.hpp / iteration_macros_undef.hpp includes afterwards.

2.3 Template parameter naming

Needs: template syntax only. Pure rename, 16 sites.

Per the naming table in CONTRIBUTING, template parameters are PascalCase. These files still use lowercase names, which reads as if they were concrete types. Rename consistently through declaration and definition. Nothing outside the file should need to change; if it does, the parameter name has leaked into a public alias. Flag it rather than fixing it silently.

include/boost/graph/detail/adjacency_list.hpp (6). For example edge_descriptor and incidence_iterator as parameter names, actively confusing next to the real typedefs of those names; see 3.3 first
test/graphviz_test.cpp (4)
include/boost/graph/detail/array_binary_tree.hpp (2). node_type
include/boost/graph/graphviz.hpp (1)
include/boost/graph/graph_concepts.hpp (1)
include/boost/graph/detail/shadow_iterator.hpp (1)
test/subgraph.cpp (1)

2.4 `BOOST_USING_STD_MIN` / `BOOST_USING_STD_MAX`

Needs: ADL, and why Windows breaks unparenthesised min. ~42 sites.

Replace the macro with parenthesized calls at the use site: (std::min)(a, b). The parentheses are not optional. They stop the Windows min/max macros from expanding. Add #include <algorithm> where missing.

2.5 `throw()` → `noexcept`

Needs: exception specifications and how they changed across standards. 15 sites.

throw() was deprecated in C++17 and removed in C++20, and our CI matrix includes both. Most occurrences are on exception-class destructors and what() overrides. Note that destructors are already implicitly noexcept, so in many cases the specification can simply be dropped.

include/boost/graph/exception.hpp (8). Start here, it sets the pattern
include/boost/graph/loop_erased_random_walk.hpp (2)
include/boost/graph/graphviz.hpp (2)
include/boost/graph/graphml.hpp (2)
include/boost/graph/bipartite.hpp (1)

Tier 3 (you need to know what the workaround was for)

These require judgement about what the old code was compensating for. Say in your PR what you concluded and why; "this branch is dead on our matrix, because …" is exactly the right kind of PR description here.

3.1 `BOOST_STATIC_CONSTANT` → in-class `static constexpr`

Needs: ODR-use, and why C++14 has no inline variables. 25 sites.

The trap: in C++14 a static constexpr data member that is ODR-used still needs an out-of-line definition. In practice these constants are used in constant expressions only, so it rarely bites. But if you hit a link error, that is why. Say so in the PR if you had to add a definition.

include/boost/pending/property.hpp (7)
include/boost/graph/two_bit_color_map.hpp (4)
include/boost/graph/topology.hpp (3)
include/boost/graph/one_bit_color_map.hpp (3)
include/boost/graph/named_function_params.hpp (2)
include/boost/graph/erdos_renyi_generator.hpp (2)
include/boost/graph/betweenness_centrality.hpp (2)
include/boost/graph/mesh_graph_generator.hpp (1)
include/boost/graph/graphml.hpp (1)

3.2 Delete dead `BOOST_NO_*` configuration branches

Needs: Boost.Config, and the ability to tell a dead branch from a live one.

These guard workarounds for compilers we no longer support. Delete the branch never taken on our toolchains and keep only the modern path. Still one file per PR. But please post your analysis of the macro in a comment here before opening the first PR for it, so we agree on the reasoning once rather than per file. A macro is only fully gone once every file below it is ticked; the last PR in each group is the one that also removes the macro from the CONTRIBUTING policy table.

BOOST_NO_STD_ITERATOR_TRAITS. The biggest win, 25 sites:

include/boost/graph/isomorphism.hpp
include/boost/graph/detail/permutation.hpp
include/boost/graph/detail/array_binary_tree.hpp
include/boost/graph/edge_list.hpp
include/boost/graph/properties.hpp
include/boost/pending/mutable_queue.hpp
example/put-get-helper-eg.cpp

BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. Not in the CONTRIBUTING table yet; propose the removal in your analysis comment and we will confirm:

BOOST_NO_CXX11_ALLOCATOR:

include/boost/graph/r_c_shortest_paths.hpp
include/boost/graph/adjacency_matrix.hpp
example/container_gen.cpp

BOOST_BORLANDC:

include/boost/graph/random.hpp
include/boost/graph/graph_concepts.hpp

BOOST_NO_STD_ALLOCATOR:

include/boost/graph/adjacency_matrix.hpp
example/container_gen.cpp

BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP:

include/boost/graph/graph_concepts.hpp
test/bfs.cpp

One file each:

BOOST_NO_MEMBER_TEMPLATE_FRIENDS in include/boost/pending/queue.hpp
BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS in include/boost/graph/sequential_vertex_coloring.hpp
BOOST_NO_SFINAE in include/boost/graph/overloading.hpp
BOOST_DEDUCED_TYPENAME in include/boost/graph/copy.hpp
BOOST_NO_CXX11_RVALUE_REFERENCES, BOOST_NO_CXX11_SMART_PTR and BOOST_NO_AUTO_PTR in include/boost/graph/detail/adjacency_list.hpp. All three in that one file; see 3.3. For BOOST_NO_AUTO_PTR, drop the std::auto_ptr branch and keep std::unique_ptr unconditionally: std::auto_ptr was removed in C++17, so that branch is already unreachable across most of our matrix. Update the stale comment above it too.

Leave BOOST_NO_STDC_NAMESPACE, BOOST_NO_EXCEPTIONS and BOOST_NO_CXX17_STRUCTURED_BINDINGS alone — those are still doing real work.

3.3 `detail/adjacency_list.hpp`

Needs: real template fluency.

This one header carries 25 BOOST_STATIC_ASSERTs, three BOOST_NO_* macros, 6 misnamed template parameters and one BOOST_USING_STD_MIN. It is the most-instantiated header in the library and mistakes there break everything downstream. Perfectly doable, but please do not make it your first PR. It is four separate PRs, one per task, not one big one.

What a good PR looks like

Title: Replace BOOST_STATIC_ASSERT in graph_concepts.hpp
Description: what you changed, which box from this issue, anything that surprised you.
Diff: one file, one task, no unrelated reformatting.
CI green on the full matrix.

Maintainers aim for a first-pass review within two weeks. If your PR is sitting untouched past that, ping this issue. That is not rude, it is helpful.

Happy to help anyone for pretty much anything. Just ask below !

Taking 1.4 on test/mcgregor_subgraphs_test.cpp

Taking 1.2 on test/undirected_dfs_visitor.cpp (and I'll look at test/bidir_vec_remove_edge.cpp next as a separate PR).

Wire up test/undirected_dfs_visitor.cpp in the test Jamfile

Taking 1.5 on example/minimum_degree_ordering.cpp

1.5 NULL -> nullptr: include/boost/graph/dimacs.hpp done.

@Becheler

@Becheler @jeremy-murphy @NNhanptnk @cxljs
Taking 1.2 on test/bidir_vec_remove_edge.cpp — TL;DR would you consider removing the tests? Or should this be a compile-fail (simplify the test if we're just testing for compile fail). This is not meant to work - in detail/adjacency_list.hpp - BOOST_STATIC_ASSERT((!is_same< EdgeListS, vecS >::value)); this line is in a bunch of place
7465bc2 Remove bidir_vec_remove_edge (@DougGregor ) dropped it from the tests, the file has instructive comments and a reason why only build-and-traverse-only configuration is allowed for vecS as EdgeListS
3eadd82 (same author) Fixes for EdgeListS=setS and static_asserts for broken functionality when EdgeListS=vecS. (the commit when the aforementioned static_asserts were added)

@Becheler @jeremy-murphy @NNhanptnk @cxljs Taking 1.2 on test/bidir_vec_remove_edge.cpp — TL;DR would you consider removing the tests? Or should this be a compile-fail (simplify the test if we're just testing for compile fail). This is not meant to work - in detail/adjacency_list.hpp - BOOST_STATIC_ASSERT((!is_same< EdgeListS, vecS >::value)); this line is in a bunch of place 7465bc2 Remove bidir_vec_remove_edge (@DougGregor ) dropped it from the tests, the file has instructive comments and a reason why only build-and-traverse-only configuration is allowed for vecS as EdgeListS 3eadd82 (same author) Fixes for EdgeListS=setS and static_asserts for broken functionality when EdgeListS=vecS. (the commit when the aforementioned static_asserts were added)

test/bidir_vec_remove_edge.cpp is testing an error in template that lives in <boost/graph/adjacency_list.hpp> that you mentioned. I think we should test this and supposely it SHOULD pass if the template error still existed ! (which is weird, testing KNOWN BUGS to pass.).

Personally, I would do these :

test test/bidir_vec_remove_edge.cpp (if passed move to 2 else ignore it)
fix the error in adjacency_list.hpp (look at 2.1 BOOST_STATIC_ASSERT → static_assert)
Fix 3.3
test test/bidir_vec_remove_edge.cpp again, and this time it SHOULD FAIL.

This test related to many changes upstream, and the sequential change matters.

We are moving away from BOOST_STATIC_ASSERT (2.1) thus 3eadd82 seems not ideal.

@NNhanptnk

@NNhanptnk I'm a bit confused? That code just wouldn't compile no? also we are not removing BOOST_STATIC_ASSERT correct? simply making it static_assert? Like I thought this just shouldn't be allowed (and the assert enforces it)
I guess I should find out (or ask?) if the issue about the iterator invalidation fixed? But that would still be different issue altogether @Becheler

@Becheler

From 2.1 BOOST_STATIC_ASSERT → static_assert , quote :

Remove #include <boost/static_assert.hpp> if it becomes dead.

Thus, yes, we are migrating away from BOOST_STATIC_ASSERT. Why ? Because BOOST_STATIC_ASSERT is a macro written before static_assert is a thing (on C++11). My hypothesis is that BOOST_STATIC_ASSERT is written pre-C++11.

I would consult @Becheler on this too.
My take is if test/bidir_vec_remove_edge.cpp does not compiled and you already included it in test/Jamfile.v2 , then we should let it be.
We should open another issue for this because there are other related problems. I have not investigated and have no idea what is the problem with the LOGIC in adjacency_list class template that test/bidir_vec_remove_edge.cpp mentioned.
Please let us know if you find it @reach2sayan.

@NNhanptnk

@NNhanptnk @reach2sayan thank you for this historical dive ! 🤗

I had a similar adventure recently.

In this kind of case, the best thing would be to consolidate current behavior.
The current behavior is desirable: in short, when edges are stored as vector, adding edges is fine because it preserves existing indices. But removing one edge would renumber all indices past the point of removal. So instead of "fixing" it (there is no fixing it), Doug secured the trade-off by saying "as long as you don't remove stuff, you can use this efficient data structure". Then he surely checked manually the compilation failed but had no way to wired this in CI at the time (we now do with [compile-fail]).

Instead of removing test/bidir_vec_remove_edge.cpp one could document it as an expected compilation fail. We would want the test to be minimal so that it guards against future regressions (that is someone removing/altering the static assertion).

I propose to do it this way:

Replace test/bidir_vec_remove_edge.cpp with https://godbolt.org/z/1oY4r4d6b
Add [ compile-fail bidir_vec_remove_edge.cpp ] to test/Jamfile.v2, next to bidir_remove_edge.cpp.
In CE check that the only error is the static assertion and that removing the remove_edge line compiles (compile-fail passes on any error, so this makes sure it fails for the right reason)
Run ../../../b2 bidir_vec_remove_edge from libs/graph/test and open the PR referencing Good first issues: start contributing to Boost.Graph here #593.

As a follow-up (I would be ok with it being in the same PR), when these asserts are migrated to static_assert, it would be good to give them a message explaining why removal is rejected when EdgeListS is vecS. Something like:

static_assert(!std::is_same< EdgeListS, vecS >::value,
    "adjacency_list: removing edges is not supported when EdgeListS is vecS "
    "(stored edge indices would be invalidated). Use listS, the default, instead.");

Feel free to open an issue or to reference this one, we are getting a bit specific here, but that's what meta-issues are for ahaha 😆

Thanks again ❤️

@Becheler

I have missed this list! Cool initiative @Becheler - Just an idea: shall this be more like a discussion?

@andreacassioli

@andreacassioli thank you ☺️
It can be a discussion, yes! If this become unamanageable (which I doubt) we could also open a Discussion about the issue to remain structured, although I would keep it simple for now 🙃
Do you have anything in mind ?

Not really, I just felt this issue more like a discussion. Maybe one issue is whether (or when) some changes will be superseded if we move to C++20. But it is very good start somewhere!

I will pick up an item from 2.1 for include/boost/graph/compressed_sparse_row_graph.hpp in the next days

Taking also 3.1 for include/boost/graph/two_bit_color_map.hpp

@andreacassioli

@andreacassioli feel free to take on 3.2 for BOOST_NO_STD_ITERATOR_TRAITS.

This seems a safe move, as i don't think the code was ever exercised: there is a colon instead of a semi-colon line 22 of detail/permutation.hpp : typedef std::ptrdiff_t D : 😅

I would do a separate PR for each of those two files:

isomorphism.hpp : most used of the files, hard to read, non-trivial changes, so we'd want to be able to revert it if necessary.
detail/permutation.hpp: this is unused, undocumented, untested, so any breaking change would go undetected. May require an audit out-there to see if someone is using it and if we could delete it (there should be enough signs it is not meant to be part of the public API though 😆 But this argument must go in a separate PR :)

The other files should be small/trivial changes, you can do them in one PR if you see it fit 😄

Taking 2.1 on include/boost/graph/circle_layout.hpp (and 2.2 on the same file next, as a separate PR).

@Becheler

My next will be 1.1 triage. @Becheler shall I look for other kind of potential dead code like #if 0 blocks?

@andreacassioli

@andreacassioli Absolutely, overall we need to simplify the codebase, the less dead branches the better ! Although I would not be surprised if we find at least one dead branch that is very important 😉

Here the triage list as for 1.1. It include fixme, todo, old compilers mentions and if 0 dead code paths.

The list is grouped by the "label" and each entry has the format

(key) <file name>:<line number> --> <a comment to explain>

key can be

(L) - legit -> something to look into the details or to act somehow (like delete dead code)
(I) - more an improvement than a issue to solve, maybe to track in specific way?
(D) - I am in doubt as I do not have enough context.

FIXME
===========
(L) include/boost/graph/vector_as_graph.hpp:241 -->  something is not robust about the edge type used in a remove_edge overload.

TODOs
========
(I) include/boost/graph/bron_kerbosch_all_cliques.hpp:68  --> potential performance improvement passing a connectivity matrix
(I) include/boost/graph/bron_kerbosch_all_cliques.hpp:201 --> possibility of a further optimization based on the algorithm original paper
(I) include/boost/graph/bron_kerbosch_all_cliques.hpp:220 --> possibility of a further optimization

(L) include/boost/graph/clustering_coefficient.hpp:69 --> propose a set of neighborhood functions for things like num_neighbors
(L) include/boost/graph/clustering_coefficient.hpp:89 --> whether graph type requirement can be reduced

(I) include/boost/graph/dominator_tree.hpp:251 --> point to a new faster algorithm to solve the dominators

(L) include/boost/graph/exterior_property.hpp:54 --> limitation of exterior_property to graph types that do not model the IndexGraph concepts.

(L) include/boost/graph/graph_mutability_traits.hpp:73 --> Find a better name for the add_only_property_graph_tag tag.

(L) include/boost/graph/labeled_graph.hpp:53 --> whether the default map type should be a map (as now) or unordered_map
(L) include/boost/graph/labeled_graph.hpp:338 --> point out labeled_graph class somewhat redundancy
(L) include/boost/graph/labeled_graph.hpp:344 --> labeled_graph to be reconciled with the named_graph

(I) include/boost/graph/metric_tsp_approx.hpp:21  --> a list of potential performance improvement s
(I) include/boost/graph/metric_tsp_approx.hpp:61  --> consider migrating PreorderTraverser to the graph_as_tree header.
(I) include/boost/graph/metric_tsp_approx.hpp:62  --> parameterize the underlying stores of PreorderTraverser so it doesn't have to be a vector.
(I) include/boost/graph/metric_tsp_approx.hpp:225 --> a performance warning

(L) include/boost/graph/one_bit_color_map.hpp:47 --> code upgrade when on c++17 (use shared_ptr)

(I) include/boost/graph/rmat_graph_generator.hpp:181 --> algorithm improvements for undirected graph
(I) include/boost/graph/rmat_graph_generator.hpp:300 --> algorithm improvements for undirected graph

(L) include/boost/graph/subgraph.hpp:368 --> questions the local vertex map value type
(L) iclude/boost/graph/subgraph.hpp:369 --> questions some of the requirements
(I) include/boost/graph/subgraph.hpp:371 --> questions the local vertex map type (map vs unordered_map)

(L) include/boost/graph/subgraph.hpp:874 --> flag a version of remove_vertex for subgraph, with no logic implemented (dead code), as under construction

(L) include/boost/graph/two_bit_color_map.hpp:47 --> code upgrade when on c++17 (use shared_ptr)

(L) include/boost/graph/detail/d_ary_heap.hpp:48  --> code upgrade when on c++17 (use shared_ptr)

(L) include/boost/graph/detail/geodesic.hpp:16 --> question whether this file should be in /detail (not really a todo)

(D) include/boost/graph/detail/labeled_graph_traits.hpp:23 --> a reminder of potential extentions of the label tags hierarchy

(D) include/boost/graph/detail/rapidxml.hpp:1511 -->  possibly verify that code is less than 256 and use replacement char otherwise?

(D) include/boost/graph/planar_detail/boyer_myrvold_impl.hpp:1371 --> it seems an algorithm improvement suggestion, but I am not sure

(L) include/boost/graph/property_maps/constant_property_map.hpp:12 --> suggest to move the file to the property maps library
(L) include/boost/graph/property_maps/null_property_map.hpp:12 --> suggest to move the file to the property maps library 


KCC compiler
=================
(L) include/boost/pending/bucket_sorter.hpp:80 --> private the nested stack class is having access problems
(L) include/boost/pending/is_heap.hpp:11 --> the whole code of this file compiles only if using KCC


VisualAge C++ compiler
========================
(L) include/boost/graph/topology.hpp:34 --> my guess is that the struct point is public otherwise it does not compile 
(L) include/boost/graph/topology.hpp:47 --> my guess is that the struct point_difference is public otherwise it does not compile 


MSVC workaround
==================
(D) include/boost/graph/visitors.hpp:197 --> It seems that the base_visitor template is needed for MSVC workaround


UNDER_CE (Windows CE?)
=======================
(L) include/boost/graph/isomorphism.hpp:418 --> if "under CE", use exit instead of abort


#if 0 
========
L -> delete the dead code 

(L) include/boost/graph/breadth_first_search.hpp:382 --> otherwise call BOOST_GRAPH_MAKE_OLD_STYLE_PARAMETER_FUNCTION

(L) include/boost/graph/compressed_sparse_row_graph.hpp:22 --> avoid to include iostream (which is in general unused)

(D) include/boost/graph/graph_archetypes.hpp:40 --> avoid to define mutability_category
(D) include/boost/graph/graph_archetypes.hpp:499 --> avoid to define mutability_category;

(L) include/boost/graph/graphviz.hpp:499 --> avoid compiling an interface that ... "// This interface has not worked for a long time"

(L) include/boost/graph/isomorphism.hpp:748 --> skip a check that might not work for filtered graph (num edges and vertices)

(L) include/boost/graph/subgraph.hpp:873 --> hide a version of remove_vertex for subgraph, with no logic implemented (dead code)

(L) include/boost/graph/detail/compressed_sparse_row_struct.hpp:26 --> prevent inclusion of iostream unless some debug code is active (which I cannot find)

(D) include/boost/graph/detail/d_ary_heap.hpp:238 --> avoid an expensive validation, I guess used sometimes when debugging (maybe it should be a separate function?)

(D) include/boost/pending/container_traits.hpp:495 --> the active code has an additional check that to me seems redundant, The inactive code seems to me actually correct
(D) include/boost/pending/container_traits.hpp:623 --> disable a version of equal_range_dispatch

(L) include/boost/pending/mutable_queue.hpp: --> hide a function that seems to be sort of a test to check if is_heap is available. I believe the code is dead (the comment is from 2003)

@Becheler

I can take 2.2 for isomorphism.hpp

The task say to coordinate, what does it mean @Becheler ?

@andreacassioli

Wooh amazing @andreacassioli ! 🤩
Coordinate so that several people don't tackle the same item, and avoid useless work. For example:

labeled graph and named graphs are broken and will be deprecated, we don't want to invest there
rapidxml is vendored from property_tree, we don't want to touch it
metric_tsp_approx is being reworked and we would prefer to avoid conflicts
I will have a closer look tomorrow to assess what would need a propre issue tracker, many thanks !

I can take 3.2 for BOOST_NO_CXX11_ALLOCATOR on the two remaining files.

I can take 2.3 for include/boost/graph/detail/adjacency_list.hpp

And 1.5 for example/implicit_graph.cpp

and 1.4 for example/csr-example.cpp

I can take 2.4 for include/boost/graph/topology.hpp

@Becheler

@Becheler I am quite sure I did 2.3 for adjacency_list and graph_concepts, but it is not reflected in the task list. Could you check?

@andreacassioli

@andreacassioli you're right, it's just that you are all so efficient I can't catch up 😢 😂

Navigation Menu

Repository navigation

Good first issues: start contributing to Boost.Graph here #593

How to claim a task

Ground rules

Do not touch these files

Tier 1 (no C++ background required)

1.1 Triage the `TODO` / `FIXME` comments

1.2 Wire up two orphaned tests

1.3 `BOOST_FOREACH` to range-based `for`

1.4 `BGL_FORALL_*` → `make_iterator_range` + range-based `for` (tests and examples)

1.5 `NULL` → `nullptr`

1.6 Documentation for undocumented headers

Tier 2 (comfortable with templates)

2.1 `BOOST_STATIC_ASSERT` → `static_assert`

2.2 `BGL_FORALL_*` migration in public headers

2.3 Template parameter naming

2.4 `BOOST_USING_STD_MIN` / `BOOST_USING_STD_MAX`

2.5 `throw()` → `noexcept`

Tier 3 (you need to know what the workaround was for)

3.1 `BOOST_STATIC_CONSTANT` → in-class `static constexpr`

3.2 Delete dead `BOOST_NO_*` configuration branches

3.3 `detail/adjacency_list.hpp`

What a good PR looks like

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Good first issues: start contributing to Boost.Graph here #593

Description

How to claim a task

Ground rules

Do not touch these files

Tier 1 (no C++ background required)

1.1 Triage the TODO / FIXME comments

1.2 Wire up two orphaned tests

1.3 BOOST_FOREACH to range-based for

1.4 BGL_FORALL_* → make_iterator_range + range-based for (tests and examples)

1.5 NULL → nullptr

1.6 Documentation for undocumented headers

Tier 2 (comfortable with templates)

2.1 BOOST_STATIC_ASSERT → static_assert

2.2 BGL_FORALL_* migration in public headers

2.3 Template parameter naming

2.4 BOOST_USING_STD_MIN / BOOST_USING_STD_MAX

2.5 throw() → noexcept

Tier 3 (you need to know what the workaround was for)

3.1 BOOST_STATIC_CONSTANT → in-class static constexpr

3.2 Delete dead BOOST_NO_* configuration branches

3.3 detail/adjacency_list.hpp

What a good PR looks like

Activity

NNhanptnk commented on Sep 21, 2026

reach2sayan commented on Sep 21, 2026

NNhanptnk commented on Sep 22, 2026

cxljs commented on Sep 22, 2026

reach2sayan commented on Sep 22, 2026

NNhanptnk commented on Sep 22, 2026

reach2sayan commented on Sep 23, 2026

NNhanptnk commented on Sep 23, 2026

Becheler commented on Sep 23, 2026

andreacassioli commented on Sep 23, 2026

Becheler commented on Sep 23, 2026

andreacassioli commented on Sep 23, 2026

35 remaining items

andreacassioli commented on Oct 11, 2026

Becheler commented on Oct 12, 2026

reach2sayan commented on Oct 13, 2026

andreacassioli commented on Oct 15, 2026

Becheler commented on Oct 20, 2026

andreacassioli commented on Oct 21, 2026

andreacassioli commented on Oct 21, 2026

Becheler commented on Oct 21, 2026

andreacassioli commented on Oct 22, 2026

andreacassioli commented on Oct 23, 2026

andreacassioli commented on Oct 23, 2026

andreacassioli commented on Oct 23, 2026

andreacassioli commented on Oct 25, 2026

andreacassioli commented on Oct 27, 2026

Becheler commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1.1 Triage the `TODO` / `FIXME` comments

1.3 `BOOST_FOREACH` to range-based `for`

1.4 `BGL_FORALL_*` → `make_iterator_range` + range-based `for` (tests and examples)

1.5 `NULL` → `nullptr`

2.1 `BOOST_STATIC_ASSERT` → `static_assert`

2.2 `BGL_FORALL_*` migration in public headers

2.4 `BOOST_USING_STD_MIN` / `BOOST_USING_STD_MAX`

2.5 `throw()` → `noexcept`

3.1 `BOOST_STATIC_CONSTANT` → in-class `static constexpr`

3.2 Delete dead `BOOST_NO_*` configuration branches

3.3 `detail/adjacency_list.hpp`