40 ms·
> Self-confidence as a programmer is when starting a new project, storing the transaction ID as a long rather than an int... uint64_t even Or a UUID as others
by rdtsc 9y ago
> Self-confidence as a programmer is when starting a new project, storing the transaction ID as a long rather than an int...
uint64_t even
Or a UUID as others have suggested.
Technically C spec doesn't really say exactly how many bits int, long and long long should be. If you want specific sizes and your code to be somewhat portable use the specific bit sizes to make that clear. There are also types for size-like things (size_t) and pointer and offset like things.
- fpgaminer 9y ago> If you want specific sizes I would go further and say you should _always_ use specific sizes, unless forced otherwise. There's no reason not to.
- majewsky 9y agoThere's a usecase for lower-bounded types such as int_least32_t, where the compiler may choose a larger type if it offers better performance. However, if you're using that, the test suite should run all relevant tests for multiple actual sizes of that particular type (through strategic use of #define, for example).
- masklinn 9y ago> There's a usecase for lower-bounded types such as int_least32_t, where the compiler may choose a larger type if it offers better performance. If you're looking for the best performances you shouldn't use leastX types, you should use fastX types (e.g. int_fast32_t for the "fastest integer type available in the implementation, that has at least 32 bits"). The difference between "leastX" and "fastX" is that "leastX" is the smallest type in the implementation which has at least X bits. So if the implementation has 16, 32 and 64b ints and is a 32b architecture, least8 would give you a 16b int but fast8 might give you a 32b one.
- wruza 9y agoThe reason is that anything else is using default types and you lose your safety battle in each: int32_t x = call_returning_int(); line. Otherwise, you assert/recover on each me-they borderline. C is a language where you have absolutely no guarantee that int or constants defined as int will fit into anything beyond int, long or long long, and then there is UB patiently waiting for your mistake. The method of handling that is to never change or fix types unless you have to, and then be careful with that.
- RcouF1uZ4gsC 9y agoThis is a perfect use for the C++ auto feature: auto x = call_returning_int();
- wruza 9y agoC had this particular feature for decades.
- louiz 9y agoNo, and it still doesn’t.
- wruza 9y agoTime to explain the joke, right? https://stackoverflow.com/questions/2192547/where-is-the-c-auto-keyword-used/2192761#2192761 https://stackoverflow.com/questions/2192547/where-is-the-c-a...
- daemin 9y agoWhat he means by that is the old definition of auto, which C++11 deprecated in favour of making it do type deduction instead. auto foo = func_returning_int(); to my knowledge worked in C because 'auto' was the lifetime keyword - like 'register' - and the default type in C is 'int'. That's why when you miss a definition in C++ the compiler warns you that there's no default int.
- kodablah 9y agoThere are reasons not to when creating RDBMS schemas.
- wott 9y agoThere are a gazillion reasons not to. You should _never_ use specific sizes, unless forced otherwise.
- bitwize 9y agoThe C spec does specify minimum sizes: at least 16 bits for int, 32 for long, and 64 for long long. Best to use the stdint types, just in case.
- deleted 9y ago[deleted]
- bcoates 9y agoYour code is actually less portable if you use types like uint64_t -- if your system doesn't have exactly that type implemented the typedef won't exist. If all you need is a really big number 'unsigned long long' is required to exist and be able to store 0..2^64-1