C++20 support

[lbt0116]

The project currently faces compatibility issues with C++20, such as disallowing template parameters in destructors (e.g., ~ConstraintSetTpl()) and the use of non-constexpr types like std::string in constant expressions, which prevent leveraging modern C++20 features. To address this, I propose ensuring full C++20 compliance by updating problematic code, replacing non-compliant patterns, and adding explicit C++20 support in the build system (e.g., CMake flags). This would enable developers to benefit from C++20's improvements like concepts, ranges, and enhanced constexpr, ensuring the library stays modern and developer-friendly.

[ManifoldFR]

Hello, thanks for your interest in aligator!

Could you elaborate on some of these points? I am not familiar with C++20 beyond concepts.
We haven't looked at implementing C++20 features yet, due to both lack of time and lack of return on investment: inherent problems in even several robotics software stacks (looking at you, ROS) limited us to C++14 when we first started. Getting to C++17 was already a difficult negotiation.

We could get onto it with your help and the help of other developers if we could get a report (and a PR down the line) on e.g. noncompliant code and how to fix the CMake build flags.

[ManifoldFR]

Hello @lbt0116, would you have time to come back to this? I will be converting this to a discussion in the meantime.

[lbt0116]

I apologize for the delayed response. Initially, I intended to integrate Aligator into my code environment, utilizing C++20's atomic shared pointers for data sharing. However, I discovered that Aligator has conflicts with the C++20 standard. As a result, I later restructured the program into a distributed architecture using ROS 2, running Aligator in a separate node process to resolve the compatibility issues.

[ManifoldFR]

No worries!

I did not know about this feature. This allows to avoid race conditions when accessing shared_ptr ?

What is your use case here, modifying aligator problems or accessing objects in the problem workspace (a lot of shared_ptr in there) from another thread?

Do you remember which issues you had when trying to compile aligator in C++20 ? In both CMake and the C++ code itself? I might have some projects using aligator together C++20 coming down the line so it might also be useful to some of us here at simple-robotics.

[lbt0116]

Atomic smart pointers can provide lock-free operations. While shared_ptr ensures thread safety only for reference counting, atomic smart pointers guarantee complete thread safety. My usage involved storing Aligator's inputs and outputs in atomic smart pointers to facilitate data sharing in a multi-threaded environment. When compiling Aligator with C++20, I recall encountering an issue like "template-id not allowed for destructor." This behavior was modified in C++20. Therefore, isolating Aligator and other algorithms using C++20 into separate processes seems to be a better choice. ROS 2 provides an intra-process communication option, which facilitates efficient communication between different processes on the same host.

[ManifoldFR]

A quick regex search found where that could come from, upstream inside proxsuite-nlp/constraint-set.hpp. Here the destructor of ConstraintSetTpl is qualified using a template parameter, which should be wrong and is the only instance of this across aligator & proxsuite-nlp. I'll push a commit upstream. Thanks!

[ManifoldFR]

Can you try compiling proxsuite-nlp (commit 6c2ed54c7bb8d4e7f72df4e5e38a57a16e2793a8) + aligator with your setup?

[lbt0116]

I compiled the version you provided, and indeed the previous ConstraintSetTpl issue has disappeared. However, there is still a problem related to fmt, as shown below:

kinodynamics-fwd.hxx:27:5: error：call to non-‘constexpr’ function ‘std::string fmt::v11::format(format_string<T ...>, T&& ...) [with T = {long unsigned int, long unsigned int}; std::string = std::__cxx11::basic_string; format_string<T ...> = fstring<long unsigned int, long unsigned int>]’
27 | ALIGATOR_DOMAIN_ERROR(
| ^~~~~~~~~~~~~~~~~~~~~

[lbt0116]

I will try it tomorrow and give you feedback😄

[lbt0116]

I can not find refs/heads/topic/domain-errors-va-args with exit status 128.

[ManifoldFR]

It was merged into devel yesterday, so you can just try devel :)

[lbt0116]

Thx for your help, it can run at c++20 right now😄

[ManifoldFR]

Great ! Please tell us if you have another issue later on, aligator is still under active development :)