Re: [9fans] integer width on AMD64

[Comeau At9Fans <comeauat9fans@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]

On Sun, May 6, 2012 at 9:10 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Yes, the u{...}int names are important.  Those "different names" are
> > normally for other (though obviously related) purposes (conceptually
> > int_exact_*), and the int_least_* and int_fast_* names, usually are built
>
> the int_least_* names appear to me to be completely wasted, given
> this is how the normal types are defined and that you couldn't depend
> on the extra bits.


Kind of.  The thing is there is the minimums required by the standard and
then there is the minimums provided by the implementation, the latter of
which at least has to match the former.   But yes, the least names can be
viewed to just thrown a wrench into it all.


>  also, how do you debug code written like this?
>

Not easily especially when you begin to look at its interaction with I/O as
well.


> one complete test for each possible definition of int_least_*?
> of course, that leads to the question, is that set known?
>
> one also wonders about int_fast_* as well.  fast /for what/ exactly?
>

IIRC the Standard even specifically leaves that question open.  I think the
goal was to try to codify/match some existing practice at the time
realizing that it wasn't perfect but at least gave a fight chance in some
situation and in those it couldn't, there was probably going to be bumps in
the road either way.  I know it can lead to a why bother situation then.


> it seems that all this is in respose to the fact that the c-std version
> of u32int is not required.


IIRC the full set is not required but I think say uint32_t is.  But it's
been so long you might just be right.


>  (the names are somewhat offensive to
> good taste, so i refer to them as one does carlin's list, by suggestion.)
> rather than fix that issue, layering on another set of types was the
> solution.  really?
>

IIRC the naming was raised a number of times.


>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm :
>
> “       It can also be argued that programmers that use the 'intN_t' more
> than
>        likely really meant to use the 'int_leastN_t' types.  Such
> programmers
>        probably want a type with a guaranteed number of bits rather than an
>        exact number of bits.
>
>        It can be argued further that use of the 'intN_t' names is not
> portable
>        because they may not exist in all implementations.  (An
> implementation
>        is not required to provide these types.)
>
> unfortunately, there are still programmers who use the definition
> more complicated ≡ more better.  evidently believing in the
> transitive nature of "more" over false premises.


Personally I could never buy the whole argument for all those names and
such, and probably would be happy with just the exact ones.  I'm trying to
recall the exact etymology of it but it's too long ago to recall.

-- 
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 4608 bytes --]