Quels comportements surprenants pouvez-vous rencontrer avec les cas C# et .NET Corner ?

Dévoiler l'inattendu : les cas C# et .NET Corner

Le développement de logiciels présente souvent des rebondissements surprenants. Cet article explore quelques cas particuliers intrigants en C# et .NET qui peuvent défier même les développeurs expérimentés.

Commençons par l'allocation d'objets de chaîne vide :

<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>

Cela génère étonnamment True, indiquant que x et y font référence au même objet. Cela est dû à une optimisation : la création d'une chaîne vide réutilise une instance mise en cache.

Ensuite, considérons les bizarreries des types Nullable :

<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>

Alors que ToString(), GetHashCode() et Equals() se comportent comme prévu pour un type nullable (comme int?), l'appel de GetType() renvoie un NullReferenceException. En effet, même si les méthodes virtuelles sont remplacées, GetType() ne l'est pas et fonctionne sur la valeur nullable encadrée, ce qui peut entraîner une référence nulle.

Enfin, examinons les contraintes génériques avec les types de classe :

<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>

Bien que l'on puisse s'attendre à une instance non nulle de T, cela peut être contourné en utilisant des techniques impliquant des classes proxy qui renvoient null pour les appels new(). Cela met en évidence l’interaction complexe entre le CLR et le comportement d’exécution du code managé. Ces exemples démontrent que même un code apparemment simple peut présenter un comportement inattendu dans des scénarios spécifiques, soulignant l'importance de tests approfondis et de compréhension des mécanismes sous-jacents de C# et .NET.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!