From: Daryle Walker (darylew_at_[hidden])
Date: 2005-10-11 13:45:38
On 9/29/05 6:25 AM, "Martin Bonner" <martin.bonner_at_[hidden]> wrote:
> ----Original Message----
> From: Simon Buchan [mailto:simon_at_[hidden]]
> Sent: 29 September 2005 10:21
>> Daryle Walker wrote:
>>> The "int" type was supposed to match the processor's natural built-in
>>> integer processor. That was easy to maintain in the 16- and 32-bit
>>> eras, but got screwed up when we started 64-bit computing. The C
>>> and C++ communities decided to expand its integer types by keeping
>>> the current types at their 32-bit-era sizes and extended the type
>>> system with a "long long" instead of moving "int" and "long" up and
>>> adding a "short short". Now we don't have a convenient way to name
>>> the best integer type in a portable fashion. I suggest we add a
>>> "int_natural_t" typedef to <boost/cstdint.hpp> to name the best
>>> integer type (and a corresponding "uint_natural_t"). We would have
>>> to research what that type is for each compiler and/or platform
>>> combination and use #conditionals.
> I don't think it's worth it. The performance difference between a 16-bit
> integer and 32-bit integer on a PDP-11 was pretty significant. Is there any
> noticable difference between a 32-bit and 64-bit integer on any of the
> 64-bit processors?
I don't know what the timing difference is. But it's still a penalty we
would have to bear, especially for arrays of integers. (I wanted to create
a type that had an array of integers, kind of like a std::bitset. I just
don't want to suffer a penalty if I can avoid it.) And wouldn't the
difference get worse if/when we transition to 128-bit (or 256-bit) computing
and "int" stays at 32 bits?
>> Isn't int the 'natural' integer type, by definition?
> Depends what you mean by "natural", but for a normal English meaning,
> probably not.
[TRUNCATE a longer exposition of next sentence's content]
It was supposed to always match, but vendors "betrayed" that idea to
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk