According to P0909R4, which either was adopted for C++20 or some close
descendent was adopted for C++20, not only is arithmetic on signed integers
now always two's complement, in C++, but also "the representations of
integral types shall define values by use of a pure binary numeration system"
(although TBH I don't know where that wording comes from now, that wording
was in C++03 standard apparently).

Anyway, to me that means that official standard C++ requires binary
representation, period.

Now, if you want to write (or somehow acquire) a C++-ish language compiler
for a non-binary computer or device then that's ok. It's just necessarily
going to be not *really* C++ but some approximation. You shouldn't call it
C++, but you could, if you wanted, and the language was close enough, just
distribute an errata sheet that said "this compiler isn't really C++, but
its close, so use the C++ standard as a baseline but know that the
following changes apply to this non-C++ language you're working with here"
- followed by a list of said changes. Including how the bit and bitset
libraries and the bit manipulation operators work with that non-C++
compiler.

But you wouldn't, IMO, change the C++ standard to accommodate it. The
standard already excludes non-binary computers, so it's inapplicable. IMO.

On Sat, Mar 6, 2021 at 3:58 PM Vishal Oza via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> The base of this idea is to add an undefined behavior clause if one writes
> C++ using bit manipulation in a target machine that does not use binary
> arithmetic in its arithmetic model. The bits value would represent a digit
> in the numbering system or a q-bit if the system is a quantum computing
> system. The best example I can think of is to have an arithmetic unit that
> has base 10 as its numbering system. We still have types like int, long,
> short, long long, unsigned int, unsigned long, unsigned short, unsigned
> long long, float and double as well as value defined in cstdint but the
> uint8_t would have value that range from 0 to 99999999 while on normal
> hardware it would range from 0 to 255. endian would be useful regardless of
> base as it would describe how the processor deals with multi-length words.
> I am not sure if bit-shifting should be defined or not but if it is then
> the bit shift sure work with the hardware base and not assume base-2.
>
> On Sat, Mar 6, 2021 at 4:00 PM Thiago Macieira via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> On Saturday, 6 March 2021 11:34:36 PST Jason McKesson via Std-Discussion
>> wrote:
>> > This is the wrong mailing list for "should this be a proposal" type
>> > things. You're looking for the "std-proposals" list.
>> >
>> > That being said, considering what I said above, you need an
>> > explanation for why hardware that is base 6 can't implement the
>> > standard as is.
>>
>> In other words, you may want to make the hardware first, which will lead
>> you
>> to think about how much existing software you want to run on it and how
>> much
>> to leave out.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DPG Cloud Engineering
>>
>>
>>
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>