From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2025-05-18 15:59:20
El 18/05/2025 a las 14:42, Ivan Matek escribió:
> 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.
Yes, I think this is good enough, plus it's what say Boost.Unordered
uses to good effect. There are much higher quality hash functions in
Boost.Hash2, but I'd say that quality is worth the extra computational
cost when dealing with cryptographic secutity, not just for purposes
of avalanching (Peter Dimov and Chris Mazakas can correct me
otherwise).
> >Â Â Â 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.
I don't know, looks to me ugly and potentially confusing to users,
who have no real use for that.
In fact, there's another piece of functionality that I'd rather have
migrated to ContainerHash, namely the is_avalanching trait. Currently
this lives in Boost.Unordered, which forces Boost.Bloom to depend on it
for no other reason than to access this almost trivial utility --not ideal,
obviously.
> >Â Â Â 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...).
Can you please post here the entire warning message so that I can
locate the offending line, plus the environment (compiler and version)
you're using? Thank you!
Joaquin M Lopez Munoz