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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Felix Uhl (felix.uhl_at_[hidden])
Date: 2014-11-26 10:54:08

David Stone wrote:

>I have been bitten in the past by operator<. I was converting code that
>used unsigned with a 'magic value' to represent nullness to
>boost::optional<std::uint32_t>. However, the maximum value it used was
>std::numeric_limits<std::uint32_t>:max(). A simple find and replace for
>this magic constant (which was referred to everywhere as DWORD_NULL) with
>boost::none and fixing compile errors led to some erroneous code. We had
>code that assumed an 'uninitialized' std::uint32_t was greater than any
>valid value.

>The concept of "value not present" is not inherently less-than or
>greater-than any value, but because of operator<, code compiled that
>shouldn't have. I suppose this is really an argument against any operator<
>overload, not just the mixed-type comparison. I don't expect this to be a
>major problem for new code, but there is a lot of code out there that uses
>a magic value, and that is what optional is supposed to replace.




I was irritated by it at first, too, and if you think about it the comparison brakes

down to a philosophical problem:


If I have a pair of pants and you don’t, are my pants smaller than yours?


Hard to say, but to me the most logical solution is “no”.

My pants aren’t smaller than yours, and my pants aren’t larger than yours.


Also, your and my logic would apply to both the operator<(optional<T>, T)

and operator<(optional<T>, optional<T>), but I think we’re only talking about

the latter.


---

Felix Uhl