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

[hoohoo]

We will be able to import header files now instead of including them; nice! This will decrease compile time. I am waiting for when C++ can create a GUI.

<s>Why is import better? Serious question.</s>

NVM, I found P1857R2.

There are many libraries for GUIs. Many are written in C++.

[cl333r]

as long as the langauge has pointers it will be possible to shoot oneself in the head. Are they going to remove pointers?

No, this is not python, even Rust has pointers and unsafe blocks.

[hoohoo]

No, this is not python, even Rust has pointers and unsafe blocks.

:-) I was being ironic. I like pointers. I use them frequently.

[CommunityMember]

Are they going to remove pointers?

No, but smart programmers use smart pointers (to reduce the likelihood of the head shots).

[TemplarGR]

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.

[carewolf]

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?

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.

Overflow is optionally trappable so it is not something that can really be codified without breaking some code, we have similar problems with runtime defined floating point behavior includign rounding, which messes with constexpr, not sure if they found a way around the latter, but that would probably be the first step towards getting rid of contextual behavior of base types.

I once lobbied for getting sign-extending arithmetic shift on signed integers codifed, and we at least go that. It was one of those features that work everywhere on every major platform and every compiler, but was officially undefined, because of of some obscure non-modern platforms.

[carewolf]

Overflow is optionally trappable so it is not something that can really be codified without breaking some code, we have similar problems with runtime defined floating point behavior includign rounding, which messes with constexpr, not sure if they found a way around the latter, but that would probably be the first step towards getting rid of contextual behavior of base types.

I once lobbied for getting sign-extending arithmetic shift on signed integers codifed, and we at least go that. It was one of those features that work everywhere on every major platform and every compiler, but was officially undefined, because of of some obscure non-modern platforms.

Besides. With two's compliment officially codified. Casting signed to unsigned, doing the addition or subtraction there and casting back to signed, should now be well defined, and gives you the result you want without doing anything undefined or triggering any signed overflow traps.

[HadrienG]

It's by design because it enables several performance optimizations. More details here:

https://kristerw.blogspot.com/2016/0...w-enables.html

This is not the intent behind that design, otherwise you would expect unsigned and signed integer overflow to obey a consistent rule.

The true rationale behind undefined signed integer overflow is that back in the dark ages where C was designed, not all mainstream hardware used two's complement representation for signed integers. And as in many other areas, the C designers decided to handwave the problem away with UB instead of properly exposing the diversity of hardware behaviors into the language.

It's only much later that compiler optimizers decided to start exploiting the UB in creative ways, which depending on who you ask was either genius (if it speeds up your code) or a terrible idea (if it breaks your code).

[TemplarGR]

This is not the intent behind that design, otherwise you would expect unsigned and signed integer overflow to obey a consistent rule.

The true rationale behind undefined signed integer overflow is that back in the dark ages where C was designed, not all mainstream hardware used two's complement representation for signed integers. And as in many other areas, the C designers decided to handwave the problem away with UB instead of properly exposing the diversity of hardware behaviors into the language.

It's only much later that compiler optimizers decided to start exploiting the UB in creative ways, which depending on who you ask was either genius (if it speeds up your code) or a terrible idea (if it breaks your code).

No, it was just a terrible idea. Don't sugar coat it.

[Weasel]

The best part by far is the [[no_unique_address]] attribute, because it allows you to create zero-overhead and syntax sugar coated properties. Just need a bit of hacking.