Re: [hash2][review] Early review (due to holidays)

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-12-05 13:05:27

On 12/5/24 15:27, Alexander Grund via Boost wrote:
>> And I don't want to force hash algorithm authors to have to include
>> <boost/hash2/span.hpp>, because this would mean a physical dependency
>> on Hash2. At the moment, you can define a hash algorithm without
>> including
>> anything from Hash2, or anything from Boost. And that's how it has to be.
> But you are currently defining the interface of the hash algorithms:
> Â Â Â  constexpr void update( unsigned char const* data, std::size_t n );
> My proposal is to define it as e.g.
> Â Â Â  constexpr void update(span<unsigned char const>);
> 
> I.e. to go range-safe from the start.
> That would not depend on the hash library but on the chosen span
> library, which might be more acceptable.
> However in C++11/14 this would require the Boost span, so I guess this
> is also off the table, unless the interface would be required to support
> span-likes
> which could be done by users via templates and not require a specific
> span implementation.
> 
> But even with the current interface of "potentially unsafe" hash
> algorithms the `hash_append` could be written to accept only spans/ranges.
> The proposed `hash2::span` would then only appear in the interface of
> the library, i.e. `hash_append`
> 
> My thinking is: If this is intended to push N3980 forward for inclusion
> in a future standard then I'd expect it to not use the "old-style"
> pointer+size-pairs but std::span readily available in the targeted
> standard.

What is the practical advantage of using span (of any provider) over the
traditional pointer+size? I emphasize the "practical" part, as opposed
to any personal preference to "modern-ness", code style or anything like
that.

I'm asking because in my practice I often don't see the point in wrapper
classes such as span<uint8_t> and iterator_range<uint8_t*> because the
original data is often received as a pointer+size pair (or a pair of
pointers) and then consumed through a pointer+size - either by my own
code or by a third party code, such as an external library, which is
often a C library. A wrapper class is useful for storing as a data
member in a class for associating the pointer and the size, but as far
as passing the range around is concerned, I don't see much point.

I do agree with Peter that not having to depend on Boost.Hash2 to be
able to define hash functions and adding support for hashing to user's
types is an important advantage.