The compiler abstracts away a lot:

Even basic stuff like the stack, local automatic variables and function parameters location or the registers - be it general purpose or vector registers.

 

C++ always had rules in its abstract machine to construct and destruct objects or for accessing data.

 

 


 

-----Ursprüngliche Nachricht-----
Von: organicoman via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Di 28.01.2025 20:29
Betreff: Re: [std-proposals] Make all data pointers intercompatible
An: Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>;
CC: organicoman <organicoman@yahoo.fr>;
>> No, not "only". An implementation that e.g. >masks out the
>> least>significant bits of void* on conversion to T*, >according to
>> T's>alignment requirements, is possible. This will violate the strict
>> aliasing rule. And any type can alias any type.

>I don't see how that would violate the strict >aliasing rule, as it only
>concerns valid pointers. Pointers that do not >respect pointed object
>alignment are not valid.
 
As per your example, if you correct the alignment when converting from void* => T*, why not generalize it for all T* <=> U*, and eliminate the extra T*=>void* before going from void*=>U*.
 
>>> Another implementation that e.g.>modifies tag bits in the pointer according
>>> to T >(e.g. to distinguish>between pointed types in hardware to >improve
>>> security) is also possible.This is counter intuitive,  because you will get
>>> a page of unsecured memory with some cells tagged as secured, or the
>>> opposite which is worse.Manipulating bits of a pointer should be a
>>> programmer responsibility, not the implementation.

>A programmer does not have the standard >means to manipulate bits in a
>pointer representation while maintaining >pointer validity. Manipulating
>object (including pointer) representation is >the responsibility of the
>compiler.
 
The compiler gives you a general purpose fundamental type, and you can customize it to your liking.

>>> Can you point where this is specified in the >standard?In the definition of
>>> the pointer type itself as a fundamental type.

I don't see where.

>> a pointer as a type defines 5 operations:++ increment , -- decrement ,
>> +ptr_diff_t  add an offset, * dereference, (T*) castingNone manipulate bits.

>The list of supported operations on pointers >is irrelevant. This is just
>the model that the language provides to >users. It doesn't mean that an
>implementation can't manipulate bits of >pointer representation using any
>instructions it sees fit.
 
But that model reflects the underlying hardware. No need to abstract it away from the programmer. 



--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
 
 
Sent from my Galaxy
 
 
-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals