veo a menudo en los códigos fuente del uso de si (object.ReferenceEquals (myObject, null)) para comprobar si myObject es nulo si en lugar de (myObject == nulo) con el que estoy familiarizado.mejor y más rápida manera de comprobar si un objeto es nulo
¿Hay alguna razón en particular (como velocidad, legibilidad, etc.) para usar la primera vía en lugar de la segunda? ¿Cuál usas?
Gracias de antemano.
Al utilizar ReferenceEquals, asegúrese de que no se esté aplicando un manejo especial (por ejemplo, operador sobrecargado). Esto también conduce a resultados diferentes si se usa con genéricos independientes.
Tome un vistazo a este interesante artículo
Performance Tip: Prefer (((Object) x)== null) to Object.ReferenceEquals(x,null)
El operador == puede originar sobrecargas en las implementaciones de clases, por lo que podría no hacer una comparación de referencia (aunque probablemente debe con null s). object.ReferenceEquals no puede, por lo que de manera confiable siempre hace una comparación de referencia.
Saludos Matthias
El método ReferenceEquals no se pueden sustituir por lo que siempre se puede estar seguro de que la comparación se va a comparar las referencias a objetos y no puede pasar a algunos de anulación del método Equals.
cosas simples son generalmente los más eficientes: (myObject == null) es más performante
Mira this artículo
El artículo al que se hace referencia, aunque parece una lectura interesante, pero está dirigido a .NET 2.0. En el momento en que .NET 4.0 estuvo fuera por algún tiempo y en él, no hay diferencia entre usar '(object) myObj == null' y' ReferenceEquals'. Sin embargo, su sugerencia en esta publicación (mientras que hace 7 años) es muy peligrosa (como se explica en el artículo vinculado) y ciertamente * no * debe usarse sin un yeso (a menos que realmente desee usar una posible sobrecarga, pero luego "performant "no tiene nada que ver con eso). – Abel
lo general, tienen el mismo efecto, aunque se compilan a diferentes cosas. if (myObject == null) da como resultado un código de operación ceq, que esperaba compilar con un código más rápido. object.ReferenceEquals es una llamada a método como cualquier otra.
Son diferentes cuando myObject tiene un método operator=; cuando esto está presente, su código llama a este método en lugar de usar ceq. operator= puede hacer lo que quiera.
Siempre if (myObject == null) a menos que tenga un motivo para no hacerlo.
El hecho de que sea una llamada a un método en IL no significa que se trate de una llamada a un método una vez que finaliza la trepidación. La referencia igual es muy corta, por lo que es probable que esté en línea. Y su contenido es simplemente 'obj1 == obj2', por lo que esperaría exactamente el mismo rendimiento que con ==, pero arroja los argumentos al objeto, por lo que cualquier operador == sobrecargado no lo afecta. – CodesInChaos
No es una "llamada a método como cualquier otra", cuando se compila, la IL no tendrá esa llamada de método, en su lugar, se usan códigos IL especiales, que son iguales (desde .NET 4.0) para ambos enfoques. @CodesInChaos tiene razón, es exactamente el mismo rendimiento (e IL). – Abel
Ese artículo está desactualizado, se llega a conclusiones erróneas. El IL es exactamente igual para ambos enfoques en .NET 4.0 y superior. Puedes ver eso fácilmente probando los ejemplos en ese artículo. Para la legibilidad sugeriría 'ReferenceEquals'. – Abel