21–30 of 50 posts
Why not fixed-size ints - uint8_t, etc. from stdint.h? I've not been using C for a while, so I wonder what the viewpoints are regarding this.
Why not fixed-size ints - uint8_t, etc. from stdint.h? I've not been using C for a while, so I wonder what the viewpoints are regarding this.
Stupid question: why not unsigned int?
A uint that actually threw an exception or something if you tried to underflow it would be useful, but most unsigned ints nowadays aren't all that useful.
Why not fixed-size ints - uint8_t, etc. from stdint.h? I've not been using C for a while, so I wonder what the viewpoints are regarding this.
You typically want to use the native integer size for something like this, for the code to be more portable. The native integer size should really be int, but it's not defined as such in the standard. My preference at the moment: off_t for file offsets ptrdiff_t for memory offsets (vs. size_t for unsigned) int for return flags A problem with this is that printf does not have sizes to match these.
For structs where there are thousands, or millions, in memory using the smallest type required to get the job done will improve performance because you will fit more data into the cache.
For structs where there are only a dozen or so in memory at any one time, this makes sense. For structs where there are thousands, or millions, in memory using the smallest type required to get the job done will improve performance because you will fit more data into the cache.
Earlier quoted context omitted.
You typically want to use the native integer size for something like this, for the code to be more portable. The native integer size should really be int, but it's not defined as such in the standard. My preference at the moment: off_t for file offsets ptrdiff_t for memory offsets (vs. size_t for unsigned) int for return flags A problem with this is that printf does not have sizes to match these.
But then you get different behavior depending on the platform, which doesn't seem any more portable to me.
For structs where there are only a dozen or so in memory at any one time, this makes sense. For structs where there are thousands, or millions, in memory using the smallest type required to get the job done will improve performance because you will fit more data into the cache.
Only if makes the overall structure actually becomes smaller. A bunch of these shorts were surrounded by fields whose alignment means that changing to int results in no increase in the overall size of the structure. In fact, I think some of them actually got smaller due to reordering the fields to be more alignment-friendly.
Earlier quoted context omitted.
Only if makes the overall structure actually becomes smaller. A bunch of these shorts were surrounded by fields whose alignment means that changing to int results in no increase in the overall size of the structure. In fact, I think some of them actually got smaller due to reordering the fields to be more alignment-friendly.
Struct packing is something you can control at the compiler level. In gcc, you can add __attribute__((__packed__)) to your structs.
In any case, these particular structs don't have any special packing applied.
Earlier quoted context omitted.
But then you get different behavior depending on the platform, which doesn't seem any more portable to me.
I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…