valor - validar fecha null en c#

El objeto C#no es nulo, pero(myObject!=Null) aún devuelve falso

Question

Necesito hacer una comparación entre un objeto y NULL. Cuando el objeto no es NULL, lo lleno con algunos datos.

Aquí está el código:

 if (region != null)
 {
  ....
 }

Esto funciona, pero cuando bucle y bucle en algún momento el objeto de la región NO es nulo (puedo ver los datos dentro de él en modo de depuración). Paso a paso al depurar, no entra dentro de la declaración IF ... Cuando hago un Quick Watch con la siguiente expresión: Veo que (region == null) devuelve false, AND (region! = Null) ) también devuelve falso ... ¿por qué y cómo?

Actualizar

Alguien señaló que el objeto era == y! = Sobrecargado:

    public static bool operator ==(Region r1, Region r2)
    {
        if (object.ReferenceEquals(r1, null))
        {
            return false;
        }
        if (object.ReferenceEquals(r2, null))
        {
            return false;
        }

        return (r1.Cmr.CompareTo(r2.Cmr) == 0 && r1.Id == r2.Id);
    }


    public static bool operator !=(Region r1, Region r2)
    {
        if (object.ReferenceEquals(r1, null))
        {
            return false;
        }
        if (object.ReferenceEquals(r2, null))
        {
            return false;
        }
        return (r1.Cmr.CompareTo(r2.Cmr) != 0 || r1.Id != r2.Id);
    }

Answer 1

Ambas sobrecargas son incorrectas

 public static bool operator ==(Region r1, Region r2)
    {
        if (object.ReferenceEquals(r1, null))
        {
            return false;
        }
        if (object.ReferenceEquals(r2, null))
        {
            return false;
        }

        return (r1.Cmr.CompareTo(r2.Cmr) == 0 && r1.Id == r2.Id);
    }

si r1 y r2 son nulos, la primera prueba ( object.ReferenceEquals (r1, null) ) devolverá false, aunque r2 también sea nulo.

tratar

//ifs expanded a bit for readability
 public static bool operator ==(Region r1, Region r2)
    {
        if( (object)r1 == null && (object)r2 == null)
        {
           return true;
        }
        if( (object)r1 == null || (object)r2 == null)
        {
           return false;
        }        
        //btw - a quick shortcut here is also object.ReferenceEquals(r1, r2)

        return (r1.Cmr.CompareTo(r2.Cmr) == 0 && r1.Id == r2.Id);
    }

Answer 2

Entonces es que estos controles aquí no son correctos:

public static bool operator !=(Region r1, Region r2)
{
    if (object.ReferenceEquals(r1, null))
    {
        return false;
    }
    if (object.ReferenceEquals(r2, null))
    {
        return false;
    }
...

Answer 3

Esas sobrecargas del operador están rotas.

En primer lugar, hace la vida mucho más fácil si! = Se implementa simplemente llamando == e invirtiendo el resultado.

En segundo lugar, antes de que la nulidad se compruebe == debe haber:

if (object.ReferenceEquals(r1, r2))
{
    return true;
}

Answer 4

Esto a veces puede suceder cuando tienes varios hilos trabajando con los mismos datos. Si este es el caso, puede usar un candado para evitar que jueguen entre ellos.

Answer 5

Existe otra posibilidad de que necesite hacer clic en el ícono de actualización al lado del parámetro que está viendo. VS intentan mantenerse al día con el rendimiento sin evaluar cada declaración / parámetro. Eche un vistazo para asegurarse, antes de comenzar a hacer cambios en lugares que no son relevantes.

Answer 6

Para la comparación de igualdad de un tipo "T", sobrecargue estos métodos:

int GetHashCode() //Overrides Object.GetHashCode
bool Equals(object other) //Overrides Object.Equals; would correspond to IEquatable, if such an interface existed
bool Equals(T other) //Implements IEquatable<T>; do this for each T you want to compare to
static bool operator ==(T x, T y)
static bool operator !=(T x, T y)

Su código de comparación específico del tipo debe hacerse en un lugar : el método de interfaz IEquatable<T> seguro de tipo Equals(T other) . Si está comparando con otro tipo (T2), implemente también IEquatable<T2> y coloque el código de comparación de campo para ese tipo en Equals (T2 other).

Todos los métodos y operadores sobrecargados deberían reenviar la tarea de comparación de igualdad al método principal de instancia Equals (T otro) seguro, de forma que se mantenga una jerarquía de dependencia limpia y se introduzcan garantías más estrictas en cada nivel para eliminar la redundancia y la complejidad no esencial.

bool Equals(object other)
{
    if (other is T) //replicate this for each IEquatable<T2>, IEquatable<T3>, etc. you may implement
        return Equals( (T)other) ); //forward to IEquatable<T> implementation
    return false; //other is null or cannot be compared to this instance; therefore it is not equal
}

bool Equals(T other)
{
    if ((object)other == null) //cast to object for reference equality comparison, or use object.ReferenceEquals
        return false;
    //if ((object)other == this) //possible performance boost, ONLY if object instance is frequently compared to itself! otherwise it''s just an extra useless check
        //return true;
    return field1.Equals( other.field1 ) &&
           field2.Equals( other.field2 ); //compare type fields to determine equality
}

public static bool operator ==( T x, T y )
{
    if ((object)x != null) //cast to object for reference equality comparison, or use object.ReferenceEquals
        return x.Equals( y ); //forward to type-safe Equals on non-null instance x
    if ((object)y != null)
        return false; //x was null, y is not null
    return true; //both null
}

public static bool operator !=( T x, T y )
{
    if ((object)x != null)
        return !x.Equals( y ); //forward to type-safe Equals on non-null instance x
    if ((object)y != null)
        return true; //x was null, y is not null
    return false; //both null
}

Discusión:

La implementación anterior centraliza la comparación específica del tipo (es decir, igualdad de campo) con el final de la IEquatable<T> para el tipo. Los operadores == y != Tienen una implementación paralela pero opuesta. Prefiero esto más que tener una referencia la otra, de modo que hay una llamada de método adicional para la dependiente. Si el operador != Va simplemente a llamar al operador == , en lugar de ofrecer un operador con el mismo rendimiento, entonces también puede usar !(obj1 == obj2) y evitar la llamada al método adicional. La comparación entre sí queda fuera del operador equals y de las IEquatable<T> , porque puede introducir 1. gastos indirectos innecesarios en algunos casos, y / o 2. rendimiento inconsistente dependiendo de la frecuencia con la que una instancia se compara a sí misma vs otras instancias.

Una alternativa que no me gusta, pero debería mencionar, es invertir esta configuración, centralizando el código de igualdad específico del tipo en el operador de igualdad en su lugar y los métodos Equals dependen de eso. Entonces uno podría usar el atajo de ReferenceEquals(obj1,obj2) para verificar la igualdad de referencia y la igualdad nula simultáneamente como lo mencionó Philip en una publicación anterior, pero esa idea es engañosa. Parece que estás matando a dos pájaros de un tiro, pero en realidad estás creando más trabajo: después de determinar que los objetos no son nulos ni tienen la misma instancia, entonces, además, tienes que verificar si cada instancia es nulo. En mi implementación, compruebas que una sola instancia sea nula exactamente una vez. En el momento en que se llama al método de instancia Equals, ya se ha descartado que el primer objeto que se compara sea nulo, por lo que todo lo que queda por hacer es comprobar si el otro es nulo. Entonces, después de como mucho dos comparaciones, saltamos directamente a la comprobación de campo, sin importar qué método usemos ( Equals(object),Equals(T),==,!= ). Además, como mencioné, si realmente está comparando y objetando consigo mismo la mayor parte del tiempo, entonces podría agregar esa verificación en el método Equals justo antes de sumergirse en las comparaciones de campo. El último punto para agregarlo es que aún puede mantener la jerarquía de flujo / dependencia sin introducir una verificación redundante / inútil en cada nivel.

Answer 7

bool comp;
if (object.IsNullOrEmpty(r1))
{
    comp = false;
}

if (object.IsNullOrEmpty(r2))
{
    comp = false;
}
return comp;

Answer 8

¿El operador == y / o! = Está sobrecargado para la clase del objeto de región?

Ahora que ha publicado el código de las sobrecargas:

Las sobrecargas probablemente se parecerían a las siguientes (código tomado de las publicaciones hechas por Jon Skeet y Philip Rieck ):

public static bool operator ==(Region r1, Region r2)
{
    if (object.ReferenceEquals( r1, r2)) {
        // handles if both are null as well as object identity
        return true;
    }

    if ((object)r1 == null || (object)r2 == null)
    {
       return false;
    }        

    return (r1.Cmr.CompareTo(r2.Cmr) == 0 && r1.Id == r2.Id);
}

public static bool operator !=(Region r1, Region r2)
{
    return !(r1 == r2);
}