UFO ET IT

C ++ / CLI : 왜 사용해야합니까?

ufoet 2021. 1. 14. 07:50
반응형

C ++ / CLI : 왜 사용해야합니까?


저는 C ++에 익숙하기 때문에 .NET과 모든 파생물 (특히 C #)을 배우는 것을 고려했습니다.

그 과정에서 C ++ / CLI에 부딪 혔는데 해당 언어에 특정 용도가 있는지 알고 싶습니다. 네이티브 C ++에서 C #으로 변환하기위한 중간 언어라고 가정합니까?

내 머리에 떠오른 또 다른 질문은 왜 .NET 프레임 워크에 여전히 많은 프로그래밍 언어가 있는가? (VB, C ++ / CLI, C # ...)


예, C ++ / CLI는 매우 구체적인 대상 용도를 가지고 있습니다. 언어 (및 그 컴파일러 등)를 사용하면 관리되지 않는 코드와 상호 운용해야하는 코드를 매우 쉽게 작성할 수 있습니다. 관리되는 형식과 관리되지 않는 형식 간의 마샬링을 기본적으로 지원합니다. 예전에는 IJW (It Just Works)라고 불렸지만 요즘에는 C ++ Interop이라고합니다. 다른 언어는 C ++ / CLI가 수행 할 수있는 작업에 비해 비효율적이며 제한된 기능을 가진 P / Invoke 마샬 러를 사용해야합니다.

네이티브 C ++, 인스턴스 함수가 ​​있고 클래스의 인스턴스를 생성 / 파괴하기 위해 new 및 delete 키워드가 필요한 클래스와 상호 운용해야하는 경우 C ++ / CLI를 사용할 수밖에 없습니다. Pinvoke는 그렇게 할 수 없으며, C ++ 컴파일러 만이 할당 할 메모리 양과 this인스턴스 함수에 대한 포인터 를 올바르게 썽 크하는 방법을 알고 있습니다.

.NET 프레임 워크에는 C ++ / CLI, 특히 System.Data 및 WPF의 PresentationCore로 작성된 코드가 포함되어 있습니다. 관리되지 않는 interop 요구 사항이 없거나 레거시 코드 기반으로 작업 할 필요가없는 경우 C ++ / CLI를 선택해야하는 몇 가지 이유가 있습니다. C # 또는 VB.NET이 더 나은 선택입니다. C ++ / CLI의 기능 세트는 2005 년경 동결되었으며 람다 또는 Linq 구문과 같은 최신 추가 기능을 지원하지 않습니다. IDE는 C # 및 VB.NET IDE에서 사용할 수있는 많은 종소리와 휘파람을 지원하지 않습니다. 주목할만한 점은 VS2010이 처음에 C ++ / CLI에 대한 IntelliSense 지원없이 제공된다는 것입니다. 거기에 약간의 죽음의 키스.

업데이트 : VS2012에서 부활, IntelliSense 지원이 돌아 왔습니다. C ++에서 WinRT 앱 작성을 단순화하는 언어 확장 인 C ++ / CX 덕분에 최소한은 아닙니다. 구문은 C ++ / CLI와 매우 유사합니다. Windows Forms 프로젝트 템플릿이 제거되었지만 디자이너는 계속 작동합니다. VS2012의 새로운 디버깅 엔진은 C ++ / CLI를 지원하지 않습니다. 도구 + 옵션, 디버깅, 일반에서 "관리되는 호환성 모드"옵션을 켜야합니다.


첫 번째 C #은 .NET의 '파생'이 아닙니다. .NET은 언어가 아니라 여러 언어가 존재하는 CLR을 기반으로하는 응용 프로그램 프레임 워크 및 클래스 라이브러리입니다.

즉, .NET을 사용하는 가장 매력적인 이유는 잘 설계된 클래스 라이브러리이고 Win32 또는 MFC보다 Windows 용으로 개발하는 것이 훨씬 더 쉽다는 것입니다. 그러나 저는 개인적으로 이전 언어에 대한 확장을 배우는 것보다 새로운 언어를 배우는 것이 더 좋겠다고 결심했고 C #은 처음부터 .NET과 함께 작동하도록 설계 되었기 때문에 이것이 .NET에서 선택하는 언어라고 제안합니다.

C ++ / CLI는 레거시 코드와 함께 .NET을 사용하려는 경우 유용하며 Windows Forms GUI를 만들고 기존 응용 프로그램 코드에 연결하는 데 사용했습니다. 다른 이유 는 단일로드 모듈에서 혼합 관리 코드와 네이티브 코드를 지원하는 유일한 .NET 언어이므로 레거시 코드의 성능과 재사용 모두에 좋습니다.

언어 수와 관련하여 Microsoft는 모든 Windows 응용 프로그램이 .NET을 기반으로하기를 원합니다. .NET이 OS의 보안과 안정성에 더 좋기 때문입니다. 유일한 방법은 여러 언어를 지원하는 것입니다. .NET을 응용 프로그램 플랫폼 또는 OS API로 생각하면 그 질문은 의미가 없습니다. 모든 플랫폼에 많은 언어가있는 것과 같은 이유로 .NET에 대한 많은 언어가있을 것입니다. 그 이유는 상업적 이점, 응용 프로그램 적합성, 정치, 기존 개발자 지원, 선택 및 의심의 여지 없음을 포함하여 많습니다.


Microsoft는 이에 대한 입장을 몇 번 변경했습니다. 원래본격적인 언어로 의도되었으며, 기본적으로 모든 네이티브 개발자가 가능한 한 네이티브 C ++를 버리고 이동하기를 원했던 것입니다.

몇 년 전, 그들은 이것이 단순히 고객이 원하는 것이 아님을 깨달았습니다. 어쨌든 .NET으로 이동하는 개발자는 일반적으로 C #과 같은 언어로 이동하고 나머지는 코드를 네이티브 환경에 유지 해야하는 이유가 있으므로 C ++를 사용합니다.

따라서 이제 Microsoft는 C ++ / CLI가 네이티브 C ++ 코드와 일부 .NET 언어로 작성된 관리 코드 사이의 "브리지"가되기를 원합니다. 더 이상 전체 코드베이스를 전환하도록 권장하는 언어가 아닙니다.


실제로 주로 .net 코드를 관리되지 않는 네이티브 C ++와 쉽게 연결하기위한 중간 언어로 사용됩니다. 자신에게 호의를 베푸십시오. 필요하지 않으면 사용하지 마십시오. C ++ / CLI 구문은 엉망입니다.

두 번째 질문에 관해서는 ... 오늘 C #이 .net에서 지배적 인 언어라고 생각하지만 모든 사람이 스타일과 패러다임을 좋아하는 것은 아닙니다. .net의 아키텍처를 사용하면 새 언어를 쉽게 추가 할 수 있습니다 (함수 프로그래밍을 목표로하는 F # 참조).


C ++ / CLI를 사용하여 관리되지 않는 일부 C ++ 라이브러리에 대한 .NET API를 만들었습니다. 매개 변수의 전달과 마샬링은 익숙해지는 데 약간의 시간이 걸리지 만 (사용 된 유형에 따라 다름) 일단 익숙해지면 관리되는 세계와 관리되지 않는 세계 사이의 간격을 메우는 좋은 방법입니다.


저는 C ++ / CLI를 보지 않았지만 .NET 세계를 활용합니다. 두 세계의 장점을 모두 갖춘 C ++와 C #의 중간이라고 생각하면됩니다. .NET 개체에 쉽게 액세스 할 수있는 C ++를 사용하려는 상황에서 유용 할 수 있으며 핵심 BCL입니다. 여기에서 C ++ / CLI의 입문서에 대해 설명하는 기사를 살펴보십시오 . 불행히도 저는 Managed C ++ 응용 프로그램에 대해 들어 본 적이 없습니다.이 응용 프로그램은 구문 측면에서 많은 C ++ 친구를 혼란스럽게하고 관리되지 않는 C ++ 세계로 돌아간 추종자 모임을 잃었습니다.

이것이 도움이되기를 바랍니다. 안부, Tom.


저에게는 C ++ 클래스를 재사용 할 다른 방법이 없을 때 사용해야합니다.


알다시피. 컴파일 할 코드를 관리되지 않는 것으로 지정하지 않는 한 CLR 지원을 사용하여 컴파일 할 때 관리 코드로 컴파일됩니다.

CLI C ++는 좋습니다. 코딩하는 것이 고통 스럽습니다. 프로그래밍하고 싶지 않은 것이 있습니다. "^"도 아닙니다. 깨진 .net을 사용하는 것과 같습니다. C #에서 10 분이 걸리는 완전히 관리되는 무언가를 코딩하는 데 40 분을 보냈습니다. 내 말은, 가끔은 C #을 포기하고 사용하는데, 코딩 할 때 실망하기 때문입니다. .net을 사용하려는 경우 C # (CLI C ++ 사용)을 사용할 수도 있습니다.

참조 URL : https://stackoverflow.com/questions/1933210/c-cli-why-should-i-use-it

반응형