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.
I would go further and say you should _always_ use specific sizes, unless forced otherwise. There's no reason not to.
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.
int32_t x = call_returning_int();
auto x = call_returning_int();https://stackoverflow.com/questions/2192547/where-is-the-c-a...
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.
Best to use the stdint types, just in case.
Remember, these fancy computing devices were built for the rich and the government, not for the average joe, noone thought computing would be this easily accessible.
Can't really use NAT on a primary key...
IPv6 isn't perfect, but we could have avoided a lot of hassle if we'd started off with it.
There are still plenty of people with that mindset. Some will even quote "YAGNI" when you question them.
It gets better yet when you realize that on 32bit systems (like in TFA) long usually is 32bit too ;)
I had some students that asked me if even a long would be enough to handle exponential growth, after all it's only twice as big. As a thought experiement I asked them to come up with a time to fill a 32 bit int completely. They came up with roughly a year. Then as a margin of error I said, let's assume you have 4.3 billion transactions every second instead. This volume can be sustained for 100 years, and we're still not in the danger zone yet.
2^32 ~ 4,294,967,000
2^64 ~ 18,446,700,000,000,000,000The simplest way to do that is to just throw UUID at all problems from the start. (https://github.com/alizain/ulid s are better, but there aren't libraries to generate them in literally every language + RDBMS.)
For some applications you don't want to leak the time. Choose wisely.