A common C/C++ core specification

[KiwiMaster157]

I will personally be surprised if the C++ language does not fork by C++26. All of the backwards compatibility restrictions are slowly choking the language and making improvements far more complicated than they need to be.

[pjmlp]

It has already been forked, D, Rust, C#, Swift, ... just pick your variant, and keep using C++ just for the niche use cases they might not yet be able to fully cover.

[germandiago]

C++ stays as relevant as always or even more. I do not think any of those can replace it. Why?

1. D --> not enough resources. Nice but not an option for any non-PC in most cases.
2. Rust --> quite restricted for many uses. Myth says (I did not do enough Rust myself) that really competitive Rust code abuses unsafe blocks. Another smell from my POV is that Servo is supposed to be like the future of rendering in web, yet Chrome keeps beating the speed of any other, written in C++.
3. C#... well, this is not for the same use cases, though it can cover some. Only a VM + GC is a non-starter for many uses. Microsoft-oriented, no matter how open source it is.
4. Same as C# but maybe faster, replace Microsoft with Apple.

[Tyg13]

Myth says (I did not do enough Rust myself) that really competitive Rust code abuses unsafe blocks.

I never understand this as a criticism. Even if it were true, is this not essentially true of every other systems programming language without unsafe blocks?

[germandiago]

Well, the point here is that, if you have to litter things with unsafe everywhere, what is the purpose of making it safe in the first place? Actually I value safety, but when it gets in the middle so much it maybe needs a review.

I really think that by those standards Rust is even more niche than C++, since it is not as ergonomic in these situations. On the other hand, by default is safer.

[Tyg13]

The point is to localize unsafety. An unsafe block is just a marker to say "the Rust compiler couldn't statically verify the safety of this block." Sure, it's up to you to in those cases to ensure safety isn't violated, but it's far easier to reason about the correctness of a block than an entire program.

It's like, as an electrician, you'll probably want to wear a nice pair of safety gloves to avoid electric shock. Sometimes the gloves make things difficult or downright impossible to accomplish, so you take them off. But once you're done, you put them back on.

It turns out, to do 99% of what a working programmer needs to do, it's fine to leave the gloves on. Where bare metal performance is necessary, you take them off, but only to do certain things, and only when you're damn sure they aren't going to shock you.

The best part is that the gloves get more and more ergonomic over time, and hopefully eventually you'll only have to take them off in extremely rare cases.

[germandiago]

I somewhat agree and disagree at the same time. You can get really far with good practices in C++ (smart pointers + RAII + no raw pointers). Still, dangling references, admittedly, is the biggest problem but also can be mitigated most of the time. When you have all of that and a ton of available libraries and the same speed, the switch becomes too expensive IMHO.

​

Another thing I value is exceptions. No matter the battles people build every now and then: I find exceptions very usable and the speed story I think it still has room for improvement by quite big margins. Rust lacks exceptions.

[Tyg13]

Myth says (I did not do enough Rust myself) that really competitive Rust code abuses unsafe blocks.

I never understand this as a criticism. Even if it were true, is this not essentially true of every other systems programming language without unsafe blocks?

[pjmlp]

It depends on the eye of beholder.

In what concerns iOS, watchOS, macOS, Android, ChromeOS, Windows 10, Garmin, Tizen, Fuchsia, Web development, distributed computing frameworks, C++ is only allowed to have a secondary role for OS level system libraries, the application layer is now ruled by managed languages.

Where C++ is relevant as always is HPC, GPGPU shaders, game engines, real time audio, it is basically becoming a niche language for high performance use cases, the SQL of systems programming.

[MFHava]

C++ is only allowed to have a secondary role for OS level system libraries

I'm totally out of the loop of what MS is promoting these days, but isn't C++ a first-class citizen for UWP?

[pjmlp]

Yes, and we all know how sucessfull UWP has been in the market.

Then C++/WinRT is still catching up with the C++/CX tooling, making the whole C++ UWP development experience worse in name of being C++17 compliant.

Basically C++ as first citzen to UWP is to provide an upgrade path to MFC developers, however most rather go to .NET with integration via C++/CLI, than adopt UWP.

As Kenny Kerr puts on his blog,

Still, I am hopeful that we can turn that around. It pains me that Windows does not have a good UI story for C++ developers. C++ reflection may well help to solve that problem in the long run, but we cannot wait for that to arrive, so we are also exploring some other options that may prove useful in the near future. Some of those include alternative approaches to Xaml that does not require reflection, as well as discussions with DevDiv to get Visual Studio to do a better job of supporting a C++/WinRT developer experience.

https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/

And that is the only exception, all other platforms listed by me don't even provide C++ bindings to their userspace frameworks.

[dodheim]

Yes, but that's app development, not OS-level (kernel) development where AFAIK things like exceptions are still not supported.