Confronti firmati / non firmati

Sto cercando di capire perché il seguente codice non emette un avviso nel punto indicato.

//from limits.h
#define UINT_MAX 0xffffffff /* maximum unsigned int value */
#define INT_MAX  2147483647 /* maximum (signed) int value */
            /* = 0x7fffffff */

int a = INT_MAX;
//_int64 a = INT_MAX; // makes all warnings go away
unsigned int b = UINT_MAX;
bool c = false;

if(a < b) // warning C4018: '<' : signed/unsigned mismatch
    c = true;
if(a > b) // warning C4018: '<' : signed/unsigned mismatch
    c = true;
if(a <= b) // warning C4018: '<' : signed/unsigned mismatch
    c = true;
if(a >= b) // warning C4018: '<' : signed/unsigned mismatch
    c = true;
if(a == b) // no warning <--- warning expected here
    c = true;
if(((unsigned int)a) == b) // no warning (as expected)
    c = true;
if(a == ((int)b)) // no warning (as expected)
    c = true;

Pensavo avesse a che fare con la promozione in background, ma gli ultimi due sembrano dire il contrario.

A mio avviso, il primo ==confronto è una mancata corrispondenza con segno / non firmato come gli altri?

Quando si confronta firmato con non firmato, il compilatore converte il valore firmato in unsigned. Per l'uguaglianza, questo non importa, -1 == (unsigned) -1. Per altri confronti è importante, ad esempio, il seguente è vera: -1 > 2U.

EDIT: Riferimenti:

5/9: (Espressioni)

Molti operatori binari che prevedono operandi di tipo aritmetico o di enumerazione causano conversioni e producono tipi di risultati in modo simile. Lo scopo è produrre un tipo comune, che è anche il tipo del risultato. Questo modello è chiamato le solite conversioni aritmetiche, che sono definite come segue:

• Se uno degli operandi è di tipo long double, l'altro deve essere convertito in long double.

• Altrimenti, se uno degli operandi è double, l'altro deve essere convertito in double.

• Altrimenti, se uno degli operandi è float, l'altro deve essere convertito in float.

• In caso contrario, le promozioni integrali (4.5) devono essere eseguite su entrambi gli operandi.54)

• Quindi, se uno degli operandi è lungo senza segno, l'altro deve essere convertito in lungo senza segno.

• Altrimenti, se un operando è un long int e l'altro unsigned int, allora se un long int può rappresentare tutti i valori di un unsigned int, il unsigned int deve essere convertito in un long int; altrimenti entrambi gli operandi devono essere convertiti in unsigned long int.

• Altrimenti, se uno degli operandi è lungo, l'altro deve essere convertito in lungo.

• Altrimenti, se uno degli operandi è senza segno, l'altro deve essere convertito in non firmato.

4.7 / 2: (Conversioni integrali)

Se il tipo di destinazione è senza segno, il valore risultante è il minimo intero senza segno congruente all'intero di origine (modulo 2 ⁿ dove n è il numero di bit utilizzati per rappresentare il tipo senza segno). [Nota: in una rappresentazione in complemento a due, questa conversione è concettuale e non vi è alcun cambiamento nello schema di bit (se non c'è troncamento). ]

EDIT2: livelli di avviso MSVC

Ciò di cui viene avvertito nei diversi livelli di avviso di MSVC sono, ovviamente, le scelte fatte dagli sviluppatori. Per come la vedo io, le loro scelte in relazione all'uguaglianza firmato / non firmato rispetto a confronti maggiori / minori hanno senso, questo è del tutto soggettivo ovviamente:

-1 == -1significa lo stesso di -1 == (unsigned) -1- lo trovo un risultato intuitivo.

-1 < 2 non significa lo stesso di -1 < (unsigned) 2- Questo è meno intuitivo a prima vista e IMO merita un avvertimento "anticipato".

Perché gli avvisi firmati / non firmati sono importanti e i programmatori devono prestare loro attenzione, è dimostrato dal seguente esempio.

Indovina l'output di questo codice?

#include <iostream>

int main() {
        int i = -1;
        unsigned int j = 1;
        if ( i < j ) 
            std::cout << " i is less than j";
        else
            std::cout << " i is greater than j";

        return 0;
}

Produzione:

i is greater than j

Sorpreso? Demo in linea: http://www.ideone.com/5iCxY

Bottomline: in confronto, se un operando è unsigned, allora l'altro operando viene convertito implicitamente unsigned se il suo tipo è firmato!

L'operatore == fa solo un confronto bit per bit (con una semplice divisione per vedere se è 0).

Il più piccolo / più grande dei confronti si basa molto di più sul segno del numero.

Esempio a 4 bit:

1111 = 15? o -1?

quindi se hai 1111 <0001 ... è ambiguo ...

ma se hai 1111 == 1111 ... È la stessa cosa anche se non volevi che fosse.

In un sistema che rappresenta i valori utilizzando 2 complementi (i processori più moderni) sono uguali anche nella loro forma binaria. Questo potrebbe essere il motivo per cui il compilatore non si lamenta di a == b .

E per me è strano che il compilatore non ti avverta su a == ((int) b) . Penso che dovrebbe darti un avviso di troncamento intero o qualcosa del genere.

La riga di codice in questione non genera un avviso C4018 perché Microsoft ha utilizzato un numero di avviso diverso (ad esempio C4389 ) per gestire tale caso e C4389 non è abilitato per impostazione predefinita (ad esempio a livello 3).

Da Microsoft docs per C4389:

// C4389.cpp
// compile with: /W4
#pragma warning(default: 4389)

int main()
{
   int a = 9;
   unsigned int b = 10;
   if (a == b)   // C4389
      return 0;
   else
      return 0;
};

Le altre risposte hanno spiegato abbastanza bene perché Microsoft potrebbe aver deciso di creare un caso speciale con l'operatore di uguaglianza, ma trovo che quelle risposte non siano molto utili senza menzionare C4389 o come abilitarlo in Visual Studio .

Dovrei anche menzionare che se hai intenzione di abilitare C4389, potresti anche considerare di abilitare C4388. Sfortunatamente non esiste una documentazione ufficiale per C4388 ma sembra apparire in espressioni come le seguenti:

int a = 9;
unsigned int b = 10;
bool equal = (a == b); // C4388