C++20 Making Progress On Modules, Memory Model Updates

[kpedersen]

I would natively compile C# and call it a day. C++ is basically trying to add all of the things that C# has but without looking like they are copying. Might as well go straight to the source.

The problem for me isnt the language. The big issue with C++/clr, C# and VB.NET is .NET and the fact that it is not very portable to alternative architectures. If you look at .NET core, you will see that the .NET Jit only supports x86 and ARM. This is pretty crap.

Unity gets round it by using IL2cpp. Can you even class this as a feature of C# then? It is more a C# transpiler I suppose.

AOT compiling is also no good because the garbage collector and runtime (which is not fully compiled AOT) are still unportable junk.

Java is mostly the same. The only difference is that Java has been around longer and has been painstakingly (And I mean it, I think people have not had much fun doing it) porting it to other platforms.

Basically the technologies nearest to the goal of portability and being platform agnostic is C (and to a lesser extent with each standard, C++). There often isn't much other choice from what I can see if you want to be able to write once and compile anywhere.

[DavidBrown]

Signed integers are now officially two's complient! I asked them to preempt C on this. Finally we can use right shifts without triggering ubsan.

Specifying that integers are two's complement is convenient for when you need very low-level code, or binary data structure compatibility (think file formats, network protocols, etc.).

But no one sane uses right-shift on negative integers anyway. A few people think it is a good way to do division by powers of two, which it perhaps was, some 25 years ago. Having two's complement integers means you can cast to an unsigned integer type and get the results you expect - then you use unsigned types for bit manipulation, shifting, etc.

Personally, I'd be happy to see all shifts, bit operations (&, |, ^, ~) and logical operations (&&, ||, !) made syntax errors for signed types.

[carewolf]

Specifying that integers are two's complement is convenient for when you need very low-level code, or binary data structure compatibility (think file formats, network protocols, etc.).

But no one sane uses right-shift on negative integers anyway. A few people think it is a good way to do division by powers of two, which it perhaps was, some 25 years ago.

It still is, it is just what the compiler rewrites your division into

But if you are using SIMD instructions or coding for a GPU, you might need to do it manually when switching between different bitwidths of signed integer

[DavidBrown]

It still is, it is just what the compiler rewrites your division into

Exactly. If you want to divide "x" by 8, write "x / 8". Don't write "x >> 3". Write what you mean - it is easier to write, easier for people to read, easier for the compiler to optimise, and easier to get right. Then it is the compiler's job to figure out if the best choice is a shift, or rolling the operation together with other expressions, or whatever gives the most efficient results for the expression you requested.

But if you are using SIMD instructions or coding for a GPU, you might need to do it manually when switching between different bitwidths of signed integer

Certainly shift operations are sometimes useful. But these are low-level bit operations, not arithmetic operations - do them with unsigned types.

[Weasel]

The main problem is that it is not "separation", it is "duplication". You manually have to manually write every method signature twice, it is a DRY fail. As other languages demonstrate, the definition part can be simply generated instead (for example javadoc).

Copy-paste is a thing. Duplicating it is actually better because it will give an error when they mismatch later so you know you changed the interface which is a big deal.

[Weasel]

Exactly. If you want to divide "x" by 8, write "x / 8". Don't write "x >> 3". Write what you mean - it is easier to write, easier for people to read, easier for the compiler to optimise, and easier to get right.

...and apparently not easy enough for people like you to understand.

Right shift truncates towards -inf for negative numbers, while division truncates towards 0.

So no, it's actually not easy AT ALL for the compiler to optimize. If it can't prove the numbers are strictly positive (in which case you should shoot yourself for using a signed type), then it will generate about 4 instructions for what should be just 1.

But people like you just parrot and preach crap they don't understand (but WANT to believe it's true) and pollute sites like stackoverflow with wrong information.

x / 8 truly generates worse code for signed integers, and it only gets worse with other types of divisors (non power of 2). Keep believing it's "easy" for the compiler to optimize tho.

[carewolf]

Exactly. If you want to divide "x" by 8, write "x / 8". Don't write "x >> 3". Write what you mean - it is easier to write, easier for people to read, easier for the compiler to optimise, and easier to get right. Then it is the compiler's job to figure out if the best choice is a shift, or rolling the operation together with other expressions, or whatever gives the most efficient results for the expression you requested.



Certainly shift operations are sometimes useful. But these are low-level bit operations, not arithmetic operations - do them with unsigned types.

But that doesn't give you sign extension which is often useful or needed. But sure invent a new syntax for sign extending shifts on unsigned and we wouldn't need shifting on signed numbers.

[paulpach]

Copy-paste is a thing. Duplicating it is actually better because it will give an error when they mismatch later so you know you changed the interface which is a big deal.

By that logic, why duplicate it only once? you should be required to write the same code 10 times to be extra sure that you did not make a mistake.

[Weasel]

By that logic, why duplicate it only once? you should be required to write the same code 10 times to be extra sure that you did not make a mistake.

It's not about making a mistake necessarily, it's about changing something and forgetting. This practice is present even when changing passwords or sensitive email addresses.

There's no gain going from 2 to 3 because the moment you changed it TWICE, you already are aware of the change.

[andreano]

no one sane uses right-shift on negative integers anyway.

It's not just about right shift. Comparions between signed and unsigned integers triggers the dreaded -Wsign-compare warning on gcc, even for equality comparisons (==, !=), which, when you know that the target CPU is two's complement, does exactly the same for signed and unsigned integers – a false positive!

Now that the compiler agrees that the target CPU is two's complement, I'm hoping we can finally compile with -Wextra without seeing that warning inappropriately.