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
, 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