Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-11-30 18:20:03
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.)
In fact in most cases the best hash is the fastest one, not the most
> 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.
>>> optional<T> is Regular if T if Regular. The more that optional<T>
>>> "just works" like int works, the better. Particularly for generic
>> The first part sounds like a definition I am unfamiliar with.
> Regular is a concept. See Stepanov's Elements of Programming. Or just
> think "int". ie assignable, copyable, copies are disjoint, etc.
> Stepanov includes ordering as part of Regular (IIRC).
Thank you for the clarification. I agree that this is a desirable
property for "value-like" types, which includes optionals and variants.
I don't agree that ordering should be included in that set, however
(but equality should).
Structures, for example, should ideally be
assignable/copyable/equality-testable etc and be treated value-like in
the same way. But most of the time defining an ordering for a structure
The same is true for variant; I don't think it makes sense to compare a
variant that holds type #4 with one that holds type #7 and somehow
declare that the first is less based just on the types.
Optional is more borderline. I don't really have a problem with
comparing two optionals, or even the default "none is less than
anything" relation. But when you start mixing comparisons with
implicitly-promoted-non-optionals you increase the risk of unintended
bugs (eg. opt < 5 is true but the intended comparison was opt && *opt <
5, which is false).