Oh, my!

[George P]

Now at least one person is talking about proposed C+++26 features:

https://www.cppstories.com/2024/constexpr-number-parsing-cpp23/

I'm still wrapping my brain around C++20 features, C++23 is in the queue a bit later this year.

[salem c]

<rant></rant>
Why is the C++ committee in such a rush?

What's the point of using the latest toys in the box if half of them are going to be either revised or deprecated within a decade.
https://mariusbancila.ro/blog/2018/07/05/c17-removed-and-deprecated-features/
It's a worryingly long list (for just one revision), and the author throws in a "not complete" for good measure.
I wonder if anyone on the C++ committee even knows what the half-life of any given C++ feature is.

How many concurrent versions of C++ can a compiler support?

If you're trying to maintain a long term project, what do you do?
- every 3 years, pick through the new deprecated list, fixing and retesting your code in an effort to stay current.
- do nothing to the code, hope that your current compiler keeps supporting -std=c++xy, and doesn't introduce regression bugs trying to keep up with the C++ committee.

[mbozzi]

I never used to think backwards compatibility was such a big deal (to me, at least), but recently I have realized that it's giving me the ability to cherry-pick the decent parts from recent C++'s undisciplined, random mishmash of language features.

I really wish the committee would listen to Stroustrup.

[keskiverto]

backwards compatibility

I don't use Python, but occasionally have to get some of those applications into use. As non-recent C++ user the experience has always been harrowing. (Although one exception supports "any version of Python between 2.3 and 3.12" -- and has some Python included in case your system has none. Now that is "compatible".)

Mere thought of lack of compatibility (in C++) gives an eerie feeling.

[seeplus]

I've previously suggested a tik-tok cycle (similar to Intel) in that the 'major' features are only introduced in a 'tik' cycle with only minor/DR changes in the tok cycle. I'd suggest a 2-year cycle so that major features/depreciations only happen every 4 years but small 'clean-up's can be every 2 years.

But from what I've come across the C++ committee (Herb, I'm looking at you here) are wedded to their 3 year cycle come what may. They won't even defer the final C++23 standard for a short while to incorporate the known DR's. So C++23 is released with known issues and C++26 starts with half-dozen DRs relating to C++23!
AAAAAAAAhhhhhhhhhhhh.............

[George P]

How many concurrent versions of C++ can a compiler support?

I can only speak of what MSVC on the surface appears to do using the VS IDE. When starting a new project the C++ version defaults to C++14 with later versions selectable later in the IDE. C++17, C++20 and C++ latest which includes so far what MS has implemented for C++23. It wasn't that long ago C++20 wasn't a separate entry, it was lumped into C++ latest.

I don't know if C++11 or earlier is even available as a command-line option when compiling outside the IDE, GCC theoretically does allow it via switches.

This 3 year cycle with profound changes happening is making it harder and harder to learn and use wisely the new features. If each 2-3 cycles were mostly additions to the language with fixes as the rest with the 4th being the "we're gonna change everything" as the committee is doing now every time would be fine. Just when someone gets used to the new way of doing things along comes the newest standard that changes all the rules in the quixotic quest to make writing code easier.

A couple of the additions in C++20 and C++23 I really like. std::format and std::print/println for example.

Modules I am still rather ambivalent about, I understand the need to replace headers but the implementation in MSVC doesn't exactly line up with faster compiles with modules in my admittedly limited hobbyist programmer experience.

[SubZeroWins]

Do you think it is ever possible for them to cherry pick or vote pick the best of C++, with no overlaps to avoid confusion, & make a Super C++? Perhaps drop C compatibility altogether?

Can you make a C++ that is more Java or Python like in simplicity & ease of usage or will that inherently make C++ more sluggish?

MyClass::MyStaticFunction.MyVariable;

just becomes
MyClass.MyVariable;

[George P]

The C++ ISO Committee has deprecated and removed a few earlier C++ features, but even in C++23 code it is possible to use older version features. That is the beauty of (mostly) being backwards compatible.

You don't need to consume modules, you can still include headers, etc. The C++ toolbox is quite extensive, most programs use but a fraction of what's available.

[Peter87]

SubZeroWins wrote:

Do you think it is ever possible for them to cherry pick or vote pick the best of C++, with no overlaps to avoid confusion, & make a Super C++? Perhaps drop C compatibility altogether?

Better make it a new language instead of destroying the C++ that we already have.

SubZeroWins wrote:

Can you make a C++ that is more Java or Python like in simplicity & ease of usage or will that inherently make C++ more sluggish?

Of course you can but it wouldn't be C++.

I think one reason why Java is so much simpler is because it uses value semantics for primitive types while class objects are always handled through "references". This avoids the need to have special pointer/reference syntax. You don't need to think about implementing copy constructors, copy assignment operators (and the move version of these). Thanks to the garbage collector you can essentially ignore all object lifetime issues.

It also have consequences. It's not possible to store a class object efficiently directly inside another object or on the stack like in C++. It's not possible to create class wrapper objects with essentially zero runtime overhead compared to primitive types like in C++. And so on.

Java and C++ make different trade-offs and I think there is a place for both these kind of languages. Sure, C++ could have been simpler but I don't think it could ever have been as simple as Java.

[George P]

Better make it a new language instead of destroying the C++ that we already have.

It can be argued C++ is already enough of a Frankenstein's monster creation that deserves being redone as a new language. That's what we get when a committee does the ongoing design.

C++11 was enough of a watershed change it should be considered a new language from what came before. C++20 is almost as much of a paradigm shift with importing modules vs. including headers.

The ISO committee has deprecated and removed some features such as std::auto_ptr and std::random_shuffle before , but some serious pruning still needs to take place IMO.

Too many people still rely on the C random number generation functions when C++ has the capability.

https://web.archive.org/web/20180123103235/http://cpp.indi.frih.net/blog/2014/12/the-bell-has-tolled-for-rand/

Is the C++ <random> library perfect? Absolutely not, there are other means available 3rd party.

C++ isn't sluggish, it is compiled to direct machine code. Java and Python require a VM layer to run the translated byte-code.

C++ apps, at least on Windows, has a C Runtime Library that gets started when running a C++ compiled app. The number of support libraries needed goes up if you use GCC or other non-Visual Studio compilers.

Or you can statically link the library code but that bloats up the app size.

The hoo-man readable source code is another argument altogether. C++ doesn't hold the programmer's hand as much as Java or Python do IMO. There are coding and performance considerations that need to be evaluated when choosing what language to use.

C++ could have been simpler but I don't think it could ever have been as simple as Java.

Ain't that the truth!

[George P]

drop C compatibility altogether?

No, there are features the C library has that the C++ stdlib doesn't. With each new language version that becomes less and less true.

Deprecate at the minimum any C library feature C++ already has, while considering removing them altogether.

There are legacy code considerations for retaining the C library, but new C++ code shouldn't use it if at all possible.

The cost of updating legacy code to a newer standard can be enormous in time and money.

[Peter87]

George P wrote:

It can be argued C++ is already enough of a Frankenstein's monster creation that deserves being redone as a new language...

There is a big difference between adding new things and breaking existing code. If we can't be relatively confident that our code will continue to work even in the future then what's the point of having a standard?

C++11 made quite a few breaking changes (and learned from it). C++20 made almost none (I'm not counting incompatible changes to relatively new features that was added recently). You can still use header includes in C++20.

I have never used std::auto_ptr but it seemed pretty broken. Removing std::random_shuffle was much more controversial in my opinion.

Note that these removed names usually gets added to the list of "zombie names" so implementations can still support them if they want. https://eel.is/c++draft/zombie.names

[Peter87]

George P wrote:

Deprecate at the minimum any C library feature C++ already has, while considering removing them altogether.

I don't think that's the direction it's going in.

Up until C++23 the "C headers" (the ones ending with .h) were listed under Annex D which contains deprecated features. In C++23 they were moved to another part of the standard and are no longer described as deprecated. For motivation you might want to read the proposal paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2340r1.html

C++23 also added stdatomic.h for compatibility with _Atomic and stdatomic.h in C even though C++ already have std::atomic. Proposal paper with motivation is here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0943r6.html

[George P]

I don't think that's the direction it's going in.

I know being reasonable about trimming the unwieldy mess that is C++ ain't gonna happen. I was just spit-ballin'.