6 décembre 2024 à 11:15 "Andrey Semashev via Boost" a écrit:
A hasher must expose a common public interface anyway to be compatible with hash_append
This is stricter than what is actually required. hash_append can be made to work with hashers having a different interface, as long as they follow a concept known to hash_append / hash_update. This concept does not need to rely on types defined by boost::hash2, the dependency is the other way (boost::hash2 must include a specialization for the interface of the hasher).
, and at this point why not use the interface in the user types hash functions directly? What value a free hash_append function would bring? The only thing that comes to mind is it could have a more flexible interface, as Vinnie suggested, to keep the hasher interface minimal, but that's about it.
That is imho largely worth it. This also gives a lot more flexibility / room for evolution. There is an order of magnitude between the number of usages of the hashing api, and the number of hashers used in a project. Changing the hashing api means changing every call to hash_append (resp hash_update). Changing the hasher concept only means changing a few files. But, as i said before, you can even support multiple hasher concepts in hash_append / hash_update, so changing the hasher recommended api can be made while keeping old hasher api still working. Something that cannot be done if you talk directly to the hasher.
I do think though that whether or not a free hash_append function is provided, using the hasher directly through its public interface should be allowed.
I don't suggest to make changes to specifically forbid such use. Just that the nominal / advertised usage uses a thin wrapper (which, i believe, would be fully inlined and not result in additional runtime cost).
This would allow the user types' hash functions not depend on Boost.Hash2 and therefore
This is not required by what i suggest.
make support for hashing more lightweight
I expect the wrapper to incur no additional runtime cost (over manual conversions that would be done at call site instead).
and potentially compatible with std::hash2, if one ever comes to light.
I do not see how this is related. Actually, i think it's quite the opposite: by decoupling the user API from the hasher concept API, you should make it easier to integrate new standards / requirements on either side. Or i'm missing something obvious here. Regards, Julien