Re: [Bloom] Some questions

From: Ivan Matek (libbooze_at_[hidden])
Date: 2025-05-18 12:42:21

Thank you for the answers, here are some quick clarifications, will read
more/think more about "complex" topics later...

On Sun, May 18, 2025 at 11:56 AM Joaquin M López Muñoz via Boost <
boost_at_[hidden]> wrote:

>
> What's that fast avalanching hash you refer to?
>

I meant hash that is fast(i.e. computation is very fast) and is
avalanching. I presume for bloom filters that is what people might find
most interesting.
But I could be wrong, e.g. maybe best hash to use for integers is identity,
and then let bloom library do the extra hashing.

> >     3. libs/unordered/include/boost/unordered/detail/mulx.hpp contains
> mulx
> >     implementation that seems very similar to one used in bloom, and
> authors
> >     are same. Although this is tiny duplication, would it be best to
> extract it
> >     somewhere to avoid duplication?
> The only place I can think of is Boost.Core, and I'm not sure this very
> specific
> code really belongs there as a public utility.
>

Maybe unordered could expose it as public functionality? Not super clean,
but avoids duplication.
tbh IDK what is best practice here..Or maybe move it to ContainerHash as it
seems both libs depend on it.

> >     9. My IDE complains about redundant inline on member functions. Is
> this
> >     intentionally done since (afaik msvc) some compilers use inline as
> >     optimization(inlining) hint or?
> Can you provide the full warning messages you're getting and for which
> environment this is happening? BOOST_FORCEINLINE is used quite liberally to
> nudge Visual Studio, which is otherwise notoriously lazy at inlining.
>

Warning is about literal inline keyword, not BOOST_FORCEINLINE. I presume
reason is because member functions are implicitly inline(I never understood
why they are treated differently from free functions, but that is
different story...).