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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2014-12-01 13:45:00

On Sun, Nov 30, 2014 at 6:20 PM, Gavin Lambert <gavinl_at_[hidden]> 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.

> In fact in most cases the best hash is the fastest one, not the most secure
> one.
>
>> Basically, people still want complex (for example) as a key in
>> std::map. Maybe that is becoming rare enough that they can just pass
>> in an explicit comparison when needed, but not always easy in generic
>> code (more on that below).
>
>
> I still question whether these people *really* want this, or whether it's
> just because unordered_map is new and scary (or longer to type). Obviously I
> suspect the latter.
>

As I said,the hash was only one reason.  There were others, IIRC.  I
do agree that unordered_map will become more popular in the future, so
that the issue is lessened.  (Also, map should have been called
ordered_map, and unordered_map called 'map'...)

Tony