Date: Mon, 11 Nov 2024 23:19:09 +0100
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.
> * type-erased comparison
Why? And for which subset of types are you suggesting
this should work?
> * quicker comparison using memcmp rather then operator== especially if there are many padding holes in the object.
Do you have measurements supporting that claim?
> 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
> -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
>
> 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.
> * type-erased comparison
Why? And for which subset of types are you suggesting
this should work?
> * quicker comparison using memcmp rather then operator== especially if there are many padding holes in the object.
Do you have measurements supporting that claim?
> 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
> -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
>
Received on 2024-11-11 22:19:15