Re: Why in stdint.h have both least and fast integer types?
From: Flash Gordon (spam_at_flash-gordon.me.uk)
Date: 12/01/04
- Next message: Keith Thompson: "Re: Zero length array declaration"
- Previous message: jjr2004a: "Re: Zero length array declaration"
- In reply to: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Next in thread: Gordon Burditt: "Re: Why in stdint.h have both least and fast integer types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 1 Dec 2004 22:08:08 +0000
On Wed, 1 Dec 2004 18:35:19 -0000
"James Harris" <no.email.please> wrote:
> "Kevin Bracey" <kevin.bracey@tematic.com> wrote in message
> news:cc6f86154d.kbracey@tematic.com...
> > In message <79062cd3.0411270240.29d3a4f7@posting.google.com>
> > groupstudy2001@yahoo.co.uk (GS) wrote:
> >
> >> The stdint.h header definition mentions five integer categories,
> >>
> >> 1) exact width, eg., int32_t
> >> 2) at least as wide as, eg., int_least32_t
> >> 3) as fast as possible but at least as wide as, eg., int_fast32_t
> >> 4) integer capable of holding a pointer, intptr_t
> >> 5) widest integer in the implementation, intmax_t
> >>
> >> Is there a valid motivation for having both int_least and int_fast?
> >
> > The point you missed is that the _least types are supposed to be the
> > *smallest* types at least as wide, as opposed to the *fastest*,
> > which are designated by _fast.
>
> The *smallest* type as least as wide as 16 is of width 16, no?
Only on implementations *having* a type that is exactly 16 bits wide.
> If it
> is impossible to support an integer of width 16 (18-bit word, for
> instance) how does the implementation deal with this standard's
> int16_t?
That's simple. It does not define int16_t
> > A typical example might be the ARM, which (until ARMv4) had no
> > 16-bit memory
> > access instructions, and still has only 32-bit registers and
> > arithmetic instructions. There int_least16_t would be 16-bit, but
> > int_fast16_t might be
> > 32-bit.
> >
> > How you decide what's "fastest" is the tricky bit.
>
> Absolutely! There is no point making a data type "fast" if it is to be
> repeatedly compared with values which are not the same width. Of
> course, operations are fast or slow, not data values. Is the standard
> confusing two orthogonal issues?
There are generally speed issues which are related to size, such as a
system with a 32 bit address bus that can quickly access a 32 bit type
but has to either mask or shift the data to access a 16 bit value.
<snip>
> I can see your point here. It's a subtlety. I still wonder, though, if
> I wouldn't prefer to specify that array as int16_t. Specifying
> int_least16_t is making me a hostage to the compiler. If I am taking
> in to account the architecture of the underlying machine (in this
> case, primary cache size) wouldn't I be better writing more precise
> requirements than int_leastX_t?
Well, when you port the SW to a 32 bit DSP processor that has absolutely
no support for 16 bit data and therefor does not provide int16_t? Such
an implementation can easily provide both int_least16_t and
int_fast16_t, anthough they would both be identical to int32_t
-- Flash Gordon Living in interesting times. Although my email address says spam, it is real and I read it.
- Next message: Keith Thompson: "Re: Zero length array declaration"
- Previous message: jjr2004a: "Re: Zero length array declaration"
- In reply to: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Next in thread: Gordon Burditt: "Re: Why in stdint.h have both least and fast integer types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
