[ub] [c++std-ext-14592] Re: Re: Sized integer types and char bits

Ion Gaztañaga igaztanaga at gmail.com
Mon Oct 28 22:43:39 CET 2013


El 28/10/2013 2:32, Lawrence Crowl escribió:

>> I think requiring 2's complement in the long term would be a
>> good idea, even in C, as no new architecture is using other
>> representation and this simplifies teaching and programming in
>> C/C++.
>
> Why do you think intN_t is not sufficient?  The interpretation is
> that int means "representation is not relevant, add traps if you
> want" while (e.g.) int32_t means "I care about representation".

It's not enough because they don't cover some types like 24 bit or 128 
bit integers with no padding, available in some modern systems. And more 
importantly, 2's complement simplifies the language with little loss in 
portability (unisys machines currently don't support C++). C could have 
supported systems with CHAR_BIT < 8 but the committee chose not to allow 
that. Not supporting (rare and in extinction) one's complement or 
sign-magnitude representations it's a similar decision for C++.

>> We could start having a ISO C macro (for C compatibility) to
>> detect 2's complement at compile time and deprecate 1's complement
>> a sign-magnitude representations for C++. If no one objects then
>> only 2's complement could be allowed for the next standard.
>
> WG21 cannot add a macro to ISO C.  Did you mean laison work or did
> you mean simply adding a macro?

I meant a liason work.

>> I think banning or deprecating systems with CHAR_BIT != 8 would be
>> a very bad idea as C++ is a natural choice for high-performance
>> data/signal processors.
>
> Agreed.  But also, it turns out, a UTF-12 and UTF-24 are pretty
> good at representing Unicode.

char_least12_t & char_least24_t to the rescue? ;-)

Best,

Ion


More information about the ub mailing list