[Suggestion] Enhance Compiler Compatibility via range-v3 Fallback for C++26 std::ranges

[0xtaruhi]

Dear Maintainers,

I am writing to express my appreciation for your work on this project. Its modern C++ design is truly impressive!

During my evaluation, I observed that the project leverages C++26 std::ranges features, necessitating a state-of-the-art compiler such as GCC 15. While this forward-looking approach is commendable, it may inadvertently pose a significant adoption challenge for developers in environments where upgrading compilers is difficult, such as on Linux LTS distributions or within contexts governed by strict corporate toolchain policies.

To address this, I respectfully propose a compatibility enhancement: implementing range-v3 as a compile-time fallback for std::ranges.
This may be achieved using a preprocessor-driven approach. A compatibility header could select the appropriate implementation at compile time. This enhancement may expand the project's potential user base while fully preserving its modern C++ foundation.

If you agree with this suggestion, I am willing to prepare and submit a pull request to implement it!

[0xtaruhi]

I'm sorry for the noise. I have just found the closed issue #6 and now better understand the context. I see that the strict GCC 15 requirement is primarily due to the project's use of std::views::concat.

Even with this understanding, I believe the proposed range-v3 fallback remains a valuable approach. My enthusiasm for this suggestion is personal: I am keen to use your high-performance library in one of my projects, but I am constrained by a deployment server with a fixed toolchain that cannot be upgraded. This single compiler requirement is currently the only blocker. A conditional fallback to range-v3 would solve this.

Thank you for your patience and consideration ^-^

[fhamonic]

Hello Oxtaruhi,

Thanks for your interest !
Indeed, it is a good Idea to handle the fallback to from c++26 ranges to range-v3 ones !

Before going full C++26, I tried to make STL and range-v3 ranges interoperable and it is in fact a nightmare because they don't have exactly the same requirements for some concepts like input_range and view.
Thus, if C++26 ranges features are not available, we should replace every STL ranges calls by range-v3 ones (instead of just replacing std::views::concat by range-v3's views::concat).

Your suggestions seems appropriate. I imagine it to be a header named, for example, ranges_freatures.hpp that, depending on a compile definition, that defines proxy functions for either STL ranges calls or range-v3 ones :

#ifndef MELON_USE_RANGEV3

#include <ranges>

namespace melon {
    template <typename... Ranges>
    constexpr auto ranges_concat(Ranges... ranges) {
        return std::views::concat(ranges...);
    }

    ...
}

#else

#include "range/v3/view/concat.hpp"

namespace melon {
    template <typename... Ranges>
    constexpr auto ranges_concat(Ranges... ranges) {
        return views::concat(ranges...);
    }

    ...
}

#endif

If you want to issue a PR I will happily help you for it ! (I am currently on vacation but will ne available in a week)
Like you said this will expand the project's potential user base but also make possible again for the github workflow to run the unit tests :)

[0xtaruhi]

Thanks for the positive feedback and the clear direction. Please enjoy your vacation—there's no rush on my end.

That's a very helpful point about the interoperability issues. It makes perfect sense to switch to range-v3 completely as a fallback. I'll follow your proposed design using a dedicated header with proxy functions.

I will get started on a PR based on this approach. Glad to know it will also help the CI workflow.

Thanks again😊

[stefanottili]

OpenROAD just recently switched to c++20 and uses https://github.com/The-OpenROAD-Project/lemon-graph as a c++20 compatible version of lemon 1.3.1

I stumbled across melon when looking for an actively maintained lemon successor.
Preferably as a "drop in replacement".

c++20 would be a hard requirement, anybody working on that ?

[fhamonic]

Hi stefanottili,

The fallback to range-v3 is currently not my priority as it would break interoperability with STL ranges, as described above.
However, melon can be compiled with c++20 as soon as the headers using c++23 and c++26 features are not #included (I just tested and can confirm).
At the moment these headers are utility/static_digraph_builder.hpp for C++23 and algorithm/bidirectional_dijkstra.hpp, views/complete_digraph.hpp and views/undirect.hpp for C++26.

It seems that OpenROAD is mainly using lemon::ListDigraph, lemon::Preflow and lemon::NetworkSimplex that would not require any of these problematic headers. Besides, utility/static_digraph_builder.hpp can easily be made into C++20 without side effects.

The last limitation is that melon does not currently have an implementation for the network simplex : it is actually on my todo list and seeing such a good use will undoubtedly make it climb :)

[spoorendonk]

I have a gcc-14 compatible branch. I implemented minimum missing C++26 feature std::views::concat so the headers are now C++23 compatible and can be compiled with gcc-14 on ubuntu 24.04 without any extra stuff.

I tested only the bidirectional_dijkstra, so maybe I have missed something somewhere.

I can make a PR if interested? https://github.com/spoorendonk/melon/tree/gcc14-build

And great work with melon. Thanks

[fhamonic]

Well done!
Yes, feel free to make a PR, I'll gladly merge it, thanks :)

I may also use you concat_view fallback for my other project which, given your github profile, may interest you too : https://github.com/fhamonic/mippp

[spoorendonk]

I opened PR #8

I will check out the other project also.