Managed Extensions for C++ 또는 Managed C++는 C++를 위한 지원이 중단된 언어 확장 세트로, C++ 구문과 언어를 닷넷 프레임워크로 가져오기 위한 문법 및 구문 확장, 키워드, 특성 등을 포함한다. 이 확장 기능은 마이크로소프트가 C++ 코드를 관리 코드 형태의 공통 언어 런타임(CLR)을 대상으로 할 수 있게 하고, 동시에 네이티브 코드와 상호 운용할 수 있도록 하기 위해 만들어졌다.
2004년, Managed C++ 확장은 구문을 명확히 하고 단순화하며 제네릭 프로그래밍을 포함하도록 기능을 확장하는 방향으로 크게 수정되었다. 이러한 새로운 확장은 C++/CLI로 명명되었으며 마이크로소프트 비주얼 스튜디오 2005에 포함되었다. 따라서 Managed C++라는 용어와 그 확장 기능은 지원이 중단되었으며, 새로운 확장 기능으로 대체되었다.
마이크로소프트는 마이크로소프트 비주얼 C++ 2002(MSVC++)에서 Managed Extensions for C++를 도입했다. 마이크로소프트는 표준 C++와 Managed Extensions for C++ 사이의 차이를 최소화하고자 했으며, 결과적으로 두 언어 간의 핵심적인 차이점이 구문상으로 모호해졌다. MSVC++ 2003과 2005 또한 Managed C++로 프로그램을 작성할 수 있도록 지원했다. 2004년, Managed Extensions for C++는 C++를 사용하여 공통 언어 기반을 위한 프로그래밍을 지원하려는 마이크로소프트의 두 번째 시도인 C++/CLI를 위해 지원이 중단되었다.
Managed는 버퍼 오버런 검사와 같은 더 많은 런타임 검사를 통해 향상된 보안을 제공하는 샌드박스 역할을 하는 닷넷 가상 머신에서 실행되거나 이에 의해 관리되는 관리 코드를 의미한다. 또한 Managed C++로 작성된 애플리케이션은 표준 C++ 애플리케이션처럼 네이티브 중앙 처리 장치 명령어로 직접 컴파일되는 것이 아니라 CIL로 컴파일된다.
Managed C++ 코드는 C#이나 비주얼 베이직 닷넷과 같이 CLR을 대상으로 하는 다른 모든 언어와 상호 운용될 수 있으며, 쓰레기 수집과 같이 CLR에서 제공하는 기능을 사용할 수 있다. 이는 Managed C++가 닷넷 언어들 사이에서 독특한 위치를 차지함을 의미한다. Managed C++는 닷넷 언어(C#, VB.NET 등)는 물론 네이티브 C++와도 직접 통신할 수 있는 유일한 언어이다. 다른 닷넷 언어들은 PInvoke나 COM을 통해서만 C++ 코드와 통신할 수 있다. 그러나 Managed C++는 관리 환경과 표준 C++ 환경 모두에서 직접 통신할 수 있기 때문에 종종 "브리지"로 사용된다.
Managed C++로 코딩된 프로그램은 닷넷 프레임워크와 CLR의 추가 기능을 제공한다. 그중 가장 주목할 만한 것은 쓰레기 수집으로, 프로그래머가 수동으로 메모리를 관리할 필요가 없도록 해준다. 쓰레기 수집기(GC)는 CLR에 의해 처리된다. 메모리 관리는 매우 빠르게 실행되지만, 성능이 중요한 애플리케이션의 경우 네이티브 비관리 코드가 더 선호되는 옵션일 가능성이 높다.
Managed C++는 객체 지향 프로그래밍을 지향한다. 표준 C++와 Managed C++의 주요 차이점은 다중 상속이 지원되지 않으며, CLR의 쓰레기 수집기 하에서 관리되는 클래스는 두 개 이상의 클래스를 상속할 수 없다는 점이다. 이는 CLR의 제한 사항 때문이다.
주요 특징:
다음 예제는 표준 C++와 비교하여 Managed C++의 사용을 보여준다.
// Gello.cpp
// 새로운 using 지시문
#using <mscorlib.dll>
// 또 다른 using namespace 지시문
using namespace System;
int main() {
Console::WriteLine("Hello, world!");
return 0;
}
새로운 전처리기 지시문
#using <mscorlib.dll>
가 필요하다. 이 외에도 기본 클래스 라이브러리의 더 많은 네임스페이스를 사용하기 위해 더 많은 라이브러리를 가져오는 #using 지시문이 필요하다. 예를 들면
#using <System.Windows.Forms.dll>
와
using namespace System::Windows::Forms;
를 사용하여 윈도우 폼을 사용할 수 있다.
cl.exe hello.cpp /clr
/clr은 닷넷 프레임워크를 참조하는 모든 코드가 CIL로 컴파일되도록 한다.
__gc 확장 키워드를 통해 쓰레기 수집 대상으로 지정할 수 있다.// GarbageCollected.cpp
#using <mscorlib.dll>
__gc class GarbageCollected {
int* i;
char* g;
float* j;
};
int main() {
while (true) {
GarbageCollected^ _gc = gcnew GarbageCollected();
}
return 0;
}
위의 코드는 메모리 누수에 대한 걱정 없이 컴파일 및 실행될 수 있다. 클래스 gc는 쓰레기 수집기 하에서 관리되기 때문에 delete 연산자를 호출할 필요가 없다. 비관리 코드로 동일한 작업을 수행하려면 delete 키워드가 필요하다:
// NotGarbageCollected.cpp
class NotGarbageCollected {
int* i;
char* g;
float* j;
};
int main() {
while (true) {
NotGarbageCollected* g = new NotGarbageCollected();
delete g;
}
return 0;
}
참고:
public __gc class MyClass {
// ...
};
public 키워드를 사용하여 __gc로 지정된 클래스의 접근을 수정한다.
__gc로 지정된 클래스는 delete 키워드를 사용하여 수동으로 삭제할 수 있지만, 사용자 정의 소멸자가 있는 경우에만 가능하다.
// MyInterface.cpp
#using <mscorlib.dll>
__gc __interface MyInterface {
void init();
int common();
}
위 코드는 간단한 DLL 파일을 생성하기 위해 /clr 및 /LD로 컴파일해야 한다.
참고:
다음은 Managed C++와 개념적으로 유사한 다른 잘 알려진 프로그래밍 언어 간의 주요 차이점과 프로그래밍 표준을 포함한다.
단점
public __gc class First {
int i;
};
public __gc class Second: private First {
int h;
i = h;
}; // 오류
public __gc class Third: protected First {
int h;
i = h;
}; // 오류
__gc class First {};
__gc class Second {};
__gc class Third: public First, public Second {}; // 오류 발생
장점
차이점
단점
장점
차이점
단점
장점