Quels comportements inattendus et quels cas particuliers existent en C# et .NET ?

C# et .NET : dévoiler des surprises cachées

Le développement de logiciels révèle souvent des comportements inattendus. C# et .NET, bien que puissants, ne font pas exception. Cet article explore quelques cas particuliers intrigants qui peuvent défier même les développeurs expérimentés.

Création de chaînes : un résultat contre-intuitif

Considérez cet extrait de code apparemment simple :

<code class="language-csharp">string x = new string(new char[0]);
string y = new string(new char[0]);
Console.WriteLine(object.ReferenceEquals(x, y));</code>

Le résultat est True, contredisant l'attente selon laquelle new crée des objets distincts pour les types référence. Le Common Language Runtime (CLR) optimise ce scénario spécifique, en réutilisant la même instance de chaîne vide.

Types génériques et Nullable : un mystère NullReferenceException

Le code suivant démontre un autre comportement inattendu :

<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

    // This throws a NullReferenceException...
    Console.WriteLine(t.GetType());
}</code>

Lorsque T est Nullable<T> (par exemple, int?), un NullReferenceException se produit lors de l'appel de GetType(). En effet, Nullable<T> remplace la plupart des méthodes, mais pas GetType(). Le processus de boxe lors de l'appel au GetType() non remplacé donne une valeur nulle.

Attributs du proxy et new() Contrainte : défier les attentes

Ayende Rahien a mis en avant un scénario similaire, mais plus sophistiqué :

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

Ce code, étonnamment, peut faire échouer l'assertion. En utilisant un attribut proxy (comme MyFunnyProxyAttribute) qui intercepte l'appel new() et renvoie null, l'assertion peut être violée. Cela démontre le potentiel d’interactions inattendues entre le comportement d’exécution et les attributs personnalisés. Ces exemples soulignent l'importance de tests approfondis et d'une compréhension approfondie du fonctionnement interne du CLR pour éviter les pièges inattendus dans le développement 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!