On 11/11/2024 23.08, Mykola Garkusha wrote:
> Thanks all. It became more clear especially regarding the C standard. Having said that, would it not help having ability to at least clear padding bits intead and reads to get the same value in the absense of writes? Particularly GCC and Clang already offer intrinsics for that and then one could have optimizations.
> * object could be treated as null by having all of its bits (including paddings) set to 0
All bits being zero is not equivalent to zero initialization.
In popular ABIs, pointers-to-members are an example.
Was not fully clear on this - the idea is that the application would have its own meaning based on all bits 0 and the set of types it operations on
> * type-erased comparison
Why? And for which subset of types are you suggesting
this should work?
purely theoretical speculation, indeed don't have any practical example at hand.
> * quicker comparison using memcmp rather then operator== especially if there are many padding holes in the object.
Do you have measurements supporting that claim?
Not at hand, but may get data points. That is a good point actually.
> Indeed clearing padding bits may interfere with other optimizations,
Indeed.
> though the programmer would have an option to use this feature or not .
How so? Guaranteeing the stability of padding bits is what
inhibits the optimization, and you need that guarantee to achieve
your presumed "optimizations".
Jens
The point is that if padding bits are cleared then only stability would be guaranteed, otherwise if it was not explicitly cleared we'd be back to the default behaviour as of now. Ofc it is based on assumption that perceived optimizations would be material.
> -Mykola
>
> On Mon, Nov 11, 2024 at 7:44 AM Jens Maurer <jens.maurer@gmx.net <mailto:jens.maurer@gmx.net>> wrote:
>
>
>
> On 11/11/2024 05.44, Thiago Macieira via Std-Discussion wrote:
> > On Sunday 10 November 2024 15:27:43 Pacific Standard Time Mykola Garkusha
> > wrote:
> >> Just want to make padding bits stable and don't change between subsequent
> >> value modifications so that memcmp actually works.
> >
> > But you need to have a motivation for that. You need to explain why you want
> > to memcmp in the first place instead of using operator== or operator<=>.
>
> In particular since we nowadays have defaulted operator== for memberwise
> comparison, so the syntax burden on the user is near zero.
>
> Jens
>