NOTE  (2016/03/26 01:30PM): The content of this post has has been fixed. I must thank Lawrence Crowl for pointing out my mistake at SG14 GDC 2016 meeting.

It is well known that using ordering comparison operators (<, <=, >, >=) with mixed signed/unsigned types result in warnings and, ultimately, in undefinedunexpected behaviour.

I never loved this, and I always tried to avoid it by using a simple trick, which apparently can be made into a definition that will make operators in mixed sign cases avoid undefined behaviour and have unsurprising semantics.

A simple function to convert from signed to unsigned is the key:

template<typename T> auto to_unsigned(T value) {
    return std::make_unsigned_t<T>(value);
}

This function alone could raise UB if we apply to a negative value, but all the positive signed values fit in the corresponding unsigned type, and the conversion maintain the value intact.

Now the various cases are actually straightforward, and are listed in the table below for the expression X <op> Y:

All the comparisons are now well defined (comparison against 0 are signed, comparison between the two operands are all unsigned).

For completeness, let’s also add the equality operators

So, what’s the problem? If it’s that simple, why nobody has standardised this yet?

I think the problem relies on equality comparison, which is defined oddly, and might result in confusion. Current wording for the standard is the following (taken from one of the latest C++14 drafts):

8. Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:
   • […]
   • Otherwise, the integral promotions (4.5) shall be performed on both operands.62 Then the following rules shall be applied to the promoted operands:
     • If both operands have the same type, no further conversion is needed.
     • Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank.
     • Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type.
     • Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type.
     • Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

Apparently, if conversion from signed to unsigned is deterministic, this gives the opportunity to assume that the following code will print “true”:

int s = -1;
unsigned int u = (unsigned int)s;  //* explicit conversion of a negative value to unsigned
if (s == u)                        //* implicit conversion of a negative value to unsigned
    cout << "true";
else
    cout << "false";

Someone already interpreted this code as correct, such as here. It is my opinion the two lines marked as //* will invoke undefined behaviour themselves (the second one because of the conversion, and not the comparison).

This actually holds also for inequalities, but the reasoning there is clearly wrong (because for normal humans the fact that in most platform (1u < -1) results in true doesn’t really make much sense).

From this point, it is also straightforward to design a set of rules for promotions in signed/unsigned comparison. Actually, by rewriting the operands as described in the tables above, all the comparisons between different types (short, int, long, …) become well-defined against existing rules (plus the assumption above).

Can we define a new type which behave correctly? Yes, but it must be noted that a change like this might break existing (but arguably wrong) code.

Acknowledgments:

J. W. Walker, Safer Comparison of Signed and Unsigned Integers in C++, 2013, May 6th (retrieved 2016, Mar 14th)

Update: I just read this from Denis Bider, posted few hours ago: apparently this is a hot topic today :)