Making compatible with C++ 20

[jerabaul29]

I wanted to use the format C++ 20-style on strings:

https://en.cppreference.com/w/cpp/utility/format/format

But got an error message. I think this may indicate that the makefile makes use of an older C++.

• Is that the right diagnostic?
• Would it be possible to make the makefiles C++ 20 compatible?

[jerabaul29]

OK, just checked, I have a quite old compiler that does not support C++20, that may be the reason. Still keeping open just to check if others are able to use C++20 features.

[siebenschlaefer]

Not all compilers are ready for C++20, some LTS versions of popular Linux distributions are not even ready for C++17. That's why there's a line CXX_STANDARD 14 in the file CMakeLists.txt.
If your compiler supports C++20 and you have a fairly recent version of CMake then you can just modify that line.
Does that help?

[jerabaul29]

This is perfect, many thanks :) . Do you think it would be possible to add a line or two of explanations about this on the readme of this repo? :) .

[siebenschlaefer]

Good idea!
I would love to have that documented somewhere.
Even better if it would contain the reasons for that decision so that we can upgrade to C++17 or later at some point in the future.

[arcuru]

The downside of this is for mentors. A common workflow is for the mentors to download and run the exercise locally, so:

1. Their local environment would need to support it, and not everyone wants (or can) run a bleeding edge compiler.
2. They'd have to recognize the problem and change the CMakeLists locally, as the CMake file is not uploaded AFAIK.

Also, it makes the mentoring job a lot harder. C++ has had some pretty large changes in usability and best practices from C++14 to C++20, so the solutions that they would suggest would differ depending on which version you were using, and there's not a consistent way to know the version just looking at the code.

There's lots of existing discussion from when I updated things to C++14 See #189 and #292

And to be clear I'm not saying "Don't do this". I am saying that you should probably label your version at the top of your solution file if you expect a mentor to look at it.

You are welcome to add that info to the documentation - https://github.com/exercism/cpp/tree/main/docs

[jerabaul29]

Would it be reasonable to have a small 'config' file in each project, that gets automatically uploaded at each submission, which would contains this kind of information? :)

[arcuru]

Coming back to this, in the past we've said that our minimum supported version should be the default installs on the oldest Ubuntu LTS version. If that still makes sense, we can now update the default to C++17, and updating to C++20 could be done when Ubuntu 18.04 goes out of support in April 2023.

[siebenschlaefer]

@patricksjackson Tying "our" C++ to the oldest Ubuntu LTS sounds somewhat reasonable. But in practice we've already transitioned to C++17, that's what we're using in out CMakeLists.txt files (e.g. see this one from hello-world).

[arcuru]

Oh man, I guess I've really not been paying attention. Thanks @siebenschlaefer

[willeccles]

It is worth noting that as of June 2022, the only STL to support std::format is clang 14, which disables it by default because it's incomplete still.

[mattnewport]

Recent versions of GCC now have pretty much complete support for C++20, both core language and libraries. Is there anything holding back updating to C++20 at this point? It would be nice to be able to use ranges in solutions.

[vaeng]

@siebenschlaefer @mattnewport

When I look at the table for compiler compatibility , I see a lot of overlaps with C++20 and the latest clang (12) and GCC (10.5) builds that are available on Ubuntu 20.04.

Many people are looking for std::format support, which is still incomplete in these versions, as far as I can tell.
I suggest we transfer to C++20 when LTS for Ubtunu 20.04 ends in April 2025.

[mattnewport]

@vaeng a year seems a long time to wait given that there are a number of other C++20 features available in GCC 10 that would be quite useful - ranges and span are the two that I see a lot of use for. Those would make for cleaner solutions to quite a lot of exercises, more so than format support in my opinion. There are some other niceties like contains() for associative containers, the spaceship operator, etc. but ranges are really the big one that could change how a lot of exercises can be solved for the better.

[vaeng]

@mattnewport
I'm with you about ranges and spans. I also understand the hesitation to leave an LTS behind before it's due.

Since yesterday there is Ubuntu 24.04 LTS and therefore the future compiler milestone.
I could see the argument to skip the last year with two LTS versions, but I'm very unsure about the actual version distribution with exercism users. What do you think @siebenschlaefer ?

[mattnewport]

@vaeng

Ok, I realize now that I can set CXX_STANDARD 23 in CMakeLists.txt and add it to my config.json under files -> solution and submit that and it will mostly work, barring some missing features in whatever compiler version exercism is using (ranges::fold_left() is not available for example).

This actually addresses most of what I want as it means I can submit solutions to exercises using ranges and even some C++23 features like the monadic functions on optional.

I do think ranges makes C++ much more approachable for newcomers to the language (being able to just write sort(vec) rather than sort(begin(vec), end(vec)) defers a whole lot of questions to later in the learning process) so I think there would be value in moving the defaults to C++20 and I would probably mention the simpler C++20 solutions in some mentorship discussions but being able to use most of C++23 in my own solutions is good enough for now.

[IsaacG]

Pushing new features vs not breaking things for people (stability, compatibility) is an age old balance. People who want the new feature really want the new feature. The pros of pushing are obvious to them. But the cost of breaking things for other people can be pretty high! Try to imagine if your code suddenly stopped working one morning because someone wanted to play with some shiny new thing.

[mattnewport]

@IsaacG

I don't really see the relevance of your concern here? We're not talking about anyone's code stopping working because someone wanted to use language or library features from newer versions of C++ in this context. We're not even really talking about "pushing new features" since as I discovered it is already possible to use most of C++23 in exercism solutions that will compile and pass the automated tests.

The one reasonable issue that has been raised as a concern is that mentors may be on an older LTS version of Ubuntu that doesn't package recent versions of clang or gcc and that as a result if the default settings for C++ exercises on Exercism targeted features not available on their compiler version they wouldn't be able to build / run the mentee's solution locally. That is not really the same type of problem at all.

Exercism is a language learning platform and for C++ it is valuable to support the latest versions of the language both for newcomers to the language to learn new features that simplify the use of the language in common situations (e.g. ranges) and for experienced users of the language like me who want to learn and experiment with newer language features in a safe context that doesn't raise the types of concern you are bringing up for 'production' code that may need to work in environments that don't yet support newer C++ standards.

Isn't a big focus of Exercism to give programmers a safe place to 'play with some shiny new thing'? That's why it supports a whole range of languages that most programmers won't get much opportunity to use 'in production' in their day to day work but that they want to learn out of curiosity. If I can't use C++23 yet in my day job or when contributing to open source projects because they aren't yet willing or able to require compiler versions that support it in all of their supported build configurations then where else am I supposed to learn and practice it other than in a 'safe space' like Exercism where those concerns don't apply?

[mattnewport]

Just to summarize the current situation as I understand it:

• Exercism is using GCC 12.2.1 to compile C++ solutions (this is what my logging code printed out when I ran it through the online editor, I assume this is always the case and doesn't vary based on what runner happens to pick up the submission).
• It's possible to submit a solution for an exercise that passes the tests that uses C++20 and C++23 features that are supported by GCC 12.2.1 by modifying CMakeLists.txt and config.json before submitting using exercism submit.
• GCC 12 supports almost all C++20 language features and library features and many C++23 language and library features.

The implications of this are that it is already possible for users who know about the above to ask for mentorship for exercises where their solutions use C++20 and C++23 features. This could make it difficult for mentors without convenient access to a recent version of clang, GCC or MSVC to build and run mentee's code locally but this problem already exists, though it is probably a rare scenario given the kind of user who know about and do this probably isn't in much need of mentorship for C++.

The open question then is whether to update the template CMakeLists.txt to enable C++20 by default. I still think ranges make this a potentially good idea for newcomers to C++ as it simplifies many common scenarios but I'm not sure who would be able to make that decision?

[vaeng]

The test-runner works with alpine 3.18 and runs with the respective compiler versions. On the other hand there is the github action, that checks the promised baseline of ubuntu-20.04 (which is the lowest version available for github's images).

[siebenschlaefer]

I could see the argument to skip the last year with two LTS versions, but I'm very unsure about the actual version distribution with exercism users.

I don't think we can possibly know. Personally I can use the newest Ubuntu release without any problems, I use a Vagrant image for solving and mentoring. But I don't have a clue about our students. I could imagine that some are stuck on older hardware and/or distributions because they cannot afford updating them for various reasons, they might not be able to afford it, it might be a big effort updating everything on their computer, or they might not own the computer and therefore have not the rights to update it.

I think this is a strategic decision where @iHiD or @ErikSchierboom might want to weigh in, whether it's more important to have newer features of the language available or being able to support older hardware/compilers.

---

Isn't a big focus of Exercism to give programmers a safe place to 'play with some shiny new thing'?

Is it? I'm not so sure about that. While I had lot of discussions with students and mentors about idioms and finer details I think the fundamental goal of Exercism has not changed: Teaching language fluency (being able to understand the basics of the language and being able to read code) rather than language proficiency (being able to solve real-world problems, writing at expert-level). At least I haven't heard the notion of a "safe space" for exploring brand-new features as an explicit goal of Exercism.

---

The open question then is whether to update the template CMakeLists.txt to enable C++20 by default. I still think ranges make this a potentially good idea for newcomers to C++ as it simplifies many common scenarios but I'm not sure who would be able to make that decision?

In the past that has been the decision of the maintainers of the C++ track. @arcuru is the most senior maintainer, @vaeng and me are have been more active in the last couple of months.

Personally I like the idea of sticking to an older but still supported LTS version of one of the popular Linux distributions. That should allow virtually all students and mentors to work locally. For me, not having access to std::ranges is just a small nuisance.

[ErikSchierboom]

I think this is a strategic decision where @iHiD or @ErikSchierboom might want to weigh in, whether it's more important to have newer features of the language available or being able to support older hardware/compilers.

We don't have a definitive take on this, but in general tracks usually try to stay quite up to date. But, the situation for C++ is relatively unique in that there is such a wide variety of "stable" versions. There's the Ubuntu LTS as you mentioned, but also other distros and then there's GCC vs Clang.

I'm not very well known with the C++ ecosystem, but could users on older versions of their distros manually install a newer version of C++?

[arcuru]

(I noticed the ping here so I will chime in with my very old context. It's mentioned above that I'm the most 'senior' maintainer but I have not been active for quite a while (years) and @siebenschlaefer has more recent context and experience as a Mentor.)

My comments above from many years ago were largely made before Exercism supported an online editor/tester, and the main way of testing and running was local. With the online editor, we can tell students 'hey you have a very old version, and for development you really need to be running a more recent distro. if you can't do that just use the website'. Does the mentor flow work in the online editor?

I always liked the fact that Exercism worked largely locally, but if anyone is stuck on an old distro we can always point them to the online editor. There are just a lot more options nowadays to run things.

I'll also say, I never saw an example of "What if a mentor doesn't have access to a new version locally?". If Mentors ever chimed in on this sort of issue, it was always with an understanding that other people might be effected. Mentors, as you can see above with @siebenschlaefer running things in a Vagrant container, are mostly able to solve the out of date problem themselves. And the student problem already seems solved with the online editor.