Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-03 01:56:41


Ivan Matek wrote:
> Thank you for the answers.
>
>
> On Tue, Dec 3, 2024 at 1:54 AM Peter Dimov <pdimov_at_[hidden]
> <mailto:pdimov_at_[hidden]> > wrote:
>
>
>
> Either way, N3980 is what I liked best, so that's what I based the library
> on.
>
>
>
> Regarding design:
> I noticed all hash_append* functions take flavor so users often have to write
> {} argument .
>
> Do you think there would be some benefit for easy use helper, e.g. to have
> something like this from example
> boost::hash2::fnv1a_32 h1;
> int v1[4] = { 1, 2, 3, 4 };
> boost::hash2::hash_append( h1, {}, v1 ); writable also as
>
>
> boost::hash2::simple_hash<fnv1a_32> h1;
> int v1[4] = { 1, 2, 3, 4 };
> h1.append( h1, v1 ); // shorter fn name, no {}, simple_hash flavor is always
> default flavor

I don't think the {} is a burden, because you generally only write it once or twice
at top level. In the tag_invoke methods you need to pass the flavor downstream.

Providing an easy way to omit the flavor also encourages the mistake of
forgetting to pass it.

I don't see anything particularly wrong with the simple_hash adaptor, but I also
don't think it will save that much typing either. If you find yourself invoking
hash_append with {} repeatedly, something is probably not right.

The examples in the documentation that do it are illustrative, real code doesn't
need to do that.

E.g. you never do this

    boost::hash2::hash_append( h2, {}, get<0>(v1) );
    boost::hash2::hash_append( h2, {}, get<1>(v1) );
    boost::hash2::hash_append( h2, {}, get<2>(v1) );

You just invoke hash_append once, with v1.

And you never do this

    boost::hash2::hash_append( h, {}, v.x );
    boost::hash2::hash_append( h, {}, v.y );
    boost::hash2::hash_append( h, {}, v.z );

You do this instead

    boost::hash2::hash_append( h, f, v.x );
    boost::hash2::hash_append( h, f, v.y );
    boost::hash2::hash_append( h, f, v.z );

where f is your flavor argument.


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