+1 👏👏👏

That says it all.

I'd suggest the OP familiarize himself to the intent of C++. That would be a good start in learning any programing language to understand the intent and design decisions that shape the said language. Only then you could understand what people intend to mean in their answers. Never try to understand a language using the semantics of another one (this also applies when learning a new natural language).

There are good resources to immerse yourself into C++ ideology. Start with CppCoreGuidelines, watch CppCon on YouTube. Beware of bad, poor style, unsafe/inefficient, outdated teaching material on C++: there is huge amount of it.


On July 31, 2025 2:13:28 p.m. EDT, connor horman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>It's moot what assembly defines as a pointer. You aren't writing in
>assembly, or even portable assembly. You are writing in C or C++ (or some
>other relatively high-level language). They have a different definition of
>pointer arithmetic, because it suits them to do so. You aren't writing C++
>code for an x86 CPU, for but an Abstract Machine that happens to be
>partially emulated by an x86_64 CPU, after being translated by a compiler.
>The AM decides what defined behaviour each operation has, or even if there
>is no defined behaviour. The compiler then is responsible for translating
>only the observable results of at least one execution of a given program,
>if all have defined behaviour, and has no responsibility to correctly
>translate any program that the AM decides does has a valid execution for a
>given input that results in undefined behaviour, other than what behaviour
>arises prior to an observable checkpoint. [intro.abstract]#6.
>Any proposal to change C++ approaches the standard from the perspective of
>the standard. If your compiler cooperates, you may decide to write program
>in a language syntactically equivalent to C++ that has direct semantic
>correspondence with your underlying machine, but this is contingent on your
>compiler, and the C++ Standards Committee does not concern itself with the
>behaviour of this programming language. Nor likely does your compiler, and
>the correspondance is merely happenstance of its largely correct
>implementation of C++.
>
>On Thu, 31 Jul 2025 at 14:01, zxuiji via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>> You can't just redfine the meaning of a pointer, asm defined it years ago
>> and C etc just have to follow on, and asm defined it to have arithmetic so
>> arithmetic it shall, *always*. If a vendor decides to make the add
>> instruction throw an exception then the CPU is already dead in the water
>> because no gamer will want it, no business will need it for their server
>> more than one that allows it, there is literally no value to disabling
>> pointer arithmetic and only cons.
>>
>> On Thu, 31 Jul 2025 at 18:40, Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On 31 Jul 2025 20:29, zxuiji via Std-Proposals wrote:
>>> > nullptr MUST hold a value, not matter if that value is valid or not,
>>> > therefore it will ALWAYS have pointer arithmetic available. It is utter
>>> > insanity to say a pointer might not have pointer arithmetic.
>>>
>>> nullptr might be a trap value, so applying any sort of math to it (or
>>> dereference it) would cause a hardware fault.
>>>
>>> PS: Cheetos crust, I can't believe this thread is still going..
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>