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