C++20 Being Wrapped Up, C++23 In Planning

[CommunityMember]

Does Bjarne still recognizes his language?

One of his famous quotes is "Within C++, there is a much smaller and clearer language struggling to get out."

Just like code written in Fortran 2018 might be unrecognizable to those taught Fortran IV, C++ has evolved over the decades in ways that were strongly influenced by changes in real world requirements and hardware capabilities and some of the newer additions would probably surprise someone who has not continued their involvement. But last I knew Bjarne was still active in the C++ standards process, so he would recognize what the language has become (and has authored a number of papers for the committee to reflect his views in recent memory).

[hoohoo]

One of his famous quotes is "Within C++, there is a much smaller and clearer language struggling to get out."

Just like code written in Fortran 2018 might be unrecognizable to those taught Fortran IV, C++ has evolved over the decades in ways that were strongly influenced by changes in real world requirements and hardware capabilities and some of the newer additions would probably surprise someone who has not continued their involvement. But last I knew Bjarne was still active in the C++ standards process, so he would recognize what the language has become (and has authored a number of papers for the committee to reflect his views in recent memory).

A lot of what I've read in the reddit that Michael linked to is nitty gritty stuff that would be of concern to library writers or specialists, or what might be called making the language easier to use, and that is all fine.

OTOH there is some tendency toward abstracting the hardware away via the C++ spec, and I question the value of that. The greater part of C++' success was that it did not mandate how one writes software, merely enables better software if one understands how to exploit OO and templates. The tendency of the committee to accept ever more stuff into the library from outside the language (threads, networking models come to mind) risks isolating the language from change.

How many Java programmers actually write new software rather that trawling thru the mountains of Java library classes to find the exact predefined thing that they need? Is that programming or Lego?

What if some brilliant hardware architect comes up with a better thread paradigm - will it be ignored because "C++ does not support it"?

Or perhaps we'll have the C++ std::ethernet library, and to hell with Infiniband or any other better network technology.

I'm a working programmer: I see a lot of other programmers who don't want to use anything that isn't in the std library, or maybe in Boost. This is a narrowing of perspectives, it bodes ill for the future. If C++ is a language and not an entire codified ecosystem it will have a broader future.

I think this tendency is not so much a result of "...changes in real world requirements and hardware capabilities..." but actually a response to many of the people involved having been spoon fed scripted or interpreted languages at university.

[hoohoo]

Every language is a tool, and each tool is suited for different jobs. Pointers are fine for those projects who need that kind of fine tuning and lower level access, but as the software ecosystem progresses there is a need for more and more higher level languages in order to facilitate faster software creation and bigger projects without tons of bugs.

In my honest professional opinion, C++ is a joke, it has always been a joke, and will continue being a joke in the future. Especially these days, it serves almost no need, yet it still holds a considerable position in the market due to momentum and its established base. If you need system programming, use C, if you need proper object based programming, use Java, C#, Python, whatever. C++ is that middle of the road stillborn, it is just C with some object-oriented features but it is not a genuine object oriented language. They keep trying to turn it into one, but they are making things worse year by year. Why not just let it be and create a brand new language (or even better, just use one of the existing ones)?

I don't get it, seriously. I can understand the original love for c++ a few decades ago but when oop was new and languages that supported it weren't widespread, but i can't understand why people keep bothering with it. Probably because they are just lazy and don't want to learn new stuff and re-write libraries/game engines/frameworks/etc etc. The typical programmer curse.

C++ is not "...just C with some object-oriented features..." - it is C with some object-oriented features AND TEMPLATES! Seriously the most powerful thing that C++ brought to programming was not OO, it was templates.

New language or use one of the existing one...
- if you want your programs compiled to machine code not byte code then you have two existing ones: C++ and C.
- you're still going to have to hang a C interface on the side of whatever your new language is to let it interface with C at a minimum: all the OS's are written in C and so are their APIs. Ask MS about this: why C++ is back in favour and C# isn't the panacea anymore... they couldn't rewrite Windows in C# and they couldn't rewrite all the APIs in C#, so eventually they had to offer a real interface to the OS and that is C or C++.

But yeah, it might be time to start a new language and leave C++ where it is (which is close to perfection IMHO). They could call the new language KitchenSink++.

I'll answer you questions with some more:
- what if I want to write system level code in a template or OO manner?
- what if I want to write template or OO code without having to deal with Java's obfuscations and weird library philosophy?
- what if I want to write template or OO code and not have to deal with any library design philosophy other than my own?
- what if I want to write template or OO code and want to just use the naked C APIs for threading, networking, IPC and the like?
- what if I want to write template or OO code but not on Windows? Uh oh, no C#.
- what if I want to write templated code using real compile-time template expansions - not Java's half baked run-time scheme?
- what if I want the program to be fast!!!? Let's skip Java and Python.
- what if I want to or need to explicitly manage memory? Let's skip Java and Python.
- and darn right, what if I don't want to learn Rust or D or whatever the flavour of the month is when I have a perfectly good language already (C++)?

[kpedersen]

OTOH there is some tendency toward abstracting the hardware away via the C++ spec, and I question the value of that. The greater part of C++' success was that it did not mandate how one writes software, merely enables better software if one understands how to exploit OO and templates.

I agree. In fact this power of C++ probably comes from the fact it is one of the very few languages based on C (With Objective-C being another and will ultimately outlive Swift because of this C-heritage).
This access to C is crucial so you do not need to spend your project budget writing bindings or maintaining those written by others (bindings are also usually very poorly maintained and out of date).
Too many languages these days fall back to the silly fat bloated VM approach, such as .NET, JVM. This old fashioned architecture stems all the way back to Alef / Limbo from Plan 9.

I am however a little bit worried about the direction of the language as a whole. The standards committee do not seem concerned enough about safety (smart pointers only go so far).
I also feel that bad engineers will misuse the newer asynchronous features of the language and turn everything into a callback nightmare. I saw this recently whilst looking through popular websocket libraries for C++. In the end I wrote my own because most of the other offerings were poorly designed or dragged in boost.
Finally the addition of modules has the potential of turning C++ into a dependency obsessed language where you cannot even wipe your own butt without dragging in 10 dependencies (i.e such as with NPM, PIP, etc).

[TemplarGR]

C++ is not "...just C with some object-oriented features..." - it is C with some object-oriented features AND TEMPLATES! Seriously the most powerful thing that C++ brought to programming was not OO, it was templates.

New language or use one of the existing one...
- if you want your programs compiled to machine code not byte code then you have two existing ones: C++ and C.
- you're still going to have to hang a C interface on the side of whatever your new language is to let it interface with C at a minimum: all the OS's are written in C and so are their APIs. Ask MS about this: why C++ is back in favour and C# isn't the panacea anymore... they couldn't rewrite Windows in C# and they couldn't rewrite all the APIs in C#, so eventually they had to offer a real interface to the OS and that is C or C++.

But yeah, it might be time to start a new language and leave C++ where it is (which is close to perfection IMHO). They could call the new language KitchenSink++.

I'll answer you questions with some more:
- what if I want to write system level code in a template or OO manner?
- what if I want to write template or OO code without having to deal with Java's obfuscations and weird library philosophy?
- what if I want to write template or OO code and not have to deal with any library design philosophy other than my own?
- what if I want to write template or OO code and want to just use the naked C APIs for threading, networking, IPC and the like?
- what if I want to write template or OO code but not on Windows? Uh oh, no C#.
- what if I want to write templated code using real compile-time template expansions - not Java's half baked run-time scheme?
- what if I want the program to be fast!!!? Let's skip Java and Python.
- what if I want to or need to explicitly manage memory? Let's skip Java and Python.
- and darn right, what if I don't want to learn Rust or D or whatever the flavour of the month is when I have a perfectly good language already (C++)?

Tons of bs and misinfo... First of all even Java code can be compiled to machine code. Actually, almost everything can be compiled to machine code these days. To claim that only c++ and c get compiled to machine code these days means you are an ignorant fool and one can disregard everything you say.

Secondly, machine code is not a panacea. Machine code does not mean "faster" and does not mean "better". Only a retarded student could claim this. Try coding professionally for a few years and then we'll talk. I won't waste time educating you.

[Weasel]

Machine code does not mean "faster" and does not mean "better".

It does though, unless you're the retard who doesn't use maximum optimizations when compiling a release build.

Only a retarded student could claim this. Try coding professionally for a few years and then we'll talk. I won't waste time educating you.

Says the retard who probably got a low end job writing some Java crap, since the barrier of entry is too low and they always allow retards in.

Maybe you should try coding C/C++ professionally for a few years first before spouting such gibberish. But you probably can't, that's why you're so butthurt, since they require actual expertise. So you're trying to justify your pathetic Java career by downplaying the real men languages to make you feel good about yourself.

[ssokolow]

It does though, unless you're the retard who doesn't use maximum optimizations when compiling a release build.

A good JIT will beat an AOT compiler with crappy optimization passes any time of the week. (Or, for that matter, an AOT-compiled language which has to do so much dynamism and indirection that it's locked into doing dynamic lookup on every variable access or method dispatch.)

Being compiled to machine code doesn't magically preclude a language from making every variable into a Visual Basic VARIANT type, for example... it just makes the stupidity of doing so more obvious.

Hell, if I'm reading the Benchmarks Game results correctly, it has JIT-compiled C# beating native-compiled Go.

[kpedersen]

Hell, if I'm reading the Benchmarks Game results correctly, it has JIT-compiled C# beating native-compiled Go.

Not really arguing (since C++/CLR on .NET is actually pretty good and C++/Emscripten on WebAssembly is also fantastic)...

but you have to ask yourself why Unity spent many man hours writing a .NET to C++ transpiler if managed code is so great.

It is probably one of those things where in theory JIT can be faster but in practice (or rather, the way developers use it), it simply isn't and won't be for the foreseeable future.

[DavidBrown]

If it isn't already fixed, any chance they will add better overflow handling for signed numeric variables?
I read something about unsigned (something numeric, can't remember if it's int or float) having wrap-around overflow specified but not the signed variant of that.
And while they mentioned it wasn't clear how to do this due to the representation (1-complement, 2-complement, etc).
Didn't they already specify the complement system and other details of signed int/float/other numeric in other operations or parts of the standard?
Including, if I'm not mistaken, 2-complement? Which would allow specifying how the value of the signed variable should be calculated.

Any chance that could be fixed for the C++23 standard if not already fixed in C++20?

Unsigned integer arithmetic has always been defined as wrapping in C and C++. Signed integer arithmetic has always had undefined overflow behaviour. This has been consistent since C before C was standardised some 30 years ago. And misunderstandings about why signed integer overflows are undefined have existed for about as long. In particular, it is not about support for odd hardware architectures that don't support two's complement representation. It is simply that there is no good way to define what should happen on overflow. Wrapping is easy in hardware, but is almost never useful in software. Saturation, terminating the program, throwing an exception, jumping to a debugger - these are all useful, but costly overflow behaviours. Wrapping is cheap (but certainly not free, as it hinders several nice optimisations) but almost always gives a wrong answer. If you have 2147483647 apples, and someone gives you another apple, do you suddenly have -2147483648 apples? If the C++ folks had done like the Java folks, and thought that defining integer overflow was a good idea, we'd lose out in optimisations, run-time checking tools, and static analysis tools.

It would do no harm for C++ to get a standard library with integer types with different overflow behaviours. But it would be a serious disservice to the language to make normal signed integer overflow defined in any way.

And is there also an initiative to make C++ and C's grammar, context-free?
Would be nice to have in C++ and C.

Will there be ideas from other programming languages put forth in the standardization process for C++23?
Languages such as Rustlang, Dlang, Swift (Apple) and others.

Of course the folks behind C++ changes are inspired by all sorts of other programming languages - just as other languages are inspired by C++.

[ssokolow]

Not really arguing (since C++/CLR on .NET is actually pretty good and C++/Emscripten on WebAssembly is also fantastic)...

but you have to ask yourself why Unity spent many man hours writing a .NET to C++ transpiler if managed code is so great.

It is probably one of those things where in theory JIT can be faster but in practice (or rather, the way developers use it), it simply isn't and won't be for the foreseeable future.

I never said C# could match C++. I just said that compiling to machine code isn't a panacea and that a good JIT will beat ahead-of-time compilation with weak optimization and/or optimization-unfriendly language semantics any day of the week.