|Re: Aliasing in ISO C email@example.com (1996-02-16)|
|Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) jgm@CS.Cornell.EDU (1996-02-19)|
|Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) firstname.lastname@example.org (Henry Spencer) (1996-02-27)|
|Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) email@example.com (1996-03-06)|
|Basic data types (was: Re: Languages: The Bigger the Uglier) firstname.lastname@example.org (1996-03-14)|
|From:||email@example.com (Jens Hansson)|
|Date:||14 Mar 1996 17:01:42 -0500|
|References:||96-02-187 96-02-234 96-02-308 96-03-050|
>[The usual justification for allowing different integer sizes and other
>such variations from one platform to another is that if you tie down too
>many details, you make it impractical for the language to run reasonable
>on machines with different word sizes.
In my opinion, the only reasonable precision of an unspecified
"integer" would be one of arbitrary size. In any other case, one user
will some day enter a too large value into your program (or library
routines). I want to use these "integers" even when developing
cryptographic routines or whatever!
Then, you could boost performance by subtyping this integer to a
subrange, or modulus arithmetic (mod 2**16 ...), though these
optimisations might improve by hardware knowledge.
If the programmer uses a subrange without range checking, the compiler
could round the size up to something more efficient.
With masks, the programmer actually should use bit vectors (or maybe
packed records a la Pascal) instead of integers. This way, the
compiler could round up the size of the mask.
Return to the
Search the comp.compilers archives again.