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@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.
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