On Mon, 11 Nov 2024 at 07:27, Mykola Garkusha via Std-Discussion <
std-discussion_at_[hidden]> wrote:

>
> On Sun, Nov 10, 2024 at 11:17 PM Thiago Macieira via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>> Std-Discussion wrote:
>> > Say one could ensure padding bits set to 0 on creation or during
>> > the lifetime of an object and later compare the object with *memcmp
>> *knowing
>> > ahead that the object value does not change and even it does one could
>> > again reset padding bits to 0 to use *memcmp*
>> Are you trying to type-erase a comparison operation?
>> Because if not, just do a regular operator== comparison over the range of
>> items and the compiler will emit the memcmp() calls for you if the type
>> is
>> trivially comparable.
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel DCAI Platform & System Engineering
>>
>> Just want to make padding bits stable and don't change *between *subsequent
> *value *modifications so that memcmp actually works.
>

I do not think it helps. Here is why.

Say, you have a struct A a, and you then copy it to b using memcpy, your
proposition seems to be that you can use memcmp on a and b, which might be
more efficient.

The problem is that unless the standard also required copy-construction and
copy-assignment to copy the padding bytes, using memcmp would be dangerous.
Suppose you have A c = a;, usually you just cannot memcmp on a and c for
equality comparison.

Yongwei