3 ms·

> 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 c

> 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 "positive numbers" but "modulo 2^N" arithmetic (while signed models the usual arithmetic). There is no good type that says "always positive" by default in C or C++ - any type which gives you an infinite loop if you do for({int,unsigned,whatever} i = 0; i < n - 1; i++) { // oops, n was zero, n - 1 is 4.something billion, see you tomorrow } is not a good type. If you want a "always positive" type use some safe_int template such as https://github.com/dcleblanc/SafeInt https://github.com/dcleblanc/SafeInt - here if you do "x - y" and the result of the computation should be negative, then you'll get the rightful runtime error that you want, not some arbitrarily high and incorrect number The correct uses of unsigned are for instance for computations of hashes, crypto algorithms, random number generation, etc... as those are in general defined in modular arithmetic

oddthink 6y ago
+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 < container.size() - 1; ++i) { for (int j = i + 1; j < container.size(); ++j) { stuff(container[i], container[j]); } } 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 was obvious, like many bugs.
- jcelerier 6y ago
  I recommend using -fsanitize=undefined -fsanitize=integer if you can build with clang - it will print a warning when an unsigned int underflows which catches a terrifying amount of similar bugs the first time it is run (there are a lot of false positives in hash functions, etc though but imho it's well worth using regularly)

oddthink 6y ago

+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 < container.size() - 1; ++i) { for (int j = i + 1; j < container.size(); ++j) { stuff(container[i], container[j]); } } 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 was obvious, like many bugs.

jcelerier 6y ago
I recommend using -fsanitize=undefined -fsanitize=integer if you can build with clang - it will print a warning when an unsigned int underflows which catches a terrifying amount of similar bugs the first time it is run (there are a lot of false positives in hash functions, etc though but imho it's well worth using regularly)