Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

On 2/12/2014 07:45, Gottlob Frege wrote:

On Sun, Nov 30, 2014 at 6:20 PM, Gavin Lambert wrote:

...

On 29/11/2014 08:01, Gottlob Frege wrote:

...

There are still reasons to use std::map over unordered_map. Lack of a cryptographically safe hash is one of them. There are others (that I've forgotten, but I've asked the same question to committee members before, and there were a few reasons that sounded valid to me.)

Why should the lack of a cryptographically safe hash matter when you are not doing cryptography?

It doesn't really matter what hash is used in internal data structures. (Although obviously there are desirable properties such as having uniform spread to minimise bucket collisions and improve lookup speed.)

Denial of Service attack - I carefully force the input data such that the hashes collide and you get worse-case hash-table performance. This is a real attack. Python and a few other languages have already fixed their hashes, we have not.

So that still doesn't apply to every app, but it applies to more than you might expect.

Perhaps I'm just being naive, but I would think that there'd be more non-internet-facing apps than internet-facing ones (or at least the probability of any given application facing attack is fairly slim, apart from the really popularly installed ones), so most applications would prefer high-performance defaults over "secure" ones. Though I fully agree that it'd be nice to have a secure hash as an option, I don't see why eg. std::hash (or any smaller type) doesn't just return the bitwise equivalent of the original value by default, as this has zero collision probability and the highest performance.