Yep, I always default to the largest possible type because compute is less valuable than my time on the weekend and the potential for any sort of overflow.
The compiler doesn’t know what numbers are going to go into a variable, that’s a runtime thing. They might prevent a crash that way, but a crash or not doesn’t matter when people need the number in the database and the database doesn’t let you put the number in the database.
i mean, at least with rust, running in debug mode (or release with flags) will hard panic if an overflow occurs, bc it checks everytime a number is changed. it is obviously less performant to do this, so it does not check when running in release/production mode. the problem is if you need to have no overflows occur, it is better to throw an error and exit the program, than cause unexpected behaviour, eg. as an incorrect, but existing array item. this could be hard to find the cause of the bug if it doesnt throw
you can just use unsigned long long (drop the int) or, if it bothers you that much, uint64t but keep in mind that yhe size of unsigned long long may vary depending on the architecture
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
Solution:
export type unsigned_int = numbertbh unsigned int scares me too. I just use int anyway to avoid strange things happening.
Yep, I always default to the largest possible type because compute is less valuable than my time on the weekend and the potential for any sort of overflow.
Long
Double
Big int
Etc.
why not just compile with overflow checking? assuming the number should not reach the limits
The compiler doesn’t know what numbers are going to go into a variable, that’s a runtime thing. They might prevent a crash that way, but a crash or not doesn’t matter when people need the number in the database and the database doesn’t let you put the number in the database.
i mean, at least with rust, running in debug mode (or release with flags) will hard panic if an overflow occurs, bc it checks everytime a number is changed. it is obviously less performant to do this, so it does not check when running in release/production mode. the problem is if you need to have no overflows occur, it is better to throw an error and exit the program, than cause unexpected behaviour, eg. as an incorrect, but existing array item. this could be hard to find the cause of the bug if it doesnt throw
I’m a C# dev so I forget that anything that’s not this case even exists. Agreed 100 percent.
The use of it quite limited in the every-day coders life. People acting like they be using 500TB databases these days.
Embedded software devs still exist btw
Stop lying, who in the modern world would need embedded systems?
const a: any = “You have no power here!”
tbh c/c++ type system is super fucked up
What the fuck is
unsigned long long intjust call itu64Well it isn’t always 64 bytes. Some architectures differ.
usizethenyou can just use
unsigned long long(drop the int) or, if it bothers you that much,uint64tbut keep in mind that yhe size ofunsigned long longmay vary depending on the architecture