6 ms·

From the Google C++ Style Guide: "You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pat

• coolgeek 12y ago
  From the coolgeek style guide: "Never use a signed type for a number that can never be negative" One of my pet peeves is developers using int (instead of unsigned ints) for primary keys in database tables.
  • tiglionabbit 12y ago
    Unsigned ints aren't supported by any sql database.
    • MrOrelliOReilly 12y ago
      Sarcasm? http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview...
      • esaym 12y ago
        His sarcasm is saying that mysql isn't a real database since it has data types that break the sql standard I guess. "SQL only specifies the integer types integer (or int), smallint, and bigint." http://www.postgresql.org/docs/9.3/static/datatype-numeric.html#DATATYPE-INT http://www.postgresql.org/docs/9.3/static/datatype-numeric.h...
      • tiglionabbit 12y ago
        Oh, I wasn't aware that there was a database that supported them. I mostly use postgres and sqlite, which both do not support them.
    • deleted 12y ago
      [deleted]
  • sytelus 12y ago
    +1. Everytime I see for(int i=0;...;i++) I wonder why we have developed this habit of defaulting all int as signed and consider uint as taboo (most coding guidelines asks not to use them unless "you know what you are doing"). Most of the time we use integers for counting and so uint should have been more natural. I did this in one of my libraries I was writing from scratch and I was happy for a while but then I got in to trouble because there is lot of code out there with interfaces expecting signed ints even though they should using uint. So ultimately the legacy forced me back to default again at using signed int.
    • dkbrk 12y ago
      > Everytime I see for(int i=0;...;i++) In this case, it makes absolutely no difference at all. It could be argued that writing unsigned int would make the code slightly harder to read. That said, I like to use stdint.h and unint32_t would, I think, not have any drawbacks. > there is lot of code out there with interfaces expecting signed ints even though they should using uint That's not a good reason to not use unsigned integers, it's a zero-overhead cast from unsigned to signed (at the risk of overflowing into the negative).
      • Joky 12y ago
        It change the semantic on the loop bound, and thus what the compiler can/cannot do when optimizing the code. Using uint limits the optimizer...
        • detrino 12y ago
          Using int also limits the optimizer in some ways, for example division/modulo becomes more expensive. Every time I see someone mention the optimization argument for signed integers I ask for examples and I've yet see a good one.
    • yongjik 12y ago
      Well, in my case, from time to time I have to do these stuff: for (int i = x.size() - 1; i >= 0; i--) ... for (int i = 0; i < x.size() - 1; i++) if (x[i] < x[i+1]) ... Both will blow up badly with unsigned ints. (Well, to be fair, both will blow up with signed ints if x.size() is greater than 2G, so it's a matter of expectations.)
  • 10098 12y ago
    yeah, some numbers can never be negative, but their difference can. and that's when it usually comes to bite me in the ass. i almost never use unsigned ints now.
    • nly 12y ago
      I disagree, signed integer arithmetic in C and C++ is just toxic. Sure, if you need to compute the difference between two integers, which have both been pre-checked to lie between say -100 and +100, then fine, use signed ints... but for arbitrary input you need to do more work. There's example code on the CERT secure coding guidelines here (look under 'Substraction'): https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow https://www.securecoding.cert.org/confluence/display/seccode... Writing safe code to calculate the absolute difference between two unsigned integers is much less hairy: max(x,y) - min(y,x).
      • Joky 12y ago
        This is true for a signed addition as well, since you are not allowed to overflow.
      • rtpg 12y ago
        do these problems disappear with unsigned arithmetic?
      • sjolsen 12y ago
        All arithmetic in C and C++ is toxic. That's the reality of using bounded-precision types. Honestly, I wish they'd had the foresight not to use the traditional infix operators for built-in types; they practically beg programmers to implicitly treat built-in types like the mathematical types they very vaguely resemble. Really, working directly in fixed-precision arithmetic is absurd. In order to be able to rely on its correctness with any degree of certainty, you need to very carefully track each operation and its bounds, at which point you may as well have just used arbitrary-precision types, explicitly encoded your constraints, and had the compiler optimize things down to scalar types when possible, warning when not.
  • ANTSANTS 12y ago
    Every time I see if (index < 0) { /* error */ } I die a little inside.
  • imanaccount247 12y ago
    >One of my pet peeves is developers using int (instead of unsigned ints) for primary keys in database tables. Seems like a pretty ignorant pet peeve considering that's the only option for every database that doesn't auto-corrupt data.
  • einhverfr 12y ago
    PostgreSQL doesn't give you an unsigned int option but if they did I wouldn't use it. Having a negative pkey space is actually useful. In LSMB we reserve all negative id's for test cases, which are guaranteed to roll back. This has a number of advantages including the ability to run a full test run on a production system without any possibility of leaving traces in the db.
  • TorKlingberg 12y ago
    There are two schools of though here, and I am not convinced either is obviously right. 1) If you don't need negative numbers, use unsigned integers. 2) If you don't need the extra positive range of unsigned integers (or defined wrapping), use signed. You advocate (1), but C is generally based on (2), with the default int being signed, and many standard functions using plain int.
  • dragonwriter 12y ago
    Most DBs don't support unsigned int [0] as a type (though its perfectly sensible to have a constraint that enforces >0.) [0] though several do support UUIDs, which are essentially unsigned 128-bit ints, and which (with a well-selected generation mechanism) are better as server-assigned surrogate keys than sequential integers, signed or unsigned, anyway.
• mohawk 12y ago
  That seems like bad advice to me. A possible infinite loop is given as justification in case of wrongly implemented reverse iteration (counting down an unsigned loop variable). Well, i claim that an infinite loop is a much more noticeable bug than undefined overflow behaviour, negative view counts, etc. Unsigned ints will make bugs impossible that with signed ints will (hopefully, famous last words) trigger assertions, if they are enabled...
• Buge 12y ago
  One problem with this is that the sizes of STL containers are returned unsigned, and with high warning levels, compilers will warn about comparing a signed int with one of these sizes.
  • cjensen 12y ago
    The size of everything is unsigned. You may not know if size_t is unsigned int or unsigned long, but you can always be sure it isn't int.
• nly 12y ago
  Which is a completely birdbrained policy given that signed integer under and overflow is completely undefined. If you want to catch implicit signed -> unsigned conversions then enable that warning on your compiler.... what they'd advocating is just dangerous.
  • rmrfrmrf 12y ago
    In a strict typing environment, the other major issue is that int is cross-platform and forward compatible whereas uint32_t, uint64_t, uint8_t, uint16_t, etc. will all always be unsigned within a specified bound, so whenever we have 128-bit or 256-bit registers, we'll have to go back and update all this code that effectively "optimizes" 1 bit of information (nevermind the fact that int is usually more optimized than uint these days). Furthermore, casting uintx_t to int and back again while using shared libraries is a huge pain in the ass and can waste a lot of programmer time that would be better spent elsewhere, especially when working with ints and uints together (casting errors, usually in the form of a misplaced parenthesis, are pretty small and can take a very long time to find).
    • mikeash 12y ago
      You don't have to update code. If 64 bits was enough on a 64-bit CPU, it'll be enough on a 128-bit CPU. The one exception is when dealing with quantities that actually depend on the bit width of the CPU, like dealing with array sizes. The language already has good types for this, like size_t, and using int won't save you. (Quite the contrary, int will sink you, because int is almost always 32 bits even on 64-bit systems.)
      • dwd 12y ago
        I had my first nasty production bug (back in the early 2000s) when I assumed an Integer was 32bit in VBScript. 2 billion survey results was never going to happen. 32,767 would have been fine as well except to compound the issue ops pointed the production site at the test database.
    • nly 12y ago