3 ms·
> When you pass operands of different types, the language usually converts one of the operands to the other's type. (Sometimes it converts both operands to a di
by nayuki 7y ago
> When you pass operands of different types, the language usually converts one of the operands to the other's type. (Sometimes it converts both operands to a different type instead.)
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›.
- comex 7y agoYep. 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.
- ohazi 7y agoI'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.
- Gibbon1 7y agoYeah 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.
- noneeeed 7y agoRange 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.
- account42 7y agoSomething 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.
- noneeeed 7y agoIt'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.
- BoiledCabbage 7y agoYet one more thing that LISP/Scheme got right: Number Towers. Avoid all of this craziness, and just works the way the user intends. https://en.m.wikipedia.org/wiki/Numerical_tower https://en.m.wikipedia.org/wiki/Numerical_tower
- Dolores12 7y agoExplicit is better than implicit, viva Guido!