Boost logo

Boost :

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-12-02 15:44:10

On 2 Dec 2014 at 20:27, Stephan T. Lavavej wrote:

> [Niall Douglas]
> > BTW I think MSVC/Dinkumware *has* fixed their std::hash<>, theirs is
> > several orders of magntitude more complex than the trivial hash
> > libstdc++ uses. Indeed this leads to MSVC's apparent poor
> > unordered_map performance when compared to GCC (about a 12-40%
> > performance loss).
> > Stephan can probably confirm or refute this claim of MSVC/Dinkumware
> > having a safe hash though. It may just be he uses a well distributed
> > hash instead of a trivial hash, not one cryptographically safe.
> VC currently uses FNV-1a for everything. This is good at jumbling up
> bits, and pretty fast (although not as fast as returning an integer
> unchanged), but it is absolutely not cryptographically secure, nor does
> it attempt to resist collisions triggered by an intelligent adversary.
> We reserve the right to change our hash implementation in the future.

Thanks for the confirm Stephan.

Out of curiosity I went and looked up what Python did to solve this
(here's the discussion: In the
end, they simply XOR salted the hash with a cryptographically
generated random number produced at process launch (source:
and carried on with their previous algorithm.

I think std::hash could be similarly adjusted with ease, the hard
part is generating a cryptographically secure random number. I don't
believe C++ 11 even has such a secure generator in <random> even ...
nevertheless, the C++1z standard might consider adding a static
function to the STL which sets the std::hash salt value to something.
It might be an idea to only permit that function to be called exactly


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at