C++/CLI에 대해서 알아두어야 할 것들

이 글을 이해하기 위해서는…

C++/CLI에 대한 기본적인 이해가 필요합니다.

C++/CLI는 unmanaged code와 managed code의 경계를 허물어 준다.

그렇기 때문에 unmanaged code 영역에서 사용하는 C++의 특성과 managed C++가 갖는 C++의 특성을 모두 가지고 있다. 하지만, 이 두가지 특성이 모두 managed code에 반영되는 것은 아니다.

C++/CLI로 클래스 라이브러리를 작성한다면 다음과 같은 사실을 감안하여 코드를 작성하는 것이 좋다.

네이티브 타입은 더 이상 공짜가 아니다

2005 부터 네이티브 타입은 private 한정자가 적용된다. 소스 수준에서 한정자를 변경하거나 컴파일 지시어 make_public 으로 한정자를 public 으로 변경해야 한다.

템플릿은 생성되지 않는다

템플릿 클래스, 템플릿 메소드 등은 타입에서 제외된다. 매니지드 클래스라 하더라도 템플릿으로 구현된 메소드는 클래스의 메소드에서 제거된다.

템플릿 클래스 타입을 만들고자 한다면 제너릭 클래스 타입을 정의해야 한다.

typedef는 타입이 아니다

C++에서 typedef는 새로운 타입을 생성하는 것이 맞다. 하지만, C++/CLI에서 생성하는 닷넷 클래스 라이브러리에서 typedef는 새로운 타입으로 노출되지 않는다.

하지만, C++/CLI에서 특정 타입의 포인터 타입에 대한 Type 클래스를 얻고자 한다면, typedef로 포인터 타입을 정의해야 한다.

네이티브 타입은 값 타입이다

네이티브 타입은 값 형식으로 정의된다.

새로운 네이티브 타입을 정의하지 말아라

새로 정의한 네이티브 타입을 다른 모듈에서 참조할 때는 여전히 헤더 파일과 라이브러리를 필요로 한다. 당연한 얘기지만, C++/CLI의 닷넷 클래스 라이브러리는 managed C++이 아닌 링커를 위한 라이브러리를 생성하지 않는다.

새로운 네이티브 타입은 오직 닷넷 클래스 라이브러리 내부에서 사용할 용도로만 정의해야 한다.

어셈블리에는 AssemblyInfo 속성이 필요하다

어셈블리는 AssemblyInfo 속성을 포함해야 한다.

그러나, 어셈블리에서 AssemblyInfo 속성 값들을 정의하지 않아도 빌드 에러가 발생하지 않으며, 심지어 오브젝트 뷰어에서 라이브러리로 구현한 클래스들을 확인할 수 있고, C#에서 클래스 라이브러리를 사용하는데 문제가 발생하지 않는다.

하지만, C++/CLI의 managed code에서 이 라이브러리를 사용하고자 할 때, 타입들이 정의되지 않았음을 알게될 것이다. 어셈블리의 AssemblyInfo 속성을 빼먹으면 그렇게 된다.

필요한 모든 클래스를 정의해라

C++/CLI로 닷넷 클래스 라이브러리를 작성하는 경우 기존에 작성해 둔 수 많은 클래스를 다시 정의해야 하는지 고민할 수 밖에 없다.

하지만, 잊어라. 네이티브 클래스는 닷넷의 세계에서 존재하지 않는다. 닷넷 기반으로 필요한 모든 클래스는 새로 정의해야 한다. 다만, 새로 정의하는 클래스에서 이미 구현되어 있는 메소드들을 호출할 수 있도록 C++/CLI가 많은 도움을 준다.

그러나, C++/CLI의 역할은 managed code에서 unmanaged code로의 호출을 지원하고 두가지 타입의 코드가 공존하는 어셈블리를 생성하기 위함에 있다. 기존에 구현되어 있는 클래스를 재사용하기 위한 도구가 아니다.

수많은 C++/CLI 예제에서 괜히 매니지드 클래스를 위한 래퍼 클래스를 일일이 만드는 것이 아니다.


출처 : http://stratosphere631.com/wp/?p=866