Boost logo

Boost :

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2024-12-06 17:23:04


I've been reading several comments on the list and I think a few different
things are being discussed concurrently so I'm hoping to clarify and address
them.

There are two interfaces: one for implementers, and one for users.

A goal for implementers is to not have to require any Hash2 headers for
their
algorithms to be used by the library.

For users, we want safe interfaces that always do the Right Thing.

hash_append is a proven interface for working with user-facing structures
and
solves the subtle and difficult problems it needs to, such as the "ab" | "c
and
"a" | "bc" case, as we've already discussed.

Unfortunately, hash_append isn't really suitable as a safe interface for
incremental hashing of byte streams, as we've noted that hash_append will
append a hash of the size once it's done.

update() works properly for hashing byte streams (as it must) but because
it's
intended as part of an implementation, it's not exactly suitable for most
end-users who just want to hash their 3 GB file. We could even go so far as
to
say that it is an "unsafe" interface.

So, we want safety.

Vinnie has already alluded to using a free function hash_update which will
accept a span. This is, as far as I can see, the best solution to the
problems
at hand.

With this, we can achieve our goals for both implementers and users because
the update interface doesn't have to change and then we can layer all the
type
safety externally to the free functions in a non-intrusive way.

- Christian


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