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
>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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk