| ||||
| Comment on GotW #93 Solution: Auto Variables, Part 2 by Adrian
@Herb: C++ isn’t just used on modern machines with 64-bit address spaces. It’s also used on 16-bit embedded processors, where it’s reasonable to have containers with sizes that might peak in the 32K to 64K-element range. I’ve debugged far too many crashes in my career caused by someone using a signed 16-bit int instead of an unsigned one. Even on 32-bit machines, there are too many programs that can’t handle a 4GB file. Regardless of whether vector::size_type _should_ have been unsigned, the fact that it _is_ unsigned. Mixing signed and unsigned forces you to disable compiler warnings that can help catch hard-to-reproduce bugs in other parts of the code (including some of the ones where you should have used signed arithmetic instead of unsigned). I’ve also debugged far too many crashes caused by comparing an unsigned 32-bit millisecond counter to a signed timeout value. Style guidelines that require disabling useful compiler warnings are broken. Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Jon
@Adrian: I’ve debugged far too many bugs caused by incorrect use of unsigned variables, and far fewer bugs related to using a signed int with a collection with more elements than MAX_INT. So my experience differs from yours, and I belong to the “size_type should have been unsigned” camp. I completely agree with you that mixing signed and unsigned is broken. So, perhaps casting the vector’s size to a signed variable (with an exception if it would overflow) is a solution. This limits the size by half, but avoids mixing signed/unsigned and avoids unsigned-related bugs. Note that Bjarne himself doesn’t seem too fussed using a signed variable. See http://www.stroustrup.com/bs_faq2.html#simple-program: “Yes, I know that I could declare i to be a vector::size_type rather than plain int to quiet warnings from some hyper-suspicious compilers, but in this case,I consider that too pedantic and distracting.” Read More » | ||||
| ||||
Tuesday, June 18, 2013
FeedaMail: Comments for Sutterâs Mill
Subscribe to:
Comments (Atom)