Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 10. C++/CLI에서 제공되는 명시적인 파괴자의 비밀 [링크 복사], [링크+제목 복사],
조회: 23271
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

C++/CLI에서 제공되는 명시적인 파괴자의 비밀


저의 경우, VC++ 8.0의 C++/CLI에 대한 매력을 느끼게 된 것은 문맥 구문이니... 뭐 그런 것들이 아니었습니다. 바로 명시적인 delete 구문의 지원이었습니다. 어떻게 그것이 가능할까... 뭔가 Interop 간에 대단한 비밀이 있지 않나 싶었는데요. 역시 파고들어 보니... 결국 ^^; IL 코드 내에서 해결할 수 있을 뿐이더군요. (이제와서는, 명시적인 종료자보다 IJW를 구현한 것에 대해 더 칭찬을 해주고 싶습니다.)

우선, 본격적으로 들어가기에 앞서 미리 다음의 토픽을 먼저 봐주시기 바랍니다.

.NET IDisposable 처리 정리
; https://www.sysnet.pe.kr/2/0/347

사실, 도움말에도 나타난 위의 토픽을 굳이 한 번 더 언급한 것은 이번 토픽을 위해서였습니다.



그럼, 하나씩 한번 알아볼까요? ^^

우선 예제 코드가 하나 있어야 할 테니, 다음과 같은 클래스를 만들어서 예로 들어보겠습니다.

public ref class MyClass 
{
public:

	MyClass()
	{
	}
};

아래는 위의 코드를 사용하느 main 함수입니다.

int main(array ^args)
{
	MyClass ^myClass = gcnew MyClass();
    return 0;
}

일단, 여기까지는 크게 일반 C#/VB.NET 클래스와 다른 점이 없습니다. 그런데, 여러분이 (또는 과거의 제가) 어렴풋이 들었던 것 중에, C++/CLI에서는 delete 구문으로 개체를 명시적으로 해제하는 것을 지원한다고 했지요. 그래서 다음과 같이 delete를 추가해 보겠습니다.

int main(array ^args)
{
	MyClass ^myClass = gcnew MyClass();
	delete myClass;
    return 0;
}

과연 정말 그럴까요? 위와 같이 하면 CLR Heap에 할당된 개체가 즉시 삭제되어 메모리 관리 효율이 C++과 같아질 수 있을까요? 물론... 대답은 "아니오"입니다. 실제로, 위의 코드 부분에 대해서 ".NET Reflector"로 보면 다음과 같이 delete 코드가 확장되어 나오는 것을 확인할 수 있습니다.

internal static int main(string[] args)
{
      MyClass class1 = null;
      class1 = new MyClass();
      IDisposable disposable1 = class1 as IDisposable;
      if (disposable1 != null)
      {
            disposable1.Dispose();
      }

      return 0;
}

위의 코드를 보시고, ^^; 쓴웃음을 짓는 분도 계실 텐데요. 그렇습니다. "delete myClass;" 구문은 실제로는 해당 개체의 IDisposable 인터페이스 구현여부를 알아내서 그것의 Dispose 메서드를 호출해주는 코드로 대체되어 삽입되는 것 뿐입니다. 이건 사실 기술이라고 부를 수도 없지요. 단지 언어적인 확장에 기인한 것 뿐이니까요. 마치 C#의 경우 using 예약어를 지원하지만, 결국 생성된 코드는 try / finally에 Dispose 메서드를 불러주는 코드로 확장되는 것과 다를 바 없습니다. 실제로, 우리가 기대했던 CLR Heap의 메모리 정리 상황은 발생하지 않는다는 것이 중요할 것입니다. 위의 방식을 아셨으니, 이제 쓰게 될 나머지 부분은 다 그러한 부분의 확장으로 받아들이시면 이해가 금방 되실 텐데요.

가만 있자... 그럼 또 뭐가 있을까요? 그렇군요. 우리가 알고 있던 얘기 중에, C++/CLI는 파괴자를 구현하면 scope을 벗어나는 경우 자동으로 호출된다고 들었지요. 그럼 그 부분도 한번 살펴볼까요? 예를 위해 위의 코드를 다음과 같이 수정해 보겠습니다.

public ref class MyClass 
{
	char *m_pBuf;
public:

	MyClass()
	{
		m_pBuf = new char[ 4096 ];
	}

	~MyClass()
	{
		delete [] m_pBuf;
	}
};

scope을 벗어나는 것을 테스트하기 위해서 MyClass에 대한 명시적인 delete 없이 다음과 같은 스택 방식으로 수정을 하겠습니다.

int main(array ^args)
{
	MyClass myClass;
	return 0;
}

역시 이번에도 생성된 IL 코드를 ".NET Reflector"로 확인해 보겠습니다.

internal static int main(string[] args)
{
      int num2;
      MyClass class1 = null;
      MyClass modopt(IsConst) local1 = (MyClass modopt(IsConst)) new MyClass();
      try
      {
            class1 = local1;
            num2 = 0;
      }
      fault
      {
            class1.Dispose();
      }
      class1.Dispose();
      
      return num2;
}

오... 이런... ^^; 역시 이번에도 실제로는 Managed 클래스를 스택상에 생성하지 않고 CLR Heap에 할당하고는 fault 처리기에서 Dispose가 명시적으로 불릴 수 있도록 하는 IL 코드로 확장이 되었습니다.
재미있는 것은, MyClass를 IL 코드로 열어보면 C++ 구문의 파괴자를 구현한 것이 실제로는 다음과 같이 IDisposable 패턴으로 확장된 것을 볼 수 있습니다.

public class MyClass : IDisposable
{
      public MyClass();
      private void ~MyClass();
      public sealed override void Dispose();
      protected virtual void Dispose([MarshalAs(UnmanagedType.U1)] bool);

      private unsafe sbyte modopt(IsSignUnspecifiedByte)* m_pBuf;
}

패턴은 이전 토픽에서 살펴봤던 C#과 동일한 구조를 따르고 있습니다.

정리해 보면, C++/CLI의 자원 해제 기능은 결국 C++과 유사한 구문을 그대로 유지하되 내부적으로는 IDisposable 구문으로 확장해주는 것에 불과하다는 것입니다.

즉, C++/CLI에서 다음과 같이 코딩을 한 것은,

	MyClass ^myClass = gcnew MyClass();
	delete myClass;
	
	또는,
	
	MyClass myClass;

C#으로 다음과 같이 코딩을 해줄 수가 있습니다.

  using ( MyClass myClass = new MyClass() )
  {
  }  

C++/CLI에서는 단지 구문을 단순하게 해준다는 장점만 있을 뿐, 그 이외의 어떠한 장점도 없다는 것입니다.



이미 앞에서 다뤘던 .NET IDisposable 처리 정리의 토픽과 비교해 보시면 아직 얘기하지 않은 이야기가 하나 있음을 아시게 될 텐데요. 바로 Managed 자원 해제와 Unmanaged 자원 해제를 구분지어 해제하는 방법이 과연 무엇이냐는 것입니다. C#의 경우, IDisposable 인터페이스를 구현하고 내부적으로 Dispose(bool disposing) 메서드를 호출하는데, C++/CLI에서는 IDisposable 인터페이스를 자동으로 구현하기 때문에 bool disposing에 대한 처리를 하는 부분이 모호해지기 때문입니다. 이를 위해, C++/CLI에서는 다음과 같은 특별한 구문의 파괴자를 하나 더 지원합니다.

public ref class MyClass 
{
	char *m_pBuf;
public:

	MyClass()
	{
		m_pBuf = new char[ 4096 ];
	}

	~MyClass()
	{
		// Managed 자원과 Unmanaged 자원을 모두 해제
		delete [] m_pBuf;
	}

	!MyClass()
	{
		// Unmanaged 자원을 해제
		delete [] m_pBuf;
	}
};

이 부분에서 약간 재미난 현상을 만나게 되는데요. Unmanaged 자원에 대한 해제 코드를 중복시키지 않기 위해 ~MyClass에서 !MyClass를 아래와 같이 호출하게 되면 컴파일 오류가 발생하게 됩니다.

	~MyClass()
	{
		!MyClass(); // error C2088: '!' : illegal for class	d:\...\Test.h
	}

	!MyClass()
	{
		delete [] m_pBuf;
	}

대신에 다음과 같이 포인터 구문을 쓰게 되면 정상적으로 호출이 됩니다.

	~MyClass()
	{
		this->!MyClass(); // 또는 MyClass::!MyClass();
	}

	!MyClass()
	{
		delete [] m_pBuf;
	}



이로써, C++/CLI의 명시적인 종료자에 대해서 웬만큼 살펴본 것 같은데요.
결론을 내려보면. C++/CLI가 자원 해제 면에서 결코 우수한 언어가 아님을 알게 됩니다. 그저 Interop만 우수한 언어일 뿐.



[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 6/24/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  [67]  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12298정성태8/27/202020003오류 유형: 640. livekd - Could not resolve symbols for ntoskrnl.exe: MmPfnDatabase
12297정성태8/25/202019458개발 환경 구성: 503. SHA256 테스트 인증서 생성 방법
12296정성태8/24/202020512.NET Framework: 933. C# - ETW 관련 Win32 API 사용 예제 코드 (2) NT Kernel Logger파일 다운로드1
12295정성태8/24/202019319오류 유형: 639. Bitvise - Address is already in use; bind() in ListeningSocket::StartListening() failed: Windows error 10013: An attempt was made to access a socket ,,,
12293정성태8/24/202020280Windows: 171. "Administered port exclusions" 설명
12292정성태8/20/202023604.NET Framework: 932. C# - ETW 관련 Win32 API 사용 예제 코드 (1)파일 다운로드2
12291정성태8/15/202020090오류 유형: 638. error 1297: Device driver does not install on any devices, use primitive driver if this is intended.
12290정성태8/11/202021468.NET Framework: 931. C# - IP 주소에 따른 국가별 위치 확인 [8]파일 다운로드1
12289정성태8/6/202018445개발 환경 구성: 502. Portainer에 윈도우 컨테이너를 등록하는 방법
12288정성태8/5/202016671오류 유형: 637. WCF - The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered.
12287정성태8/5/202018989오류 유형: 636. C# - libdl.so를 DllImport로 연결 시 docker container 내에서 System.DllNotFoundException 예외 발생
12286정성태8/5/202020426개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/202019394오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/4/202018803디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/202020524디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd) [2]
12282정성태8/2/202017567디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202021708개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202019240오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202021724개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/202017765VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202019891개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202019688.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202021444개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202020517개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202023734개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/202016162.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
... 61  62  63  64  65  66  [67]  68  69  70  71  72  73  74  75  ...