Le jeudi 05 décembre 2024 à 12:06 -0800, Vinnie Falco via Boost a écrit :
On Thu, Dec 5, 2024 at 5:11 AM Joaquín M López Muñoz via Boost < boost@lists.boost.org> wrote:
You can define the interface of update as accepting a templatized arg with span-like semantics.
This could work. Instead of writing:
h.update( span );
You instead write:
boost::hash2::update( h, span );
+1 on this approach. The proposed library currently consists of two things : * a concept that hashers must use (for hash implementors) * an hash_append helper to ease the use of hash functions with objects I think it should evolve into something more like : * a concept that hashers must use * a public api for hash users This means that for the library user, the hash object would basically be an opaque type, only accessed through calls like boost::hash2::hash_append(h, X) or boost::hash2::update(h, Y). The public api can then use a set of overloads for Y to anything we want to support (the multiple needed span<X>, a pair of pointers, a pointer + a size, etc.). That burden is left out of hash implementors.
The signatures for update can be conditionally compiled based on C++ version, availability of boost::span, or it could be a function template based on a span-like concept.
+1
Hasher's update signature would remain as (void const*, std::size_t ).
Or, hasher's signature can be selected through a set of supported ones. I'm not convinced by the ”hash writer shall not depend on boost::hash2” argument, but if that really matters then it's technically doable without forcing the use of the pointer + size pair for hash implementors. Regards, Julien