Earlier quoted context omitted.
> they are opting in to a subtly different arithmetic that most people are surprised by I think that's a "citation needed" moment there. It's true that any native integer type will strange if you go outside of its defined range. The only way to avoid that is to use a language that automatically converts to bignums behind the scene (Common Lisp, etc) What I don't agree with is that this is something that "most people…
I find that most programs deal with values greater-than-or-equal-to zero. -1 is very frequently used as a sentinel value. For example, counting backwards through the elements of some container: for (i = count - 1; i >= 0; --i) /* body */; I've had plenty of bugs prevented by "comparison of signed and unsigned" warnings You wouldn't have had these warnings, much less needed to pay attention to them, if you hadn't had…
I actually think these sentinels work quite nicely with unsigned.
unsigned element_num;
static const unsigned NO_ELEMENT = (unsigned) -1;
Yes, you need a cast, but it's just one place. From then on you can use a nice constant for your sentinel.Also, your sentinel is more range-check safe then it would have been if it were an int (the classic "if (x > For example, counting backwards through the elements of some container:
Ok, that is a fair point. Tat type of loop is easy to mess up with an unsigned type. Worse, gcc will only warn you if you compile with -Wextra which not everybody does.
Actually implementing the loop in a safe manner isn't really that hard though, of course:
if (count > 0) {
unsigned i = count - 1;
do {
/* body */
} while (i-- != 0);
}
Couple extra lines, true. I don't think it loses much clarity.> For example, counting backwards through the elements of some container:
You missed my point. I mean warnings caused by "oops, that's not the variable I meant to compare with there"
It's a similar story with "const". One of the great side-benefits of using "const" consistently is that suddenly you find that the compiler starts catching more of your dumb mistakes ("oh I thought this was called like func(dest,src) but it's actually func(src,dest)" The moral is that "more info to the compiler" translates to "compiler notices a larger percentage of your dumb mistakes"
> It's impossible to convince people labouring under tyranny they've learned to love without them experiencing a free life first.
Melodramatic much?