C# 및 .NET에는 어떤 예기치 않은 동작과 코너 케이스가 존재합니까?

C# 및 .NET: 숨겨진 놀라움 공개

소프트웨어 개발은 ​​예상치 못한 동작을 드러내는 경우가 많습니다. C#과 .NET도 강력하지만 예외는 아닙니다. 이 기사에서는 숙련된 개발자라도 도전할 수 있는 몇 가지 흥미로운 특수 사례를 살펴봅니다.

문자열 생성: 직관에 반하는 결과

간단해 보이는 다음 코드 조각을 생각해 보세요.

string x = new string(new char[0]);
string y = new string(new char[0]);
Console.WriteLine(object.ReferenceEquals(x, y));

출력은 True이며, 이는 new이 참조 유형에 대해 고유한 개체를 생성한다는 기대와 모순됩니다. CLR(공용 언어 런타임)은 동일한 빈 문자열 인스턴스를 재사용하여 이 특정 시나리오를 최적화합니다.

일반 유형 및 Null 허용: NullReferenceException 미스터리

다음 코드는 또 다른 예상치 못한 동작을 보여줍니다.

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());
}

T이 Nullable<t></t>(예: int?)인 경우 NullReferenceException을 호출하면 GetType()이 발생합니다. 이는 Nullable<t></t>이 대부분의 메서드를 재정의하지만 GetType()은 재정의하지 않기 때문입니다. 재정의되지 않은 GetType() 호출 중 boxing 프로세스로 인해 null 값이 발생합니다.

프록시 속성과 new() 제약: 기대에 부응

Ayende Rahien은 유사하지만 더욱 정교한 시나리오를 강조했습니다.

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?");
}

이 코드는 놀랍게도 어설션에 실패할 수 있습니다. MyFunnyProxyAttribute 호출을 가로채고 new()을 반환하는 프록시 속성(예: null)을 사용하면 어설션이 위반될 수 있습니다. 이는 런타임 동작과 사용자 정의 속성 사이에 예상치 못한 상호 작용이 발생할 가능성이 있음을 보여줍니다. 이러한 예는 C# 및 .NET 개발에서 예상치 못한 함정을 피하기 위해 철저한 테스트와 CLR의 내부 작동에 대한 깊은 이해의 중요성을 강조합니다.

위 내용은 C# 및 .NET에는 어떤 예기치 않은 동작과 코너 케이스가 존재합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!