Summary of C/C++ integer rules

Post by 0xffff2 » Fri, Apr 02, 2021, 5:51 PM UTC

jcelerier wrote: post #75

rualca wrote: post #59

Earlier quoted context omitted.

> This is no longer true of C++. As of C++20, signed integer types are defined to use two's complement. [0] I don't think C intends to do the same. As no good language lawyer discussion should be free from pedantry, there is no such thing as "As of C++20". C++20 is just a new version of the C++ standard. Projects that target C++11 or C++14 or C++17 are all still here and won't go away any time soon, and the respectiv…

> C++20 is just a new version of the C++ standard. and per ISO rules, older versions are withdrawn (as can be confirmed for C++ here: https://www.iso.org/standard/79358.html ) and not to be used anymore: https://www.iso.org/files/live/sites/isoorg/files/store/en/P... Other reasons why a committee may decide to propose a standard for withdrawal include the following : ▸ ▸ the standard does not reflect current practice…

Post by jcelerier » Fri, Apr 02, 2021, 7:15 PM UTC

oddthink wrote: post #80

jcelerier wrote: post #76

Earlier quoted context omitted.

> Maybe I'm spoiled by other languages with more powerful type systems, but this is exactly what I want my types to do! Isn't this why we have type traits and concepts and whatnot in C++ now? If not for semantics, why have types at all, the compiler could figure out what amount of bytes it needs to store my data in, after all. yes, but understand that, despite the name, what unsigned models in C / C++ is not "positiv…

+1 for this. I was just bitten by this last week, when I switched from using a custom container where size() was an int to a std::vector where size() is size_t. The code was check-all-pairs, e.g. for (int i = 0; i Which worked just fine for int size, but failed spectacularly for size_t size when size==0. I totally should have caught that one, but I just couldn't see it until someone else pointed it out. And then it w…

Post by giomasce » Fri, Apr 02, 2021, 7:17 PM UTC

enriquto wrote: post #57

dkersten wrote: post #54

Earlier quoted context omitted.

> No need to enforce your semantics through type Maybe I'm spoiled by other languages with more powerful type systems, but this is exactly what I want my types to do! Isn't this why we have type traits and concepts and whatnot in C++ now? If not for semantics, why have types at all, the compiler could figure out what amount of bytes it needs to store my data in, after all. I use types for two things: to map semantics…

Would you really write a function find_prime_factors() that takes an input of type "integer" and an output of type "prime", that you have previously defined? Then if you want to sum or multiply such primes you have to cast them back to integers. Maybe it makes sense for you, but for me this is the textbook example of useless over-engineering. The same ugliness occurs when using unsigned types to store values that hap…

Post by MaxBarraclough » Fri, Apr 02, 2021, 8:16 PM UTC

giomasce wrote: post #86

MaxBarraclough wrote: post #70

Earlier quoted context omitted.

> So yeah, undefined behavior isn't "implementation defined" nor "unportable" but rather "illegal not allowed wrong code". There are edge-cases even there. Calling a function generated by a JIT compiler is undefined behaviour, but there's a gentleman's agreement that the compiler won't screw it up for you. Almost all C/C++ compilers promise that floating-point division-by-zero results in NaN (the IEEE 754 behaviour),…

> There are edge-cases even there. Calling a function generated by a JIT compiler is undefined behaviour, but there's a gentleman's agreement that the compiler won't screw it up for you. Though you're not writing C/C++ in that case. You're writing "C/C++ for that particular architecture, ABI, OS and compiler". In general C/C++, if your code is correct every present and future, known and unknown compiler is supposed t…

Post by renox » Fri, Apr 02, 2021, 10:57 PM UTC

enriquto wrote: post #15

saagarjha wrote: post #4

> Having signed and unsigned variants of every integer type essentially doubles the number of options to choose from. This adds to the mental burden, yet has little payoff because signed types can do almost everything that unsigned ones can. Unsigned types are quite useful when doing bit twiddling because they don't overflow or have a bit taken up by the sign.

> Unsigned types are quite useful when doing bit twiddling because they don't overflow or have a bit taken up by the sign. That's essentially their only application. The rest are stupid single-bit memory-size optimizations. As Jens Gustedt noted, it's one of the (many) misnomers in the C language. It should be better called "modulo" instead of "unsigned". Other such misnomers that I recall: unsigned -> modulo char ->…