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

[plonoma]

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.

Thanks for your information and work on C++.

[plonoma]

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.




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

What if math operators with explicitly defined over- and underflow behaviour would be added? Could that work?
E.g. +%%, -%%, *%%, /%%, etc. Or +%, -%, *%, /%. I do NOT know which syntax (a trailing % or %% for both over- and underflow wraparound behaviour) would be the best.
Also bit shift operators that put the removed bit back in the blank space generated by the shift; <<% and >>%.

Or what if the default behaviour of math on a variable would be indicated with an attribute?
[[wraparound]] and [[saturation]]

What if the default over- and underflow behaviour of math on a variable would be indicated with a property?

Or alternatively with a macro, specifier or other thing.

[DavidBrown]

I thought the Boost libraries were going to be incorporated into the standard at some point. I love boost and tend to use it over std.

Boost libraries are often used as a playground or test for what would be useful in later versions of the standard library. Some Boost libraries get taken almost directly into the library, but most do not. Many others are used as inspiration, and perhaps for ideas about what needs to be changed in the core language to get similar results without some of the most horrendous coding tricks that are needed to make Boost work.

[DavidBrown]

What if math operators with explicitly defined over- and underflow behaviour would be added? Could that work?
E.g. +%%, -%%, *%%, /%%, etc.
Also bit shift operators that put the removed bit back in the blank space generated by the shift; <<% and >>%.

Or what if the default behaviour of math on a variable would be indicated with an attribute?
[[wraparound]] and [[saturation]]

What if the default over- and underflow behaviour of math on a variable would be indicated with a property?

Or alternatively with a macro, specifier or other thing.

No, maths operators with explicitly defined overflow behaviour would not work. They would be overwhelming, no one would remember them, and they would not be used. Excessive numbers of operators or overly complicated operators never work well in a programming language (except in APL, of course).

It would be fine to make C++ classes (or, more accurately, class templates) for integer types with specific overflow behaviour. That could be done today, just as a library.

Rotations could be made as separate operators (<<< and >>> are the usual choices), but they are actually very rare in code. You get them in specific types of code (like cryptography), but not much in general code. C++20 has std::rotr and std::rotl.

[plonoma]

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++)?

So Rust and Dlang do not have technical deficits like the other languages have, interesting.
What do you think of Rust's borrow checker?

[plonoma]

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.

But that's a very roundabout way of doing things.
Surely being able to do the operation on a signed numeric variable in one step would be faster while providing more readable and elegant code.

[plonoma]

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).

Interesting point you have there. How should C++ have properly exposed the diversity of hardware behaviors?
Please do think about it for a while and proofread. Don't be afraid to write too much.
Myself as well as other readers might be very interested in what you come up with.

And if you have good ideas maybe it's a good idea to talk about them at the appropriate place. As another poster told me in a reply: join the C++ standardization process and participate to make sure your issues/ideas receive the appropriate consideration. More details on participation can be found at: https://isocpp.org/std

[plonoma]

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).

If you are worried please join the C++ standardization process and participate to make sure your issues/ideas receive the appropriate consideration. More details on participation can be found at: https://isocpp.org/std

[plonoma]

No, maths operators with explicitly defined overflow behaviour would not work. They would be overwhelming, no one would remember them, and they would not be used. Excessive numbers of operators or overly complicated operators never work well in a programming language (except in APL, of course).

It would be fine to make C++ classes (or, more accurately, class templates) for integer types with specific overflow behaviour. That could be done today, just as a library.

Rotations could be made as separate operators (<<< and >>> are the usual choices), but they are actually very rare in code. You get them in specific types of code (like cryptography), but not much in general code. C++20 has std::rotr and std::rotl.

OMG!!!! Overwhelming, no one would remember. My dreams of more operators are totally crushed!
I'm fine though. Really, it's nothing.
joke: And C++ shall therefore forever be a totally lean, compact language with no bloat whatsoever! LOL
C++ is already a lost cause, full bloat ahead!! MOAR operators to the max!
/joke

[carewolf]

But that's a very roundabout way of doing things.
Surely being able to do the operation on a signed numeric variable in one step would be faster while providing more readable and elegant code.

No, doing it in unsigned is actually faster. C casting does no computation, but only controls how instructions are selected. So casting+operating+casting back is still one instruction, but now one that doesn't set CPU-flags, so one with less hazards so potentially slightly faster. Even if both signed and unsigned addition are 1 clock instructions, the unsigned one is easier for the CPU to perform out of order because it has fewer side effects.

But yes, it looks like shit in code.