|
Boost : |
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-12-06 08:31:40
>>> 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
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.
So this discussion is only on which "concept that hashers must use".
> If you mean this
>
> template<class T> void update( std::span<T> sp );
>
> then the reason to not use it is that you can't pass things like `string` and
> `vector<unsigned char>` and `char[65536]` directly because deduction will
> not work.
>
> I'm not particularly fond of the user-facing syntax being
>
> hash.update( std::span{buffer} );
>
> instead of
>
> hash.update( buffer );
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.
Given that I kind see that point why void*-size is acceptable, except
for the new warning/safety-guidline against such pairs.
If that should be adhered too (note that I no longer lean strongly
either way) the interface could be defined using a SpanConcept:
`void update(SpanConcept)` where `concept SpanConcept = requires(T t) {
t.data(); t.size(); }` (Use of C++20 syntax only for illustration)
So implementers are not required to support a particular span but to
accept any span-like that `hash_append` passes to it.
However I see the shortcoming that this would possibly exclude
`template<typename T> void update(std::span<T>)`
because `hash_append` might use `boost::span` which isn't(?) convertible
to std::span (or whatever span type the hash algorithm accepts).
So hash-algorithms need to use `template<class T> void update(T
data_span)` exclusively, which isn't great either.
--> void*-size is likely the most flexible and least burden for hash
algorithm authors.
If there is the way to silence the compiler warning in a reasonable way
I don't see a reason against it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk