I've heard a lot about NULL being considered a multi-billion-dollar mistake, but not a lot about the wishy-washy integer types hierarchy.
The more explicit stdint types (e.g. uint32_t) are both safer and more portable. Modern languages like Rust seem to agree... (u8, i32, etc).
The argument I've always heard was that you want your program to use the sizes that the architecture can handle most efficiently. But actually, I don't. I'd rather my program run correctly, the way I intended, even if that means it runs a little slower on a sparc or powerpc.
The combinatoric explosion of size hierarchies is basically impossible for normal people to reason about or test for.
Yeah things I would get rid of in c is 'int' and the wishy washy integer type non sense that goes with it. The whole thing was a big pain in the ass until pure 32 bit machines came along and everyone forgot. Now it's a pain in the ass again.
I'd also add range types ala Ada.
Re:Warning: Implicit Backdoor
by BoiledCabbage on Thursday September 05, 2019 @07:35AM
(#20885662)
Yet one more thing that LISP/Scheme got right: Number Towers. Avoid all of this craziness, and just works the way the user intends.
Range types were one of my favourite features of the Ada type system. Such a simple idea, but super effective, and really useful when doing static analysis. Being able to push constraints to the interface simplified a lot of things.
Something like that is what I am hoping we get with contracts when they make it into C++. Although the versions so far only add constraints to functions, having them on types as well sounds very useful.
It's great. It allows you to push the responsibility for checking values are in type right out to the earliest point, reducing the need to sprinkle bounds checking code all over the place. If you are using static analysis like SPARK or one of the others, it then lets you do a load more of it automatically, the constraints it places on values makes it much easier to statically demonstrate runtime properties of the code before.
Yep. Also, if both operands have types smaller than int, they’ll both be converted to int as part of the “integer promotions” step. This is less likely to lead to surprising results since the conversion is value-preserving, but it’s inconsistent with the behavior of int-and-larger types.
Indeed. The pathological example where both operands get converted to a different type is like this: Assume that ‹int› is 32 bits and ‹long› is 32 bits. Then ‹unsigned int› + ‹long› becomes ‹unsigned long›. This is because ‹long› has a higher rank than ‹int›, so the result must have the rank of long. But because ‹long› cannot hold all values of ‹unsigned int›, we must use ‹unsigned long›.