C++용 확장 관리
Managed Extensions for C++Managed Extensions for C++ 또는 Managed C++ 는 문법 및 구문 확장자, 키워드 및 속성 등 C++ 의 언어 확장자 세트로, 에 C++ 구문 및 언어를 가져옵니다.NET 프레임워크이러한 확장 기능은 C++ 코드를 관리 코드 형식으로 Common Language Runtime(CLR; 공통 언어 런타임)으로 설정하고 네이티브 코드와 계속 상호 운용할 수 있도록 Microsoft에 의해 작성되었습니다.
2004년에 Managed C++ 확장이 대폭 개정되어 구문을 명확하게 하고 심플하게 하고 기능을 확장하여 Managed Generic을 포함하게 되었습니다.이러한 새로운 확장 기능은 C++/CLI로 지정되어 Microsoft Visual Studio [1]2005에 포함되어 있습니다.따라서 Managed C++라는 용어와 그 용어가 나타내는 확장자는 폐지되고 새로운 확장자로 대체됩니다.
역사
Microsoft 는, Microsoft Visual C++ 2002(MSVC++)에, C++ 용 Managed Extensions 를 도입했습니다.Microsoft는 표준 C++와 Managed Extensions for C++의 차이를 최소화하려고 시도했습니다.그 결과, 이 둘은 구문적으로 구별되지 않습니다.MSVC++ 2003 및 2005 에서는, Managed C++ 로의 프로그램 기술도 서포트되고 있습니다.2004년에 C++용 Managed Extensions는 C++/CLI를 위해 폐지되었습니다.이것은 마이크로소프트가 C++[2]를 사용한 공통 언어 인프라스트럭처의 프로그래밍을 지원하는 두 번째 시도입니다.
설계.
Managed는 에서 실행되거나 에 의해 관리되는 관리되는 코드를 의미합니다.버퍼 오버런 검사와 같은 더 많은 런타임 검사 형식으로 향상된 보안을 위한 샌드박스 역할을 하는 NET 가상 시스템입니다.또한 Managed C++로 작성된 어플리케이션은 CIL(Common Intermediate Language)로 컴파일되며 표준 C++ 어플리케이션과 같은 네이티브 CPU 명령으로 직접 컴파일되지 않습니다.
관리 대상 C++ 코드는 C#이나 Visual Basic 등 CLR을 대상으로 하는 다른 언어와 상호 운용할 수 있습니다.NET 및 가비지 컬렉션 등의 CLR에 의해 제공되는 기능을 사용합니다.즉, Managed C++는 의 갤러리에서 하나의 위치를 차지하고 있습니다.NET 언어와 직접 통신할 수 있는 유일한 언어입니다.NET 언어(C#, VB 등)NET) 및 네이티브 C++.다른.NET 언어는 PInvoke 또는 COM을 통해서만 C++ 코드와 통신할 수 있습니다.단, Managed C++는 관리 대상 컨텍스트와 표준 C++ 컨텍스트 모두에서 직접 통신할 수 있기 때문에 "브릿지"로 사용되는 경우가 많습니다.
기능
Managed C++ 로 코드화된 프로그램은 의 추가 기능을 제공합니다.NET Framework 및 CLR.이 중 가장 주목할 만한 것은 가비지 수집으로 프로그래머의 수동 메모리 관리를 덜어줍니다.Garbage Collector(GC; 가비지 콜렉터)는 CLR에 의해 처리됩니다.메모리 관리는 매우 빠르게 실행되지만 성능이 중요한 애플리케이션에서는 비관리형 네이티브 코드를 사용하는 것이 가장 좋습니다.
Managed C++는 객체 지향 프로그래밍에 맞춰져 있습니다.표준 C++와 Managed C++의 주요 차이점은 다중 상속이 지원되지 않으며 CLR의 가비지 컬렉터에서 관리되는 클래스는 여러 클래스를 상속할 수 없다는 것입니다.이는 CLR의 제한 때문입니다.
주요 기능:
- 확장 가능한 메타데이터: 관리되는 컴포넌트의 구조와 유형을 설명하기 위해 제공되는 정보입니다.소프트웨어 구성 요소를 생성하는 데 확장 및 재사용할 수 있습니다.C# 및 Visual Basic에서 많이 사용됩니다.그물
- 가비지 컬렉션: CLR은 CLR 자체에 의해 자동화된 메모리 관리를 위해 가비지 컬렉터에 의해 완전히 관리됩니다.즉, 관리 대상 C++ 코드로 삭제 연산자를 호출할 필요가 없습니다.
- 와의 상호 운용성.NET 언어: 대상 코드.NET Framework는 Microsoft Intermediate Language(MSIL, Java 바이트 코드와 유사) 출력을 생성합니다.따라서 컴파일된 모듈 및 컴포넌트(어셈블리)는 를 대상으로 하는 다른 언어로 작성된 다른 프로그램컴포넌트에 의해 재사용할 수 있습니다.JScript 등의 NET Framework.NET, C#, Visual Basic.의 NET 및 기타 서드파티 언어.그물.
- 버전 관리: 기존 클라이언트 측 소프트웨어와의 바이너리 호환성을 해치지 않고 기존 관리 클래스에 새로운 메서드와 데이터 멤버를 도입할 수 있습니다.
- 바이너리 헤더: 사전 컴파일된 메타데이터를 재사용할 수 있습니다.MSIL로 컴파일된 .exe, .dll, .obj 또는 .netmodule은 C++ 소스 파일에서 참조할 수 있습니다.
- 버퍼 오버플로우 방지 - 가비지 컬렉션이 C++에 도입되어 관리 대상 C++는 표준 C++에 데이터 유형 검사가 없기 때문에 발생하는 일반적인 버퍼 오버플로우 오류가 발생할 가능성이 낮아집니다.가비지 콜렉터를 사용하면, 이러한 에러의 빈도를(완전하지는 않지만) 줄일 수 있습니다.
- .NET 프레임워크 Base Class Library - Managed C++는 모든 관리대상 함수 호출 및 상속된 클래스는 에서 파생되므로 표준 관리대상 코드보다 상세하지 않을 수도 있습니다.NET Framework Base Class Library(BCL, FCL 또는 Framework Class Library라고도 함). API는 TCP/IP 네트워킹 기능, 텍스트 조작 기능, 데이터 액세스(ODBC에서 SQL), XML 서비스(XSD에서 XSL), GUI 프로그래밍(Windows Forms), 메일 서비스(SMXTP)를 제공합니다.Natures), MSIL 생성(MSIL에서 기본적으로 명령을 출력), 파일 I/O, CLR 가비지 컬렉터의 수동 조작 및 WMI 콘솔을 조작하기 위한 관리 정보.
네이티브 코드보다 우위
- 관리 대상 코드와 관리 대상 외의 코드를 같은 CLI 어셈블리에서 심리스하게 혼재시킬 수 있습니다.이것에 의해, 프로그래머는, 에 포토 오버 할 수 없는 비관리 코드를 유지할 수 있습니다.NET Framework를 완전히 다시 작성하지 않아도 됩니다.다만, 이 하이브리드 규약을 사용하면 몇 가지 영향이 있습니다.
- Managed C++는 비관리 코드를 포함하고 다른 모든 코드와 네이티브하게 통신할 수 있는 유일한 언어입니다.NET 언어따라서 Managed C++는 를 포함한 다른 언어를 사용하는 프로그래머 간의 상호 운용성에 매우 편리합니다.NET Theater 및 표준 C++를 사용하는 사용자.
관리되지 않는 코드와 비교한 단점
- Managed C++는 특히 C++ 코드가 직접 포함되어 동일한 어셈블리에서 Managed C++ 코드와 직접 대화하는 경우 코드의 가독성을 해칠 수 있는 많은 새로운 키워드와 구문 규칙을 도입합니다.
- 관리 대상 C++는 C++/CLI로 대체되었기 때문에 C++/CLI가 표준화되었기 때문에 사용되지 않습니다.
완전 관리 코드와 비교한 단점
- Managed C++는 다른 C++보다 약간 긴 개발 시간을 필요로 합니다.같은 결과를 내는 프로젝트에 적용할 수 있는 NET 언어.관리 대상 C++에는 값 유형(_값 구조 및 __값 클래스)과 참조 유형(_gc 구조 및 __gc 클래스)이 모두 있기 때문에 포인터 사용은 필수일 수도 있고 필요하지 않을 수도 있습니다.
- 관리 C++는 ASP를 완전히 지원합니다.NET 웹 어플리케이션은 다른 어플리케이션보다 개발이 더 어렵지만NET 언어(다른 서드파티 언어 포함)
- 관리 대상 C++에는 템플릿(네이티브 C++와의 상호 운용성)만 지원되며 범용(다른 모든 C++와의 상호 운용성)은 지원되지 않습니다.NET 언어).C++/CLI는 템플릿(컴파일 시)과 범용 템플릿(실행 시)을 모두 지원합니다.
예
다음으로 Managed C++를 표준 C++와 비교하여 사용하는 예를 나타냅니다.
- (글로벌 변경) CLR을 통해 포트되는 기존 C++에는 다음 사항을 추가해야 합니다.
//hello.cpp //지시문을 사용하여 신규 생성 # < mscorlib > 를 사용합니다.dll> //네임스페이스 디렉티브를 사용하는 다른 명령어. 사용. 네임스페이스 시스템.; 인트 주된() { 콘솔::기입선("안녕, 세상아!"); 돌아가다 0; }
새로운 프리프로세서 디렉티브
# < mscorlib > 를 사용합니다.dll>
필수 항목입니다.게다가 베이스 클래스 라이브러리에서 더 많은 네임스페이스를 사용하기 위해 더 많은 라이브러리를 Import하려면 다음과 같은 #using Directive가 필요합니다.
#<시스템>을 사용합니다.창문들.Forms.dll >
그리고.
사용. 네임스페이스 시스템.::창문들::폼;
Windows Forms 를 사용합니다.
- CLR을 대상으로 하는 코드를 컴파일하려면 새로운 컴파일러 옵션을 도입해야 합니다.
cl.exe hello.cpp/clr
/clr은 를 참조하는 모든 코드를 활성화합니다.CIL로 컴파일되는 NET Framework.
- 클래스는 를 통해 수집되는 가비지로 지정할 수 있습니다.
__gc
extension 키워드
//syslog.cpp # < mscorlib > 를 사용합니다.dll> __개요 학급 gc { 인트* i; 차* g; 흘러가다* j; }; 인트 주된() { 하는 동안에 (진실의) { gc^ _개요 = 새로운 gc(); } 돌아가다 0; }
위의 코드는 메모리 누수의 염려 없이 컴파일 및 실행할 수 있습니다.왜냐하면 수업.gc
가비지 콜렉터에서 관리되기 때문에,delete
교환입니다.관리대상 외 코드에 대해서도 동일하게 하기 위해delete
키워드는 필수입니다.
//nogc.cpp 학급 gc { 인트* i; 차* g; 흘러가다* j; }; 인트 주된() { 하는 동안에 (진실의) { gc* _개요 = 신규 gc(); 삭제하다 _개요; } 돌아가다 0; }
주의:
- __gc 지정 클래스는 컨스트럭터를 선언할 수 있습니다.
- __gc 지정 클래스는 소멸자를 선언할 수 있습니다.
- __gc 지정 클래스는 여러 클래스를 상속할 수 없습니다.(이는 CLR의 제한입니다.)
- __gc 지정 클래스는 __gc 지정되지 않은 다른 클래스를 상속할 수 없습니다.
- __gc 지정 클래스는 __gc가 지정되지 않은 다른 클래스로 상속할 수 없습니다.
- __gc 지정 클래스는 임의의 수의 __gc 인터페이스를 구현할 수 있습니다.
- __gc 지정 클래스는 관리되지 않는 인터페이스를 구현할 수 없습니다.
- __gc 지정 클래스는 기본적으로 자체 어셈블리 외부에 표시되지 않습니다.사용하다
일반의 __개요 학급 이봐. { };
public 키워드를 지정하면 __discription 지정 클래스의 액세스가 변경됩니다.
__gc 지정 클래스는 delete 키워드를 사용하여 수동으로 파기할 수 있지만 __gc 지정 클래스에 사용자 정의 소멸자가 있는 경우에만 파기할 수 있습니다.
- 인터페이스는 __gc extension 키워드를 앞에 붙여 선언할 수 있습니다.예를 들어 다음과 같습니다.
//interface.cpp # < mscorlib > 를 사용합니다.dll> __개요 __인터페이스 클래스 베이스 { 무효 초기화(); 인트 흔한(); }
간단한 DLL 파일을 생성하려면 이전 코드를 /clr 및 /LD로 컴파일해야 합니다.
주의:
- __gc __인터페이스에는 데이터 멤버, 정적 멤버, 중첩된 클래스 선언 및 액세스 지정자를 포함할 수 없습니다.
- __gc __interface는 다른 __gc __interface 인터페이스 또는 시스템에서만 상속할 수 있습니다.: 오브젝트.시스템에서 상속:: 오브젝트가 기본 동작입니다.
- __gc __ 인터페이스는 선언된 함수 프로토타입의 구현(바디 코드)을 포함할 수 없습니다.
다른 언어와의 비교
다음은 Managed C++와 유사한 다른 잘 알려진 프로그래밍 언어 간에 다른 주요 포인트와 프로그래밍 표준을 포함합니다.
표준 C++
단점들
- 네이티브 C++ 코드는 실행 시 더 빠를 수 있습니다.
- C++는 대상 시스템에 관련 컴파일러 및 관리 런타임 환경을 설치할 필요가 없습니다.
- C++는 범용 프로그래밍을 지원합니다.단, C++/CLI의 최종 릴리스까지 Managed C++ 프로그래머는 제네릭 사용을 위한 회피책을 위해 복귀해야 합니다.
- C++는 키워드 "const"와 const correctness를 지원합니다.Java 나 C# 와 같이 관리 대상 C++ 에는, 이 기능은 포함되어 있지 않습니다.다른 방법으로는 매니지드클래스를 불변으로 하거나 퍼블릭인터페이스상의 세트액세서를 제한하는 방법이 있습니다.
- C++ 코드는 CLR의 제한에 의해 제한되지 않습니다.예를 들어 CLR에서는 클래스가 다른 클래스를 비공개로 상속하거나 보호받는 것을 허용하지 않습니다.따라서 다음과 같은 컴파일러 오류가 발생합니다.
일반의 __개요 학급 하나. { 인트 i; }; 일반의 __개요 학급 두명: 사적인 하나. { 인트 h; i = h; }; // 오류 일반의 __개요 학급 세개: 보호되고 있다 하나. { 인트 h; i=h;}; // 오류
- Managed C++ __gc 클래스는 여러 클래스에서 상속할 수 없습니다.그러면 다음과 같은 컴파일러 오류가 발생합니다.
__개요 학급 a {}; __개요 학급 b {}; __개요 학급 c: 일반의 a, 일반의 b {}; //오류가 발생합니다.
이점
- Managed C++는 일반 C++보다 더 큰 반사를 지원합니다.일반적으로 코드의 기능이나 코드의 목적에 따라 훨씬 편리합니다.
- 관리 대상 C++ 는, 다른 모든 것과 상호 운용할 수 있습니다.NET 대응 언어(다른 서드파티 언어 포함)
- 관리 C++ 가비지가 수집되었습니다.표준 C++에서는 메모리 관리와 할당은 프로그래머의 책임입니다.
자바
차이점.
- Java 코드를 실행하려면 적절한 가상 머신이 필요한 반면 Managed C++ 코드를 실행하려면 를 적절하게 구현해야 합니다.NET 프레임워크
단점들
- Java는 소스 코드에 대한 문서를 제공하지만 Managed C++는 제공하지 않습니다.
- Java에는 Java 프로그래머가 사용할 수 있는 다른 많은 개발 도구가 있는 반면 Managed C++는 Visual Studio에서만 사용할 수 있습니다.네트워크
이점
- Managed C++는 Java보다 낮은 수준의 인터페이스로 컴퓨터 시스템에 훨씬 쉽게 액세스할 수 있습니다.Java 프로그래머는 호스트 운영 체제의 낮은 수준의 서비스를 사용하려면 JNI(Java Native Interface)를 사용해야 합니다.
C#
차이점.
- C#은 C++와 마찬가지로 포인터를 지원하지만 이 기능은 기본적으로 비활성화되어 있습니다.
단점들
- Java와 마찬가지로 C#은 관리 코드를 다룰 때 구문적으로 더 단순합니다.
- C#은 기본적으로 Managed C++와 동일한 결과를 얻을 수 있습니다.통사 규칙과 구조 규칙이 모두 현저하게 유사하기 때문입니다.
- Managed C++는 CLR에 도입되어 있기 때문에 강력한 타입의 언어이지만 C#은 순수 MSIL인 반면 관리되지 않는 컴파일된 코드가 같은 코드베이스에 도입되면 오류가 발생하기 쉽습니다.
이점
- C#은 를 사용해야 합니다.NET Framework 및 클래스 라이브러리를 제공하여 컴퓨터 시스템에 저레벨로 액세스 할 수 있도록 했습니다.
- 에의 애플리케이션상의 이식.C 또는 C++의 NET Framework는 Managed C++를 사용하면 훨씬 쉽게 실행할 수 있습니다.
- Microsoft Visual C++.NET 컴파일러: Managed C++를 컴파일하여를 대상으로 합니다.NET Framework는 그 결과 어셈블리에서 훨씬 더 성숙한 명령어 세트를 생성하여 성능을 향상시킵니다.
「 」를 참조해 주세요.
레퍼런스
- ^ "Translation Guide: Moving Your Programs from Managed Extensions for C++ to C++/CLI". Microsoft. August 2004. Retrieved 2009-11-11.
- ^ Sutter, Herb. "A Design Rationale for C/C++" (PDF). p. 6. Archived (PDF) from the original on 2017-08-30. Retrieved 2018-06-12.