C++20 Is Still Settling While LLVM Clang Already Adds Option For Starting C++2b/C++23

[phoronix]

Phoronix: C++20 Is Still Settling While LLVM Clang Already Adds Option For Starting C++2b/C++23

It was just in September that the C++20 standards draft was approved as a major update to the programming language over C++17. While compilers like GCC and LLVM Clang are still completing all of the changes for C++20 support, Clang is already moving ahead and has added support for the "-std=c++2b" option as it begins the endeavor of staging changes likely for C++23...

http://www.phoronix.com/scan.php?page=news_item&px=LLVM-Clang-Option-CPP2b

[kaprikawn]

I've been watching Jonathon Blow's Jai streams and videos and have drunk the kool aid. So now I view additions to the C++ spec with contempt as they add more needless crap to an already bloated language. I wish them well, but I think I'll be ditching C++ as soon as Jai is opened up to general users.

[dev_null]

what c++ is really lacks is compile time reflection. For some reason it cannot be added for decades.

[uid313]

Rust vs C vs C++?
Or is it Rust vs C, and C++ vs Java? Or is it Rust vs C++?

C seems simple, there is not much to it, but it has no safety, and it is very easy to shoot yourself in the foot.
C++, I've learned that it has some cool stuff like std::Enum, std::Option and smart pointers. I cannot understand C++ though.
Rust, I really like Rust, the strong type safety and strict compiler assures you of reliability and robustness.

One thing to know about Rust though is the standard library is very small, doesn't have any random function, and doesn't have any async functions. It has files and networks, for other stuff you need crates. One thing I don't like about Rust is you can't have async functions in traits, but I've been told it is possible with a third-party crate. Another thing I don't like about Rust is that crates (which are Rust's name for libraries) that provides async functions depends on a specific async runtime of which there are many, so it creates of clusters of libraries which are of isolated islands, like this library is depending on the async-std libray, and the other library is depending on the Tokio library, etc.

[Zan Lynx]

I've been watching Jonathon Blow's Jai streams and videos and have drunk the kool aid. So now I view additions to the C++ spec with contempt as they add more needless crap to an already bloated language. I wish them well, but I think I'll be ditching C++ as soon as Jai is opened up to general users.

C++ is adding things to the standards which have existed in outside libraries for 20 years and more. Obviously networking and asynchronous functions and many other features already existed. Adding them to the standard just makes them official and chooses one as "the best."

Even reflection isn't really new. It has existed for years as modifications to GCC and Clang to output XML files describing the C++ code. There's been Python scripts to parse C++ code and build IDL from it. I know. I wrote one that was pretty simple, not open source, but worked on our code at the time.

So, what if you switch from C++ to some new language? Well, you lose all of the backward compatibility which makes changes to C++ a bit clumsy: you've got fresh new syntax all shiny. Until you need to add things to it later. You also lose access to all those C++ libraries that already exist. Take Rust for example. It has a lot of momentum and enthusiasm and has for years. It's still working on building up a library environment equal to C or C++, and even then a lot of that is simple wrappers around the existing C libraries.

[carewolf]

what c++ is really lacks is compile time reflection. For some reason it cannot be added for decades.

That is one of the goals of C++23

[Michael_S]

C++ is adding things to the standards which have existed in outside libraries for 20 years and more. Obviously networking and asynchronous functions and many other features already existed. Adding them to the standard just makes them official and chooses one as "the best."

Even reflection isn't really new. It has existed for years as modifications to GCC and Clang to output XML files describing the C++ code. There's been Python scripts to parse C++ code and build IDL from it. I know. I wrote one that was pretty simple, not open source, but worked on our code at the time.

So, what if you switch from C++ to some new language? Well, you lose all of the backward compatibility which makes changes to C++ a bit clumsy: you've got fresh new syntax all shiny. Until you need to add things to it later. You also lose access to all those C++ libraries that already exist. Take Rust for example. It has a lot of momentum and enthusiasm and has for years. It's still working on building up a library environment equal to C or C++, and even then a lot of that is simple wrappers around the existing C libraries.

As someone that doesn't especially like C++...

1. There are the languages people complain about, and the languages nobody uses.

2. There are, without exaggeration, billions of lines of C++ in use. I don't care how cool the replacement is, we're decades away from leaving C++ behind.

3. If people - including me - that liked to dump on C++ spent a third of our bashing time actually rewriting C++ applications in other languages, nobody would have these discussions. That should be an internet rule: "Most internet programming language debates and flame wars consume more resources than it would take to rewrite all known software in any of the languages under discussion."

[programmerjake]

Rust vs C vs C++?
Or is it Rust vs C, and C++ vs Java? Or is it Rust vs C++?

C seems simple, there is not much to it, but it has no safety, and it is very easy to shoot yourself in the foot.
C++, I've learned that it has some cool stuff like std::Enum, std::Option and smart pointers. I cannot understand C++ though.

Did you mean std::variant and std::optional?

Rust, I really like Rust, the strong type safety and strict compiler assures you of reliability and robustness.

One thing to know about Rust though is the standard library is very small, doesn't have any random function, and doesn't have any async functions. It has files and networks, for other stuff you need crates. One thing I don't like about Rust is you can't have async functions in traits, but I've been told it is possible with a third-party crate. Another thing I don't like about Rust is that crates (which are Rust's name for libraries) that provides async functions depends on a specific async runtime of which there are many, so it creates of clusters of libraries which are of isolated islands, like this library is depending on the async-std libray, and the other library is depending on the Tokio library, etc.

The Rust standard library has a few async functions, but, yeah, mostly you need a separate crate for async stuff.
One nice part is that, unlike C/C++, it's extremely easy to use external libraries (for 99.9% of cases, just 1 line of code and it just works), so Rust often depends on de-facto standard crates such as serde, syn, quote, num, futures, etc.
The issue with async ecosystems is that Rust has taken the approach that the standard library provides common code but they're waiting to see what de-facto standard is settled on, since they want to avoid picking some library to include in the standard library only to discover that the chosen API was a mistake and they have to maintain a fundamentally broken library forever (like C++ did with std::ostrstream).

[kaprikawn]

...So, what if you switch from C++ to some new language? Well, you lose all of the backward compatibility which makes changes to C++ a bit clumsy: you've got fresh new syntax all shiny. Until you need to add things to it later. You also lose access to all those C++ libraries that already exist. Take Rust for example. It has a lot of momentum and enthusiasm and has for years. It's still working on building up a library environment equal to C or C++, and even then a lot of that is simple wrappers around the existing C libraries.

Where you see backwards compatibility, I see legacy cruft. The syntax change doesn't bother me too. The syntax of C++ isn't great, when code looks like

std::vector<std::pair<unsigned int, glm::vec4>> myMeshOrWhatever;

it makes my eyes bleed. This might be a contrived example that I haven't thought about too much, but I definitely have code like this.

And Jai has all the libraries I need, It can access C libraries like SDL2 and OpenGL (which I'm currently using) just fine.

In return I'll get to ditch CMake, be able to trivially dev cross platform, and no longer have to write header files.

[uid313]

Did you mean std::variant and std::optional?

Yes, I do believe so.

The Rust standard library has a few async functions, but, yeah, mostly you need a separate crate for async stuff.
One nice part is that, unlike C/C++, it's extremely easy to use external libraries (for 99.9% of cases, just 1 line of code and it just works), so Rust often depends on de-facto standard crates such as serde, syn, quote, num, futures, etc.
The issue with async ecosystems is that Rust has taken the approach that the standard library provides common code but they're waiting to see what de-facto standard is settled on, since they want to avoid picking some library to include in the standard library only to discover that the chosen API was a mistake and they have to maintain a fundamentally broken library forever (like C++ did with std::ostrstream).

Oh, I am new to Rust, but I am not aware of any async functions in the standard library.
Yes, Cargo (the package manager) is quite nice.

Yeah, I don't like that packages are dependent on specific runtimes, because like if I pick a package, then I am stuck on that island, or if I write a package, then I have to target a specific island. It would be very nice if all the async crates just worked everywhere.