Using an int in a for loop that needs less than 32,767 or 65,535 iterations

that doesn't specifically have to do with messing with variable types but maybe gcc does that too

Protip, int doesn't guarantee a range bigger than (-2^15) - (2^15 - 1). Read the standard, you embarrassing tryhard. Int is also often faster than smaller types because it's usually the native word size and the CPU is optimized for these.

this is why I think the compiler is going to change this shit anyway depending on the architecture it's building for

...

b8 thread

...

I bet you're a java programmer.

that's just to avoid the repeated conditional check, if its actually useful to do so (ie checking against the length of a c-string, which is linear in cost). It might alternatively simply generate a new variable to store that value, and check against that to avoid calling string length

the problem here is using more memory than absolutely necessary to store the int, which is a separate problem. It might be reasonable for the compiler to change the memory allocation, but at the same time, might not be. Really depends on what the condition is, and more importantly, if anything is dynamic in the check.

Javafags usually don't engage in this sort of microoptimization, that's typically in the realm of """hardcore""" C++ """hackers""".

stdint contains uint8_t/int8_t.

Like they say, "one cycle is the start of a billion..."

Java doesn't even have unsigned, you think it has different integer sizes? Protip: no.

...

I have no idea what that has to do with my post, but Java does have different integer sizes, what the fuck are you on about?

True, but are they actually smaller in memory, or are they just artificially limited?
Considering how shit Java is memory-management-wise, it wouldn't surprise me if all integers are actually 64-bit longs wrapped in a class to artificially limit it and wrap around once it reaches a specific value.

Is that even a well-defined question? What's an artificially limited integer and which situations do you need to consider to answer this? A short in a x86 implementation of C will often take up 16 bits in a struct but 32 bits while passing parameters to functions. Does that mean C doesn't have real™ shorts?

C passes function arguments over registers. Ge fucking wee, any value that goes to register is automatically resized to fill entire thing, who would've thought.

The most common convention, cdecl, doesn't.

i386 is all stack bruh.

Yes. "How does Java store primitives in memory (RAM)? Are they larger than they should be for their storage capacity? And if so, to what regard, and why?"

Is the variable of proper size in memory (eg. byte == 1byte, short == 2byte, etc)?
Or are they of a larger type in memory (eg. 4 or 8 bytes) and just wrapped in an object with overloading so that for example a (signed) byte being assigned (127 + 3) equals -125 even though it has reserved enough bits in memory to technically hold 130.

The question referred to raw variables, not structs.

In C, if you write short s = 1; how many bytes does it take up in the stack/memory/whatever?
If 2 bytes then yes, C does have real™ shorts.
If != 2 bytes then no, C does not have real™ shorts.

None of those types are guaranteed to be any specific size. int is native integer type, short is not larger than int, long is not shorter than int. The only thing related to size of integer types defined in the standard is that both short and int are at least 16 bits wide, long is at least 32 bits, long long is at least 64 bits.

...

...

I bet you're one of those queers who doesn't even try to be compatible with hardware from forty years ago.

So what you're telling me is that any variable can be between 1 byte and infinite bytes depending on what our lord and savior Jesus Christ feels like that particular day?

Surely there's got to be some kind of logic. It makes no sense for an unsigned short to take up 2GB of memory while at the same time being restricted to holding only 0 - 65535.

It's not that bad, but it's fairly terrible. Take a look at this:
en.wikipedia.org/wiki/C_data_types#Basic_types

An unsigned short needs to be able to contain 0-65535, but it's allowed to be able to contain more.

Many types have a minimum size above one byte. An int is at least 16 bits, and a long is at least 32 bits and at least as large as an int, for example.

Even TCC supports c99.

Why would you keep backwards compatibility with something that's 30 years since deprecated.

That's how it works in the world of real physical hardware. Experts from magical land of Equestria need not apply.

Nope, it's also there to avoid the costliness of jumping so much, in fact that's the main reason for it (hence why some loops will be fully unrolled)

man, you must really know your assembly language very well.
16 bit ops require LONGER ENCODING on x86 and are slower.
using a char is also pointless as it will end up in a 32 bit reg.

You realize this doesn't counter anything, right? The stack is aligned in a similar way, a short on the stack can take up anything from 2 bytes to the number of bytes the stack is aligned to, and it makes sense to do that.

Fuck off Poettering.

You're just asking to make a mistake. Don't try to do the compiler's job.

You might as well just cuck yourself now fam.

This is why Holla Forums won't be able to code apps worth shit.
Arguing over shit instead of getting things done.
Enjoy your optimized software no one will ever use because it isn't yet feature-complete or that some other application exists already and has a lot more user-base than yours.

absolutely street shitter tier

i remember Holla Forums implemented echo in assembly and it was way more efficient

It had a smaller binary than GNU echo, but it had fewer features, was slower, was less portable, and was in the end not really useful for anything.