On Sun, Mar 7, 2021 at 1:59 PM Andrey Semashev via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On 3/7/21 8:09 PM, Lénárd Szolnoki via Std-Discussion wrote:
> > On Sun, 07 Mar 2021 18:52:26 +0300
> > Andrey Semashev via Std-Discussion <std-discussion_at_[hidden]>
> > wrote:
> >
> >> On March 7, 2021 6:26:41 PM Jason McKesson via Std-Discussion
> >> <std-discussion_at_[hidden]> wrote:
> >>
> >>> On Sun, Mar 7, 2021 at 4:14 AM Andrey Semashev via Std-Discussion
> >>> <std-discussion_at_[hidden]> wrote:
> >>>>
> >>>> On 3/6/21 10:34 PM, Jason McKesson via Std-Discussion wrote:
> >>>>> On Sat, Mar 6, 2021 at 12:55 PM Vishal Oza via Std-Discussion
> >>>>> <std-discussion_at_[hidden]> wrote:
> >>>>>>
> >>>>>> I was thinking of making the bit and bitset libraries as well
> >>>>>> bit manipulation operators with the exception of endian and
> >>>>>> possibly left and right bitshift to undefined behavior if the
> >>>>>> base is not 2 in hardware.
> >>>>>
> >>>>> Um, what exactly does that mean?
> >>>>>
> >>>>> Here's what I mean. If you have the number 15, and you do a
> >>>>> binary-left-shift it by 2, the number you get is 30. It *does not
> >>>>> matter* how the hardware implements this. So long as `30 == 15 <<
> >>>>> 2` is true, the implementation is doing its job.
> >>>>>
> >>>>> Similarly, if you have the number 15, and you do a bitwise-and
> >>>>> with 2, you get the number 13. Again, how the hardware does this
> >>>>> is irrelevant; the implementation's job is to make the math work
> >>>>> out.
> >>>>
> >>>> Bit manipulation operators affect bit representation of a number,
> >>>> the resulting value is a consequence of that. In that sense,
> >>>> before we mandated two's complement representation, applying bit
> >>>> operators to signed integers would yield implementation-dependent
> >>>> numbers, although the effect on bit representation (with some
> >>>> restrictions) was well defined.
> >>>
> >>> Bitwise operations on signed integers, pre-twos complement, were
> >>> defined so long as the source integers were positive and the
> >>> resulting value could be stored in a signed integer of that type.
> >>>
> >>> Also, don't forget that a specification describes behavior, not
> >>> implementation.
> >>
> >> Sure, my point is that the specification describes behavior in terms
> >> of bit representation. The effect on the value is the consequence.
> >>
> >> You could rewrite the spec to define behavior in terms of integer
> >> values, but that would be useless for the binary world, and it's not
> >> clear how useful that would be for platforms of different bases.
> >>
> >
> > The standard already describes behavior in terms of values, not bit
> > representation. Value representation of integers are not even specified
> > outside of intN_t/uintN_t, so it can't be specified based on that.
> >
> > http://eel.is/c++draft/expr.shift#2
> >
> > http://eel.is/c++draft/expr.shift#3
>
> The notes in both these sections speak in terms of bit representation.
> Granted, notes are not normative.
>
> For bitwise operators the standard speaks in terms of bits:
>
> http://eel.is/c++draft/expr.bit.and
> http://eel.is/c++draft/expr.xor
> http://eel.is/c++draft/expr.or

Notice how the standard describes it though:

> the base-2 representation of the converted operands

Any number can be represented in base 2. So while the description uses
the base 2 representation of the number, what matters is what number
you get in the end. It does not require that the implementation
actually be in base 2.

And that's the main issue with the OP's suggestion. The OP is
basically saying, "we should make it possible to implement C++ on
systems that aren't base 2, and to do that, we need to make all of the
bitwise operations optional". And what I'm saying is the C++ standard
does not require that the system implementing C++ be base 2. Any
bitwise operations can be implemented however the implementation wants
so long as it comes up with the right answers. So nothing needs to
change to implement C++ on non-base 2 machines.