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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Olaf van der Spek (ml_at_[hidden])
Date: 2014-12-02 08:10:28

On Mon, Dec 1, 2014 at 8:44 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> Not vector. I was referring to set and map, whose use frequently doesn't

Just two? That's not what I'd call many datastructures.

> depend on what the ordering actually is, but often only that there simply
> is an ordering. While on the topic though, the standard containers such as
> std::vector /do/ use std::less for their operator< (even though the
> requirements of the operation are [inconsistently] specified on the value
> type's operator< rather than their default ordering function). This was

I'm not sure what you're saying.
Requirements specify operator< but they're using std::less? I'm confused.

> I think I'm still thinking about operator<
>> Other then map, do you have a reference for all these algorithms etc
>> that would benefit from less<optional<>>?
>>
>
> Any algorithm that takes a comparator and has a default (there are plenty
> in the standard library). This is no different from the set and map cases
> where you often don't care about the specific order, but rather, only that
> an order exists. Depending on your specific use, this can be true with
> respect to algorithms such as std::sort and std::binary_search, for example.

True

>> lack of a default comparator for the types in question has already led to
>> > the recommendation of preferring entirely different associative
>> > datastructures over passing in an explicit comparator in this very thread
>> > (ironically, the other containers that were recommended also depend on a
>> > subjective default, only it's the default hashing function instead of the
>> > default ordering function).
>>
>> How is the hash function subjective w.r.t. semantics?
>
>
> Not all hash functions are created equal and there are reasons to
> explicitly specify one as opposed to using the default, just as there are
> reasons to explicitly specify an ordering function.

True, but not an answer to the question.

>
>> > You should not be afraid to have your types be ordered when they can be
>> > ordered. Most decisions in development have a subjective aspect to them
>> and
>> > precisely which default ordering comparator you provide is just one of
>> > those many decisions. The fact that a default is subjective (and it
>> always
>> > is, even for arithmetic types), does not mean that a default is not
>> useful.
>> > Why do we use less as a default for arithmetic types with respect to a
>> set?
>> > Wouldn't greater be just as sensible?
>>
>> No, IMO, though for a lot of uses it probably wouldn't matter.
>>
>
> Why no? Why is "less" as a default objectively better than "greater" as a
> default?

Because in the majority of cases people order stuff in ascending order.

> It's simply not, we just use it by convention. The same is true
> for why we frequently define other operators in terms of operator<. We
> could just as easily have decided that operator> was the "base" operation
> to be used as a default and around which we built other operators. < is
> nothing special and not intrinsically better. I understand that you
> personally intuitively like < best, but you're only kidding yourself if you
> think that there is something deeper.

True, operator> could've been used. But then default order would
probably still have been ascending..

-- 
Olaf