Re: Why in stdint.h have both least and fast integer types?
From: James Harris (no.email.please)
Date: 12/01/04
- Next message: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Previous message: Gregg Wood***: "compiler won't allow dimensioned array of Char* to be signed to another???"
- Maybe in reply to: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Next in thread: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 1 Dec 2004 18:18:45 -0000
"Charlie Gordon" <news@chqrlie.org> wrote in message
news:cof17g$omq$1@reader1.imaginet.fr...
<snip>
>> Interesting example but what advantage does int_least16_t really give?
>> If
>> we are talking about a few scalars wouldn't it be OK to let the compiler
>> represent them as int32s since they are faster? If, on the other hand,
>> these were stored in arrays
>> int_least16_t fred [10000];
>> why not let the compiler choose whether to store as int16 or int32,
>> depending on it's optimization constraints?
>
> That would create incompatibilities between modules compiled with
> different
> optimisation settings : a horrible side effect, that would cause
> unlimited
> headaches !
But isn't that exactly what int_least16_t does? It requires compilation
under the same rules for all modules which are to be linked together (and
that share data). Otherwise chaos will ensue. Given that the compilation
rules must match why have the three types of 16-bit integer? I can see the
need for two,
1) an integer that is at least N bits wide but upon which operations are as
fast as possible,
2) an integer than behaves as if it is exactly N bits wide - for shifts
etc.,
but I'm not sure about having a third option. This seems a bit baroque and
not in keeping with the lean nature that is the essence of C. It also seems
to me to confuse the performance vs. space issue with program logic. Is
this a set of data types designed by committee? I wonder what Ken Thompson
and Dennis Ritchie make of it.
> My understanding is that int16_t must be exactly 16 bits.
> int_least16_t should be the practical choice on machines where 16 bit
> ints have
> to be emulated for instance, but otherwise would still be implemented as
> 16 bit
> ints, whereas int_fast16_t would only be 16 bits if that's the fastest
> option.
>
> There really is more than just the speed/size tradeoff: practical/precise
> is
> another dimension to take into account.
Agreed.
- Next message: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Previous message: Gregg Wood***: "compiler won't allow dimensioned array of Char* to be signed to another???"
- Maybe in reply to: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Next in thread: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]