Boost logo

Boost :

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-12-06 09:22:00


6 décembre 2024 à 09:31 "Alexander Grund via Boost" a écrit:

> > 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
> >
> As far as I understood this is exactly how the library is implemented:
> It is not `boost::hash2::update( h, span )` but
> `boost::hash2::hash_append( h, {}, span )` but thats minor.

I have a different understanding.

Quoting the doc, “This library addresses two major use cases: hashing
an untyped sequence of bytes, and hashing C++ objects.”.

But for the former, the library relies on the user to directly call the
hasher object update function. This is the part i don't feel comfortable,
with, i think a hasher completly opaque for the user of the library would
be a better design. That's just a minor change in term of implementation.

> So this discussion is only on which "concept that hashers must use".

I believe part of the discussion is also a misunderstanding on what the public
api is. It seems we don't all have the same opinion on this. Mine is that update
is also part of the public api, not only hash_append. This public api needs to
be at least compatible with modern / safe paradigms.

This is not necessarily

> Related to the above: Isn't the user-facing API the `hash_append`
> function and this update method is part of the concept for hash algorithms?
> And `hash_append` can massage the input into whatever that concept requires.

If i understand correctly:

std::span<char> v("123", 3)

hash_append(h, v); // hash "123" + the size 3, as v is a container
h.update(v); // hash only "123".

Or did i miss something?

Regards,

Julien


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk