(to == null) w języku C#!

Question

Z powodu błędu, który został rozwiązany w C# 4, następujący program wypisuje true. (Spróbuj go w LINQPad)

void Main() { new Derived(); } 

class Base { 
    public Base(Func<string> valueMaker) { Console.WriteLine(valueMaker()); } 
} 
class Derived : Base { 
    string CheckNull() { return "Am I null? " + (this == null); } 
    public Derived() : base(() => CheckNull()) { } 
} 

w VS2008 w trybie Release, to rzuca InvalidProgramException. (W trybie debugowania działa bez zarzutu)

W VS2010 Beta 2, nie kompiluje (nie wypróbowałem wersji beta 1); Dowiedziałem się, że twardy sposób

Czy istnieje inny sposób, aby this == null w czystym C#?

Answer 1

Ta uwaga została opublikowana dzisiaj na StackOverflow w another question.

Marc „s great answer to that question wskazuje, że zgodnie z specyfikacją (rozdział 7.5.7), nie powinny być w stanie uzyskać dostęp this w tym kontekście oraz możliwość to zrobić w C# 3.0 kompilator jest błąd. C# 4.0 kompilator zachowuje się poprawnie według specyfikacji (nawet w wersji beta 1, to jest błąd czasu kompilacji):

§ 7.5.7 Dostęp ten

ten dostępu składa się z zarezerwowane słowo this.

tego dostępu:

this 

tego dostępu jest dozwolona tylko w bloku z konstruktora przykład, metodę przykład, lub przykład accessor.

Answer 2

Mogę się mylić, ale jestem pewien, że jeśli Twój obiekt jest null, nigdy nie będzie scenariusza, który będzie obowiązywał pod warunkiem, że jest on objęty this.

Na przykład, jak nazwać CheckNull?

Derived derived = null; 
Console.WriteLine(derived.CheckNull()); // this should throw a NullReferenceException 

Answer 3

Miałem to! (I mam dowód zbyt)

Answer 4

Smoły dekompilacji (reflektorowe bez optymalizacji) trybu debug:

private class Derived : Program.Base 
{ 
    // Methods 
    public Derived() 
    { 
     base..ctor(new Func<string>(Program.Derived.<.ctor>b__0)); 
     return; 
    } 

    [CompilerGenerated] 
    private static string <.ctor>b__0() 
    { 
     string CS$1$0000; 
     CS$1$0000 = CS$1$0000.CheckNull(); 
    Label_0009: 
     return CS$1$0000; 
    } 

    private string CheckNull() 
    { 
     string CS$1$0000; 
     CS$1$0000 = "Am I null? " + ((bool) (this == null)); 
    Label_0017: 
     return CS$1$0000; 
    } 
} 

Sposób CompilerGenerated nie ma sensu; jeśli spojrzysz na IL (poniżej), to wywołanie metody na wartości string (!).

.locals init (
     [0] string CS$1$0000) 
    L_0000: ldloc.0 
    L_0001: call instance string CompilerBug.Program/Derived::CheckNull() 
    L_0006: stloc.0 
    L_0007: br.s L_0009 
    L_0009: ldloc.0 
    L_000a: ret 

W trybie zwolnienia zmienna lokalna jest zoptymalizowana, więc próbuje przenieść nieistniejącą zmienną na stos.

L_0000: ldloc.0 
    L_0001: call instance string CompilerBug.Program/Derived::CheckNull() 
    L_0006: ret 

(wywala Reflektor gdy przekształcając go w C#)

---

EDIT: Czy ktoś (? Eric Lippert) wie, dlaczego kompilator emituje ldloc?

Answer 5

To nie jest "błąd". To nadużywasz systemu typu. Nigdy nie należy przekazywać odniesienia do bieżącej instancji (this) do kogokolwiek w obrębie konstruktora.

Mogłem utworzyć podobny "błąd", wywołując metodę wirtualną w obrębie konstruktora klasy podstawowej.

Tylko dlatego, że może zrobić coś złego, nie oznacza jego błąd, gdy pojawi się trochę o niego.

Answer 6

Nie wiem, czy to jest to, czego szukasz

public static T CheckForNull<T>(object primary, T Default) 
    { 
     try 
     { 
      if (primary != null && !(primary is DBNull)) 
       return (T)Convert.ChangeType(primary, typeof(T)); 
      else if (Default.GetType() == typeof(T)) 
       return Default; 
     } 
     catch (Exception e) 
     { 
      throw new Exception("C:CFN.1 - " + e.Message + "Unexpected object type of " + primary.GetType().ToString() + " instead of " + typeof(T).ToString()); 
     } 
     return default(T); 
    } 

przykład: UserID = CheckForNull (Request.QueryString [ "UserID"], 147);