Heim >Backend-Entwicklung >C++ >Welches überraschende Verhalten können Sie mit C #- und .NET -Eckfällen begegnen?
Enthüllen Sie das Unerwartete: C# und .NET Eckfälle
Softwareentwicklung zeigt häufig überraschende Wendungen. In diesem Artikel werden einige faszinierende Eckfälle innerhalb von C# und .NET untersucht, die selbst erfahrene Entwickler in Frage stellen können.
Beginnen wir mit leerer String -Objektzuweisung:
<code class="language-csharp">string x = new string(new char[0]); string y = new string(new char[0]); Console.WriteLine(object.ReferenceEquals(x, y)); // Outputs True</code>
Dies gibt überraschend True
aus, was darauf hinweist, dass x
und y
dasselbe Objekt verweisen. Dies ist auf eine Optimierung zurückzuführen: Erstellen einer leeren Zeichenfolge wiederverwendet eine zwischengespeicherte Instanz.
Betrachten Sie als nächstes die Macken von nullierbaren Typen:
<code class="language-csharp">static void Foo<T>() where T : new() { T t = new T(); Console.WriteLine(t.ToString()); // Works fine Console.WriteLine(t.GetHashCode()); // Works fine Console.WriteLine(t.Equals(t)); // Works fine Console.WriteLine(t.GetType()); // Throws NullReferenceException }</code>
während ToString()
, GetHashCode()
und Equals()
verhalten sich wie erwartet für einen nullbaren Typ (wie int?
), und ruft GetType()
ein NullReferenceException
auf. Dies liegt daran, dass die virtuellen Methoden zwar überschrieben sind, GetType()
nicht mit dem nullbaren Wert des Boxed arbeitet, was möglicherweise zu einer Nullreferenz führt.
Untersuchen wir schließlich generische Einschränkungen mit Klassenarten:
<code class="language-csharp">private static void Main() { CanThisHappen<MyFunnyType>(); } public static void CanThisHappen<T>() where T : class, new() { var instance = new T(); // new() on a ref-type; should be non-null, then Debug.Assert(instance != null, "How did we break the CLR?"); }</code>
Während man eine Nicht-Null-Instanz von T
erwarten könnte, kann dies mithilfe von Techniken mit Proxyklassen umgangen werden, die null
für new()
Anrufe zurückgeben. Dies unterstreicht die komplexe Wechselwirkung zwischen CLR und dem Laufzeitverhalten von Managed Code. Diese Beispiele zeigen, dass selbst scheinbar einfacher Code in bestimmten Szenarien ein unerwartetes Verhalten aufweisen kann, wodurch die Bedeutung von gründlichen Testen und Verständnis der zugrunde liegenden Mechanismen von C# und .NET betont wird.
Das obige ist der detaillierte Inhalt vonWelches überraschende Verhalten können Sie mit C #- und .NET -Eckfällen begegnen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!