Re: int to intXX_t conversion

Kinkie <gkinkie_at_gmail.com> writes:
> On Fri, Feb 1, 2013 at 7:30 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 02/01/2013 10:20 AM, Kinkie wrote:
>>> On Fri, Feb 1, 2013 at 6:08 PM, Alex Rousskov wrote:
>>>> On 02/01/2013 04:01 AM, Kinkie wrote:
>>>>> Is there any objection for me to entertain myself doing "int" ->
>>>>> "intXX_t" and "unisgned int -> uintXX_t" conversions in the meanwhile?
>>>>> This seems to be in line with c++11 changes, and should have no
>>>>> adverse effects.
>>
>>>> What is the motivation behind this? Why intXX_t is better than int when
>>>> we do not really care about the exact variable size?
>>
>>> It adds clarity, and a predictable cross-platform, cross-os and
>>> cross-architecture memory layout.
>>
>> I am not sure int32_t adds "clarity" compared to "int" but it is
>> difficult to argue about such vague concepts, and I will not in this case.
>
> It adds consistent information: int32_t = signed integer, 32-bits
> long. int = signed integer, currently somewhere between 16 and 64 bits
> in size.

'Information' without practical values is noise: 'int' is (except on
16bit systems) a signed integer type with at least 31 value bits and
whoever provided 'the implementation' is supposed to chose 'a suitable
native type' which is 'most natural for the machine', ie, something
all common machine instruction can work with. What's the point of
replacing that with int32_t _except_ when an integer with exactly 31
value bits is specifically supposed to be used, eg in order to keep
the size of some compound type whose size matters (because it is used
a lot) 'small'? If there is no reason for "this must be exactly 32
bit", the 32_t doesn't communicate anything useful, the opposite,
actually, since it suggests that '32 bit' is a hard requirment for
some reason when it actually isn't.
Received on Sat Feb 02 2013 - 20:49:46 MST