C# 및 .NET: 숨겨진 놀라움 공개
소프트웨어 개발은 예상치 못한 동작을 드러내는 경우가 많습니다. C#과 .NET도 강력하지만 예외는 아닙니다. 이 기사에서는 숙련된 개발자라도 도전할 수 있는 몇 가지 흥미로운 특수 사례를 살펴봅니다.
문자열 생성: 직관에 반하는 결과
간단해 보이는 다음 코드 조각을 생각해 보세요.
<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>
출력은 True
이며, 이는 new
이 참조 유형에 대해 고유한 개체를 생성한다는 기대와 모순됩니다. CLR(공용 언어 런타임)은 동일한 빈 문자열 인스턴스를 재사용하여 이 특정 시나리오를 최적화합니다.
일반 유형 및 Null 허용
다음 코드는 또 다른 예상치 못한 동작을 보여줍니다.
<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>
T
이 Nullable<T>
(예: int?
)인 경우 NullReferenceException
을 호출하면 GetType()
이 발생합니다. 이는 Nullable<T>
이 대부분의 메서드를 재정의하지만 GetType()
은 재정의하지 않기 때문입니다. 재정의되지 않은 GetType()
호출 중 boxing 프로세스로 인해 null 값이 발생합니다.
프록시 속성과 new()
제약: 기대에 부응
Ayende Rahien은 유사하지만 더욱 정교한 시나리오를 강조했습니다.
<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>
이 코드는 놀랍게도 어설션에 실패할 수 있습니다. MyFunnyProxyAttribute
호출을 가로채고 new()
을 반환하는 프록시 속성(예: null
)을 사용하면 어설션이 위반될 수 있습니다. 이는 런타임 동작과 사용자 정의 속성 사이에 예상치 못한 상호 작용이 발생할 가능성이 있음을 보여줍니다. 이러한 예는 C# 및 .NET 개발에서 예상치 못한 함정을 피하기 위해 철저한 테스트와 CLR의 내부 작동에 대한 깊은 이해의 중요성을 강조합니다.
위 내용은 C# 및 .NET에는 어떤 예기치 않은 동작과 코너 케이스가 존재합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!