7 ms·
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.
by marcoms 10y ago
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.
- Sean1708 10y agoFixed sized integers are useful in two situations (that I can think of); if you're interfacing with a language that doesn't use the same integer size as your C compiler, or if you're relying on integers being a certain width (maybe you're casting between integers and non-integers, or writing a certain number of bytes to a binary file). I doubt either of these situations come up when dealing with line sizes in a text editor.
- datenwolf 10y agoAnd a third situation: Writing device drivers interfacing with hardware registers of specific sizes, although you should use `{u}int_least<N>_t` for that, to give the compiler some leeway with alignment.
- jstelly 10y agoThere are many cases where using fixed size types can save a significant amount of memory (and your application is constrained by memory on some platform) or CPU time (design to minimize cache misses happens all the time in high performance applications like games). Neither of these situations is happening in a text editor application though.
- jhallenworld 10y agoYou 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.
- omtose 10y agoBut then you get different behavior depending on the platform, which doesn't seem any more portable to me.
- accatyyc 10y agoI'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. Calculations on an 8-bit int can be slower than 64-bit ints on your 64-bit CPU, because the CPU might have to mask out the relevant part of the register to only operate on your 8 bits. And you don't gain anything by writing uint8_t, you still need to occupy a register on your CPU (which will be 64-bit). The behavior of your program will be the same on both platforms.
- coldpie 10y agoIn practice, how much of my code is going to be run on an 8-bit CPU? Zero. I'd rather have the clarity and consistent behavior of explicitly typed ints than pre-optimize for something that will almost certainly never happen.
- hwh 10y agoThe C8051 architecture is still very much a thing in the MCU world. (As is Atmel AVR.)
- prodigal_erik 10y agoThere were so many bad programmers who assumed 32 bit machines would last forever, that now we're stuck with compilers that don't default to 64 bit ints even building for 64 bit targets.
- 10y ago
- wyldfire 10y agoBest of both worlds: uint_fast8_t / uint_least8_t gives you at least 256 discrete values and likely a native/optimal-register-width allocation.
- deleted 10y ago[deleted]