Malcolm: Usability improvements in GCC 8 [LWN.net]

Malcolm: Usability improvements in GCC 8

Posted Mar 22, 2018 4:32 UTC (Thu) by ncm (guest, #165)
Parent article: Malcolm: Usability improvements in GCC 8

I would like it to suggest alternatives to comparing signed with unsigned values. Too often I see people add a cast, or change the type of a variable, when 9 times out of 10, changing < to != is the better choice. (In C and, still, in C++, (-1 < 0u) is false, hence the warning. But the C++ people have vowed to fix it someday -- most likely c. 2029.)

By the way, the compiler people say "for (int i =..." is much better, nowadays, than "for (size_t i =...", although of course "for (auto val : ..." or "std::foreach(..." is better than either.

to post comments

Malcolm: Usability improvements in GCC 8

Posted Mar 23, 2018 14:44 UTC (Fri) by anton (subscriber, #25547) [Link] (1 responses)

By the way, the compiler people say "for (int i =..." is much better, nowadays, than "for (size_t i =...", although of course "for (auto val : ..." or "std::foreach(..." is better than either.

The latter two are not C, so I guess they are better in the eyes of a C++ fan.

Concerning "for (int i=...", this introduces sign-extension operations when using i for array indexing when compiling for AMD64 with -fwrapv (which is needed for a lot of production code); using long instead of int is one way to solve this if you don't expect i to wrap around.

Alternatively, this problem is also solved by using size_t (if the code is correct for size_t, which it presumably is if it started out with size_t), so suggesting that users replace size_t with int makes no sense (except if a compiler maintainer wants to justify the adversarial default of -fno-wrapv by first getting the user to pessimize his program, and then using this default to undo the pessimization).

Malcolm: Usability improvements in GCC 8

Posted Mar 24, 2018 16:59 UTC (Sat) by zlynx (guest, #2285) [Link]

If the for loop has explicit, understandable termination conditions there's no problem using size_t. GCC as far as I can tell compiles the loop the same way for int or size_t. And size_t is always better because it won't fail like int on unusually large indexes.

So yeah, just use size_t.