Moving to C++20

[barbara]

We would like to ask our CopperSpice users for feedback about moving from C++17 to C++20. This is a change we are going to make at some point, the question is simply when.

CopperSpice Team

[seasoned_geek]

Not a good idea.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html

Looking at the changes found there I humbly suggest you skip 20 and wait for the next release where the C++ standard will once again undue bad decisions made in the previous release.

I haven't gone through everything because no client has even considered moving to 20 (only a token few have moved to 17, none have moved to 14, most are still wanting only 11 for new code) Just off the top these are real problems.

P1236R1 will be completely unusable in the embedded systems world where devices one communicates with via DMA or some other non-messaging means require signed integers of different format. Let us not forget that UNISYS is 1's complement hardware and what the IRS uses to process taxes in America. IBM z/OS hardware uses 2's complement but UNISYS edged them out with math throughput so the IRS went with them. Anyone who has to exchange binary data (written a few e-file and tax systems myself back in the day) has to handle integers in 1's complement.

P0806R2 is definitely going to bust oceans of code. That singular change will stop 20 from ever getting adopted in many shops. The cost of fixing the code base is far too high for zero return.

P0966R1 Another one which will break a lot of code and where the cost of updating code base will be too high for zero gain.

Embedded systems where human and in many cases animal life is at risk must compile without warning and turning any warning off is a huge amount of paperwork and sign-offs.

Let us not forget that IBM has very deep pockets so the trigraphs battle really isn't over.

Here's a question:

Is any compiler on the market 100% compliant with 20? Last I heard was no.

[janwilmans]

Our company is on C++23 or whatever part of that GCC 13.1 supports and I see more and more companies in the Eindhoven area moving to C++20, so I would say, go for it. I think we can open up a lot of new constexpr, concepts and ranges opportunities.

[ansel]

Just looking at GCC, they started adding C++20 features back in version 8 and more was added with each release. The majority of features are present in GCC 12, except for a few things related to modules. Support for C++23 started to appear in GCC 9 with the majority appearing by GCC 13.

(1) As of C++20 the standard defines arithmetic will use two's complement in integer calculations. This was not a change in C++ but rather documenting what was already being done internally. Keep in mind, there is nothing preventing you from using one’s complement or sign magnitude in your code base.

(2) In a C++11 lambda expression could capture THIS by using [=]. In C++20 they deprecated “implicit capture of THIS”. If you use [=] in a lambda and THIS is captured, a warning is emitted not a compile error. If your code needs to capture THIS simply modify the capture from [=] to [=, this] and the deprecated warning will be gone.

From a library designer perspective, it is not good for us to jump directly from C++17 to C++23. Our key motivation for moving to C++20 is concepts / requires clause, spaceship operator, char8_t, and consteval. It is our belief that moving to C++20 will allow us to improve and optimize the internals in the Core library.

[seasoned_geek]

(1) As of C++20 the standard defines arithmetic will use two's complement in integer calculations. This was not a change in C++ but rather documenting what was already being done internally. Keep in mind, there is nothing preventing you from using one’s complement or sign magnitude in your code base.

(2) In a C++11 lambda expression could capture THIS by using [=]. In C++20 they deprecated “implicit capture of THIS”. If you use [=] in a lambda and THIS is captured, a warning is emitted not a compile error. If your code needs to capture THIS simply modify the capture from [=] to [=, this] and the deprecated warning will be gone.

(1) was only being done internally on x86 derived platforms. It was not done internally on hardware that natively uses 1's complement. This change breaks platform support and will eventually be undone.

(2) What you say is somewhat true, but in standards committee fashion it completely ignores the galactic sized pile of code that would have to be modified, inflicting immense probability of error for absolutely no gain. The size of the C++11 codebase out in the field means this can't happen. Yes, some small companies that have only been around for a few years with a limited code base or those who correctly banned all use of lambda from the get-go will be able to move. The rest will not go forward. Mandating C++20 as the minimal compiler for your library means it won't even be considered.

[barbara]

(1) was only being done internally on x86 derived platforms. It was not done internally on hardware that natively uses 1's complement. This change breaks platform support and will eventually be undone.

We understand your concerns about this issue and thank you for bringing them up. We talked with someone who is very involved in the embedded world and the C++ standard. He reminded us, embedded hardware which uses 1's complement is not the target for modern C++. He also made a very good point that these platforms are too small to utilize CopperSpice.

He is really happy that we can build CS for Raspberry PI and impressed we did this as a cross platform from Debian. But he also teased us that very few of his embedded systems are "as big as a Raspberry PI".

We respect that you have clients who feel let down by recent changes in C++20. There is very little if any chance that C++26 or later versions will make any modifications in this area.

Barbara

[seasoned_geek]

just so this conversation is properly scoped.

Those ones complement systems feed binary data to larger systems, generally across a bus, to a larger system which is running a full OS and the receiver needs native ones complement support.

Please not that Unisys mainframes, used by the IRS in America to process every income tax return ever filed are ones complement machines. They have been migrating some code to C++ as part of their modernization effort. (Java migration failed spectacularly.) They (and quite a few other organizations) are on the Unisys machines because the twos complement hardware tested could not achieve the required throughput.

This is an obvious case where academics operated in a vacuum. Deep pockets and government regulations will step in. I'm not directly involved with the "modernization" effort. I just read and hear stuff from people who are. Attempting to migrate to commodity hardware using thousands of servers in a "cloud" failed. When it was tested with old returns people did the math and found out it was going to take something like more than two years to process a single year's taxes. They have been bringing in C/C++ people re-writing big chunks of the system because there are so few of us left who know COBOL.

There are publicly available magazines which focus on various IT systems for various government agencies (all above board, not hacker stuff) if you care to do research on the topic. I just know that whoever made this decision has only worked on x86 and its imitators. There is no way the government of the United States is going to let a "language standard change" hamstring the IRS. Every so many months (quarterly?) the IRS has to appear before the committee/sub-committee overseeing the modernization effort. When they point this out it will not be shrugged off.

Every x86 system which is allowed to reach into the databases created at the IRS must also support ones complement or they have to go through a messaging system using incredibly slow translation to XML.

At any rate, I've said my peace. Migrating to 20 would be ill-advised.

[ansel]

Thank you for contributing to this conversation and explaining your point of view. We really do appreciate user input. We are going to chat with a few other C++ committee members before making a decision about when to implement the transition to a newer version of C++.