ponen - estandar de documentacion de codigo c#
Guid== null no debe ser permitido por el compilador (4)
En realidad, hay un caso en el que Guild == null devolverá true.
Sin embargo, es un poco difícil de explicar.
En los marcos de mapeo ORM (por ejemplo, openAccess) cuando tiene un campo Guid que tendrá un valor predeterminado de Guid.Empty, por supuesto, es posible tener el siguiente escenario:
- Usted agrega un nuevo campo Guid + una propiedad
- Actualiza el esquema de la base de datos anterior ... en este caso, todos los valores serán NULL en la base de datos.
- Si llena un objeto que tiene esta columna nula de tipo Gremio, por supuesto, el Objeto obtendrá un valor Guid.Empty SIN EMBARGO si utiliza una consulta LINQ ... en la consulta LINQ parece que el Guid aún no está poblado, por lo que debe usar == nulo. Tal vez sea un error pero esta es la forma en que es.
En resumen ( usando OpenAccess pero probablemente no solo ):
var item = GetItems (). Where (i => i.SomeGuidField == null); funcionará y u obtendrá elementos con guid nulo esto es después de una actualización de esquema. item.First (). SomeGuidField devolverá Empty Guid
var item = GetItems (). Where (i => i.SomeGuidField == Guid.Empty); no funcionará incluso si después de la población del elemento será Guid.Empty y devolverá el resultado vacío.
El comportamiento descrito a continuación es específico para .net-3.5 solamente
Acabo de encontrar el comportamiento más sorprendente en el compilador de C #;
Tengo el siguiente código:
Guid g1 = Guid.Empty;
bool b1= (g1 == null);
Bueno, Guid no es anulable, por lo que nunca puede ser igual a nulo . La comparación que estoy haciendo en la línea 2 siempre devuelve falso .
Si haces lo mismo para un entero, el compilador emite una advertencia que dice que el resultado siempre será falso:
int x=0;
bool b2= (x==null);
Mi pregunta es: ¿Por qué el compilador le permite comparar un Guid con un valor nulo ?
Según mi conocimiento, ya sabe que el resultado es siempre falso.
¿La conversión integrada se realiza de tal manera que el compilador asuma que es nulo un valor posible?
¿Me estoy perdiendo algo aquí?
La marca es correcta. Los tipos de valor que definen sus propios operadores de igualdad también obtienen automáticamente las versiones elevadas a nulos, de forma gratuita. El operador de igualdad anulable que toma dos guías anulables es aplicable en esta situación, se llamará y siempre devolverá falso.
En C # 2, esto produjo una advertencia, pero por alguna razón, esto dejó de producir una advertencia de guid-to-null pero continúa produciendo una advertencia de int-to-null. No se por que No he tenido tiempo de investigar todavía.
Me disculpo por el error; Probablemente arruiné una de las rutas de código de detección de advertencia cuando reescribí la lógica de valores nulos en C # 3. La adición de árboles de expresión al lenguaje cambió en gran medida el orden en que se realizan las operaciones aritméticas de valores nulos; Cometí numerosos errores moviendo ese código. Es un código complicado.
Por supuesto, esto no es solo un problema para Guid . El mismo comportamiento se ve con cualquier tipo de struct que no sea un tipo predefinido de C # siempre que el operator == struct sobrecargue operator == de la forma habitual. Otros ejemplos en el marco incluyen DateTime y TimeSpan .
Esto merece una advertencia de tiempo de compilación ya que, si bien es técnicamente legal debido al operador elevado, no es una comparación útil, ya que siempre da false . Como tal, es una indicación de un error del programador.
Como dijo Eric Lippert en su respuesta, la advertencia en tiempo de compilación existía con el compilador de Visual C # 2.0. En las versiones 3.0 a 5.0, la advertencia se omitió accidentalmente (para estos tipos de struct "definidos por el usuario", pero no para los tipos de valores predefinidos como int , y no para los tipos de enumeración).
Desde C # 6.0 (basado en Roslyn), el compilador detecta este problema de código una vez más. Sin embargo, debido a la compatibilidad con versiones anteriores (?!), la advertencia no se emite a menos que compile su código con la llamada característica estricta.
Para habilitar de forma estricta cuando use un archivo .csproj (el caso más habitual), descargue el proyecto de Visual Studio, edite el archivo, inserte el elemento XML:
<Features>strict</Features>
en cada <PropertyGroup> (generalmente habrá más de uno) del archivo .csproj . Luego recibe la advertencia (puede ser "promovido" a un error si usa Tratar las advertencias como errores).
Si no puede editar el .csproj y si llama a msbuild.exe desde la línea de comandos para compilar, use el interruptor:
/p:Features=strict
a msbuild.exe .
Si no usa los archivos .csproj porque compila directamente con csc.exe (el compilador de C #), use el interruptor:
/features:strict
a csc.exe en la línea de comandos.