2011-07-05 18 views
5

Considere el siguiente código:¿Por qué se implementa CompareTo en corto de esta manera?

namespace ConsoleApplication1 { 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      Console.WriteLine(100.CompareTo(200)); // prints -1 
      Console.WriteLine(((decimal)100).CompareTo((decimal)200)); // prints -1 
      Console.WriteLine(((short)100).CompareTo((short)200)); // prints -100 
      Console.WriteLine(((float)100).CompareTo((float)200)); // prints -1 
      Console.ReadKey(); 
     } 
    } 
} 

Mi pregunta es, ¿hay razones específicas del CompareTo método de Int16 devuelve valores distintos de -1, 0 y 1?

ILSpy muestra que se lleva a cabo de esta manera

public int CompareTo(short value) 
{ 
    return (int)(this - value); 
} 

mientras que el método se implented en Int32 esta manera

public int CompareTo(int value) 
{ 
    if (this < value) 
    { 
     return -1; 
    } 
    if (this > value) 
    { 
     return 1; 
    } 
    return 0; 
} 

Respuesta

13

La diferencia es que para short, no hay posibilidad de que el resultado desbordante. Por ejemplo, short.MinValue - (short) 1 sigue siendo negativo, mientras que int.MinValue - 1 es int.MaxValue.

En otras palabras, la razón específica es que puede salirse con un atajo con short (sin juego de palabras) mientras que el mismo atajo no funciona con int. Definitivamente no debe requerirIComparable<T>.CompareTo implementaciones para devolver -1, 0 o 1. La documentación es bastante clara que el resultado solo es significativo en términos de ser negativo, cero o positivo.

+1

Gracias por su respuesta. No pensé en el problema del desbordamiento. Desafortunadamente, tengo que mantener una aplicación heredada que contiene una gran cantidad de código suponiendo que CompareTo devuelve siempre -1, 0 o 1 ... – sloth

+1

@dkson: sugiero que corrija el código heredado. Ese tipo de suposición simplemente seguirá mordiéndote hasta que finalmente lo arregles. Mejor hacerlo más pronto que tarde, y educar a los desarrolladores originales, si todavía están por ahí ... –

5

Bueno, usted debe realmente sólo comprobar el signo todos modos, pero por razones: Creo que para int etc habría un riesgo de desbordamiento/envoltura (manipulación de 2 números de gran magnitud) que invertir el signo, lo que significa debe verificar los operadores.

Prefiero que sea consistente, pero no parece ser un problema. Más probablemente una optimización que es atípica pero dentro de la API documentada. En particular, la optimización de short aquí no se siente como que va a conseguir un enorme cantidad de uso (I usoshort, pero no es nada como tanto como lo hago int).

Cuestiones relacionadas