On Monday 11 November 2024 14:40:14 Pacific Standard Time Mykola Garkusha
wrote:
> 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

It cannot. By definition of the language, those bits are inaccessible. You
can't read them, you can't write to them, and you can't rely on any particular
value. Therefore, any class that depends on the padding bits assuming a
particular value is, by definition today, ill-formed.

We get to a circular reasoning here, though. How about the class simply be
designed without padding bits? It isn't very difficult, just use a single
integer type and be done with it.

> > > * 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.

Compilers emit call to memcmp when they know that memcmp can be used, because
all bits contain meaning. So we get back to circular reasoning and some QoI.
If the implementation guarantees a stable bit value, then it can implement the
trivial operator== and operator<=> with memcmp.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering