On Wed, May 15, 2024 at 7:58 AM Jonathan Wakely wrote:
>
> Why would you want to hash the indeterminate padding
> bits between members anyway?
How about we add a new constexpr function to the standard library
called "std::zero_padding":
template<typename T> requires (!is_const_v< remove_reference_t<T> >)
constexpr T &&zero_padding(T &&obj, bool const skip_tail = false)
{
// Step 1: Zero out the padding bits inside integer types
// Step 2: Zero out the padding bytes between member variables
// Step 3: If 'skip_tail' is false, zero out the tail padding
// (must set to 'true' when used with 'no_unique_address')
}
With regard to Step 1, this is a throw back to the days when a 36-Bit
integer was a 32-Bit integer with 4 padding bits -- so probably
doesn't apply today.
The hash algorithm could hash "__datasizeof(T)" instead of
"sizeof(T)", which is why in the above function I give the option of
skipping the tail padding.
Why would you want the md5sum for tuple<int, char> to depend on the unspecified order of the two subobjects, and the unspecified number of padding bytes? Given a custom String type, why would you want the md5sum of
tuple<String, int> to hash the bits of the String, which is
probably a pointer value, instead of the characters in the string?
Why not just visit each of the members in a defined order, say get<0>(t) then get<1>(t), and hash each member? Wouldn't this be more sensible, more portable, and more useful for other hashing algorithms that also want to visit each member of a data structure?
Instead of inventing more complicated and less portable ways to access every object as a bag of bits, why not follow the actually useful and already existing practice of abseil and boost and others?