Kinkie <[email protected]> writes: > On Fri, Feb 1, 2013 at 7:30 PM, Alex Rousskov > <[email protected]> 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.
