ROS 2 and C++20

tylerweaver · 2023-10-25T22:58:12.852Z

Because the ISO C++20 standard is very recent, GCC’s support is experimental .”

very is doing some heavy lifting there. It is like saying, “Foxy is a very recent version of ROS 2”.

For maximum compatibility, why use C++ over C if compatibility is always more important than ergonomics and features of the language?

C++20 and C++23 are some of the most underwhelming releases of C++ compared to 11 and 17. Many blame COVID and the ISO process for being poorly designed for remote collaboration.

Concepts are excellent for library authors of templates. The brick operator and mdspan might have some interesting applications for the ergonomics of DSLs. PMR is probably the most relevant feature for robotics applications. Deducing this is a cool feature with many applications, go watch one of the Ben Dean talks on it. There are a few features that are not easily replicated without newer standards from 20 and 23.

Phil_Brown · 2023-10-26T01:21:48.586Z

There are a few features that are not easily replicated without newer standards from 20 and 23.

This is the second time in this thread I’ve seen mention of “a few features”, without any specifics.

How about mentioning even just one specifically, and explaining why you think it is worthwhile to go through a bunch of upgrade hassle?

ibrahimqazi · 2023-10-26T01:48:13.233Z

Looking at your comments I feel that someone is speaking on the behalf of me.

tylerweaver · 2023-10-26T16:13:06.110Z

Here are a list of C++20 features I want to use in interfaces (header files):

concepts, reason: simplify code that uses enable_if and make it more readable
expected, reason: using today through a header file I vendored (tl_expected in ros) but it would be nice to just use it through the stl
operator<=>, reason: simplifying comparison overloads
ranges, reason: composable algorithmic code, I’m already using this sort of through a library called flux. Sadly it is implemented using C++20 so I can’t use flux in the public interface of ROS packages. This one heavily depends on the concepts feature.

Designated initializers is a C++20 feature that made it into C so unless you use -Wpedantic you can join me today and use it.

I thought I spelled out what features I wanted because you asked but noticed you also wanted reasons. Here are some reasons.

I’ve heard several people say they’d like to use PMR in their algorithmic code. I listed the features I know I want to use in the code I write and maintain. I’m not entirely convinced PMR is a good change in C++.

Here is a list of C++23 features I want to use as soon as possible:

deducing this, reason: simplifies code where you previously had to specify lvalue/rvalue overloads, simplifies CRTP
operator[] and mdspan, reason: ergonomic image transform code

thejeeb · 2023-10-27T01:55:20.225Z

Thanks @tylerweaver. I was going to reply with pretty much a similar set of features but you did a much better job than me.

I wanted to point an example of a minor C++20 feature that came up recently. A developer recently wanted to use map.contains(key) and I said it was only available in C++20. So the developer was resigned to using map.find(key) != map.end() or map.count(key) > 0, both of which are are poor substitutions for existence of a key in a map. My point here is not that this is a reason to move to C++20. It is that one of the goals of the evolution of C++ by the standards body is to make the language easier to use and understand. My example is admittedly a poor example but I can point to extremely complex written C++ code that can replicated in much simpler understandable syntax in languages like C# or Python, for example. And no, this is not a “code prettifying hack”. It is code that I write that I want myself and other developers to clearly understand the intention of the code a year or two from now, without having to “decipher” the meaning of the code. It leads to better code maintenance. The standards committee are continually introducing features that help make our code more expressive and intentional without sacrificing the performance guarantees of C++. This includes new language features, code semantics and new library features all of which are intended to improve the use and understandability of your code.

One more thing, maybe minor. If you want new developers joining the ros 2 ecosystem, then you most likely want to keep updating the ecosystem to the latest language features. Users are less likely to join the ros 2 ecosystem, if it is still stuck on C++14 and they have been using C++26 in their previous job.

I’m not minimizing the effort it takes to qualify the ros 2 core packages with C++20 - I’m sure that is a significant effort. But as an end user developing a ros 2 application, the fact that the latest ros 2 distro has made C++20 the default C++ version does not in any way mandate you to use C++20 in your own code. A developer is free to write his/her application using the constructs of any earlier version of C++ including C++98 if you so choose. That is the backwards compatibility guarantee of successive version of C++. The only time they have deprecated and removed features is when they are broken e.g. auto_ptr. You should be able to recompile your C++11 code and keep chugging along without using any of the newer language features. I have even found bugs in my existing application code when compiling with a newer compiler e.g. when there is stricter checking.

At some point, you have to move forward with the language so developers who want to use it can. The only question is when. You can make the same argument why we need to keep adding features to the ros 2 core and just stick with ‘foxy’ and just only fix bugs. The ros 2 distro upgrades are even worse since they break both source and binary compatibility. But that is acceptable to gain the new features.

Phil_Brown · 2023-10-27T15:20:35.000Z

Its not the same argument at all. You can add features to an API, while leaving existing ones in place. People who want to use the new features use them, and people who dont want to, dont, and everyone is happy.
Whereas changing the minimum compiler version, FORCES change on everyone.

That being said, some of the specific examples for C++20 do sound a little useful, at least
(Even if the rest of them are not, IMO )

tylerweaver · 2023-10-27T15:28:37.518Z

C++20 and C++23 is maybe 10% better than C++17. Rust is 10x better. The transition is 10x harder though. I’m happy to advocate lightly for upgrading C++ but if I have to choose what to spend my time on it will always be the future where we all worship a crab god.

Phil_Brown · 2023-10-27T17:05:32.000Z

Eh.
We already have python for “easy”, and C++ for “fast, lowlevel”. Moving from C++ to Rust is just replacing one “fast, lowlevel” implementation with another one. It’s not evolutionary.
Personally, what I’d like to see as a new direction for the future, is “easy, AND fast”. eg: golang support for everything.

JM_ROS · 2023-10-27T17:09:22.908Z

I’m totally confused by this whole discussion, nobody prevents you from using C++20 in your own code. The ABI between c++17 and c++20 are fully compatible, so it does not matter what standard ros uses internally to compile their stuff.

Edit: Got it, this is the other way around, people wanting to compile ros2 on centos4

tylerweaver · 2023-10-27T17:20:23.524Z

I feel like I shouldn’t make moveit2 require a C++20 compiler until ROS 2 does… but maybe no one would notice…

tylerweaver · 2023-10-27T17:22:32.438Z

Rust is “fast, reliable, productive: pick three”… golang feels like a toy, no proper sum types or generics and a gc, bleh.

thejeeb · 2023-10-27T22:47:06.456Z

You’re right. There’s nothing preventing me from using C++20. Except I have to specify usage of it in every package. And then remember to remove it when it becomes the ros2 default. I’m sure there are clean ways to do. I’m just wondering what the ros2 roadmap is which doesn’t look like has been determined.

thejeeb · 2023-10-27T23:00:47.253Z

The ros2 API sometimes has breaking changes in a new distro. I have had to fix compilation errors when switching to a new distro. So yes, in theory, the API can leave existing ones in place but that is not the case in practice. In this case, it does force change on everyone. On the other hand, a C++ version forces change under the cover but as an end user you won’t even notice it - you just recompile your code without having to change anything. You’re going to recompile anyway when switching to a new distro that supports the new C++ version and you’ll be fixing compile errors due to API changes not C++ version changes.

I’m not sure what the argument is against this other than the work it takes to qualify the ros2 core on a new version which I admit may not be trivial. Anyway, my original question was answered. It will happen at some time, but it is unclear when. Till then I have the option of using C++20 on my own packages by specifying the version to the compiler.

tylerweaver · 2023-10-30T20:19:46.987Z

thejeeb:

I’m just wondering what the ros2 roadmap is which doesn’t look like has been determined.

Technically I think you should specify the version of C++ you use in your cmake even if ROS has a default. That way if someone tries building it on a system that is not the ros buildfarm that has different defaults it will still work.

thejeeb · 2023-10-30T21:05:57.137Z

Not sure where the ROS default is specified. Must be somewhere in ament. I am curious.

I can see your point about non-ROS-specific packages. For ROS packages, I’m not sure I would want to have the C++ version in every cmake. It’s something else that needs to be maintained. I guess I could be convinced otherwise.

emersonknapp · 2023-10-31T00:13:22.382Z

I don’t believe a ros2 default is specified in any central place. Individual packages specify their C++ standard version in CMake, and we say that the “ros2 core is on X version” when all (any?) packages under https://github.com/ros2/variants/blob/master/ros_core/package.xml now specify that version. (could be wrong on that but it’s my understanding)

clalancette · 2023-10-31T01:00:02.061Z

Yep, you have it exactly correct.

thejeeb · 2023-10-31T03:59:22.131Z

Hmm. Good to know. For some reason, I got it into my head that C++17 features were available to me when I switched to Galactic. But it’s because my compiler defaulted to C++17.

This also seems to imply that all packages should probably specify the C++ version in the cmake as @tylerweaver suggested instead of relying on the compiler default.

peci1 · 2023-10-31T09:29:44.727Z

If I get it correctly, C++ is forward-compatible up to some very obscure things like auto_ptr. So if you write a package working with the default compiler of an older ROS distro, it should also work with newer ROS distros. Up to those obscure things, of course. So it doesn’t seem to me very important to add the standard declarations. They’re one more thing to maintain. It really seems to me the best choice depends on your development process and the number of C++ features you use.

gbiggs · 2023-11-01T04:55:21.935Z

REP 2000 specifies the minimum C++ version that each ROS distribution is required to work with. This is, in general, derived from the combination of the C++ version available in the G++ compiler on the version of Ubuntu that distribution is targetting, and the need to ensure users who work in more restricted environments (e.g. safety-critical systems and embedded systems) will be able to work with the source code.