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

On Tue, Dec 2, 2014 at 5:10 AM, Olaf van der Spek wrote:

On Mon, Dec 1, 2014 at 8:44 PM, Matt Calabrese 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.

Well, technically 4 (multi-versions), but keep in mind that that is 100% of the ordered datastructures. This is also just in the standard. Other library developers can and do use std::less appropriately.

...

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.

Yes, that is what I'm saying. In the C++ standard, when library components are specified, it describes concept requirements and contracts on types and functions involved. Sometimes it goes further and specifies more specific implementation details. In the case of the comparison operators, the standard states that the requirements are that operator< of the value type of the container must be defined and that it forms a total order. However, when it specifies what the operators should do, that specification is in terms of std::lexicographical_compare, using the default ordering (std::less). These two specifications do not match as std::less and operator< do not necessarily relate (they differ with respect to certain fundamental types and library components, not to mention that they can differ in user code). Either the requirements or the implementation are incorrectly specified. My jab regarding concepts was that the (good) C++0x concepts proposal could have potentially caught this kind of mistake when a vendor implemented the library because the definitions would have been constrained. However, this type of checking is not a part of concepts-lite and its design essentially precludes that checking from getting there in future revisions. Concepts-lite deems that kind of checking "unimportant" even though the standard could have benefited from the feature (not to mention other library developers).

...

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.

I'm not sure what you mean with respect to semantics in this context. Regarding ordering, the semantics that matter don't differ either.

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.

First, I'm not even sure that that's true and you certainly do not either (beyond that, it could be entirely incidental). Even if that were true, it also has no bearing on the discussion. It could be 99% of the time and that would make no difference. -- -Matt Calabrese