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@lists.boost.org> 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...).