add missing const values; use some using instead of typedef

[andreacassioli]

Before submitting

• This PR targets the develop branch.
• I searched for an existing PR or issue covering the same change. (actually this PR superseeds successive_shortest_path_nonnegative_weights const bugfix #160)
• My contribution is licensed under the Boost Software License 1.0.

Type of change

• Bug fix
• New feature or API addition
• Refactor (no behavior change)
• Documentation
• Build, CI, or tooling
• Other (specify below)

Does this PR introduce a breaking change?

• Yes (describe migration impact below)
• No

What this PR does

It superseeds #160

Motivation

Some const qualifiers are missing. Not a big deal, but it make it clearer to have them in place. Notice that the named parameter interface cannot be changed without introducing a breaking change: the reason is that it defaults to use graph internal property map as output, thus the graph must be modifiable to extract that map.

Incidentally I change some typedef to using.

Testing

Existing tests should be fine

Checklist

• Existing tests pass (b2 in the test/ directory).
• New behavior is covered by a test, or this is a docs / build / refactor change.
• Documentation was updated if user-facing behavior changed.
• No new compiler warnings on the platforms I built against.

[github-actions]

Compiler-warning counts vs develop (auto-generated).
PR run 27845986552 vs develop run 27551679795 (cf1839a3dc).

Job	Baseline	After	Delta
macos (clang, 14)	46	46	0
macos (clang, 17)	41	41	0
macos (clang, 20)	41	41	0
ubuntu (clang-19, 14)	46	46	0
ubuntu (clang-19, 17)	46	46	0
ubuntu (clang-19, 20)	46	46	0
ubuntu (clang-19, 23)	46	46	0
ubuntu (gcc-14, 14)	28	28	0
ubuntu (gcc-14, 17)	28	28	0
ubuntu (gcc-14, 20)	28	28	0
ubuntu (gcc-14, 23)	28	28	0
windows_msvc_14_3 (msvc-14.3)	974	974	0

[Becheler]

I don't think we should use const on private data. The argumentation around my mental model of const has been developed here by Arthur O'dwyer: https://quuxplusone.github.io/blog/2022/01/23/dont-const-all-the-things/

See particularly the "const members are never a good idea" section where he says constness should be enforced by the public API, not by marking private data const: https://quuxplusone.github.io/blog/2022/01/23/dont-const-all-the-things/

Specifically here, the operator is already const so it adds no security:

reference operator[](key_type v) const {
    return get(distance_, source(v, g_)) - get(distance_, target(v, g_)) + get(weight_, v);
}

And more importantly, a non-static const data member deletes the implicit copy/move assignment operators, and this class is a property map created by make_mapReducedWeight(...) and handed to Dijkstra by value (weight_map(...)). Property maps are value types you copy around so making it non-assignable makes it a non-regular type for no benefit :/

[Becheler]

To be clear, the other changes are great so thank you for this ! ❤️

In hindsight maybe what's missing is a concept check to ensure the maps are not written to ?

BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept<Weight, edge_descriptor> ));
BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept<Distance, vertex_descriptor> ));

[andreacassioli]

Thanks for the pointers @Becheler I got used to maybe too many const lately and not much time to dig into more C++!

I have made the changes to you propose.