On Mon, Nov 11, 2024 at 10:19 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:

>
>
> 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_at_[hidden]
> <mailto:jens.maurer_at_[hidden]>> 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
> >
>
>