원문: http://www2.research.att.com/~bs/bs_faq.html#CppCLI
저자: 비아르네 스트로우스트룹(비야네 스트롭스트룹, Bjarne Stroustrup)
기록:
2007년 4월 - 최초 번역
2011년 2월 - 갱신
C++/CLI는 ISO C++가 확장된 것으로, 마이크로소프트의 CLI(Common Language Infrastructure)를 지원하도록 C++에 매우 완벽한 "바인딩"을 제공한다. 그리고, ECMA (ECMA-372)가 표준화하였다. 개인적으로는 C++에서 쉽게 CLI의 모든 기능을 사용할 수 있어서 기쁘고, 조상격인 "Managed C++"보다 훨씬 더 나은 언어라서 기쁘게 생각하고 있다. 하지만, C++/CLI이 CLI의 기능(인터페이스, 프로퍼티, 일반화, 포인터, 상속, 열거형, 그 외에도 아주 많음) 각각에 해당하는 C++의 개별적인 언어 기능을 본질적인 측면에서 확장함으로써 그 목표를 달성하고 있다는 점은 마음에 들지 않는다. 이는 중대한 혼란을 초래하는 요소가 될 것이다(사용할 때든 의사소통할 때든). ISO 표준 C++에 비해서 C++/CLI에 추가된 많은 새로운 언어적 요소는 프로그래머들이 이식성 없는 코드를 작성하게끔 (알게 모르게) 부추기고, 그 코드는 마이크로소프트 윈도 환경에 깊숙이(intimately) 종속된다.
CLI는 시스템 기능을 지원하는 인터페이스 집합을 제공하는데, 과거의 운영 체제나 응용 소프트웨어에서 볼 수 있는 인터페이스와 비교해서 매우 다르다. 특히, 이러한 인터페이스는 전통적인 프로그래밍 언어로는 완전히 적합한 형태로 표현할 수가 없다. CLI를 표현하는 또 하나의 방법은 (부분적인) "플랫폼" 또는 "가상 머신"같은 것이다. CLI는 언어적인 기능(상속, 메서드, 루프 생성, 콜백 메커니즘, 등)의 커다란 집합으로 구성되어 있고, 거대한 기반 라이브러리(BCL[1]) 외에도 복잡하고 정교한 메타데이터 시스템를 지원한다. 종종 CLI를 "언어 중립적"으로 표현한다. 하지만, 이런 커다란 기능의 집합을 수용하지 못하는 언어는 기본적인 닷넷 기능조차 사용할 수 없다(마이크로소프트의 계획이 바뀌지 않는 한, 앞으로의 윈도 기능도 사용할 수 없다). 그리고, 이 모든 기능을 표현할 수 없는 언어는, 또 다른 언어에서 사용 가능한 리소스조차도 구현할 수 없다. 그러므로, 닷넷 환경에서 모든 언어가 "최고급 언어(first-class)"가 되기 위해서 CLI의 기능을 전부 지원하는 상황에서만 "언어 중립적"이라고 할 수 있겠다.
개인적으로는 매우 적은 부분에만 기초하는 바인딩이 좋다. 어떤 언어로든 간단한 함수 호출이나 간단한 자료 구조를 표현할 수 있고, 아마 언어에 특화된 라이브러리에 내장되어 있어야 하겠다. CLI에서 이 관점은, 기껏해야 CLI 기능만 사용하는 사람만이 만족할 수 있다. CLI 모듈을 제작하는 데 사용되는 언어는 메타데이터를 포함해서 모든 CLI 기능을 표현할 수 있어야만 한다. 이렇게 할 수 있는 언어만이 닷넷 환경의 시스템 프로그래밍 언어가 될 수 있다. 그러므로, 마이크로소프트의 C++ 팀은 언어에 내장된 요소를 추가하는 것만이 사용자가 수용할 수 있을 것이라고 결론지었다. C++ 팀의 설계는 C++/CLI 확장을 통해 C++로 CLI 기능들을 표현하는 데에 있어서 어떠한 제약도 허락하지 않으며, CLI 기능을 사용할 때 다른 언어와 비교해서 표현이 장황해서도 안 되고 오버헤드도 없어야 한다는 관점을 반영하고 있다. C++ 팀은 C++ 언어를 윈도 환경에서 주요한 시스템 프로그래밍 언어로 유지하는 것을 목표로 한다.
나는 여전히 이식성을 매우 중요하게 생각하고 있으며 시스템에 의존적인 기능들은 ISO C++에 명시된 대로 잘 정의된 인터페이스를 통해서 접근하는 방식으로 응용 소프트웨어를 설계하도록 권장하고 있다(예를 들어, C++/CLI를 직접적으로 사용하지 않는 것). 윈도에서는 C++/CLI 기능들을 직접적으로 사용하는 방법에 비해 다소 불편할 것이다. 하지만, 이는 이식성을 유지하고 특정 벤더에 종속되지 않을 수 있는 유일한 방법이다. 다른 코드가 사용할 CLI 인터페이스를 제공하는 것이 목적이라면, CLI로의 손쉬운(arms-length) 접근 방식이 계속 유지될 수 없다는 것은 명백하다. 내가 시스템 의존적인 기능에 대한 요구를 알고 있다는 점과, 마이크로소프트가 그러한 기능을 제공하는 유일한 C++ 벤더가 아니라는 점을 말하고 싶다. 단지 ISO C++에 명시된 "간소한(thin) 인터페이스"를 통해서 확장 기능을 다뤄 주기를 강력히 바라고 있을 뿐이다.
시스템 의존적인 기능을 어떻게 다루어야 하는지는 본질적으로 어려운 문제다. 마이크로소프트 C++ 팀은, 특히 허브 슈터는, ISO C++ 표준 위원회 구성원과 활발한 대화를 유지했고, ISO C++와 그 상위 집합인 C++/CLI의 관계는 결국 정리가 될 것이다. 우리는 ISO C++ 위원회에서 있었던 건설적인 공동 작업물에 대한 많은 기록을 가지고 있다. 또한, ISO C++와 C++/CLI 확장 사이의 혼란을 최소화하도록, 마이크로소프트는 ISO C++와 C++/CLI를 명확하게 구분하기 위한 노력으로 Visual C++ 문서를 재고하고 있다(그냥 C++은 ISO C++을 의미한다). 다른 사람은 그 주도(lead)를 따라주길 바란다.
C++로부터의 CLI 바인딩과 확장 기능을 뭐라고 불러야 하는지에 대한 질문은 까다롭고 논쟁의 여지가 있는데, 나는 "ISO C++로부터의 CLI 확장"을 줄인 형태인 C++/CLI를 선호한다. C++ 문구를 포함하는 것은 사람들에게 무엇이 기반이 되는 언어인지 상기시켜주고, C++/CLI 확장을 포함한 C++에서 C++ 언어가 적절한 부분집합으로 남게해 준다. C/C++ 호환성 문제는 부분집합의 속성을 유지하는 것이 얼마나 중요한지 설명하고 있다.
다음은 C++/CLI에 관련된 몇 가지 문서이다:
영국 ISO C++ 패널의 이의 신청 (약간의 코드 예제 포함).
[1] (역주) BCL: Basic Class Library의 약자로, 닷넷 프레임워크의 기반이 되는 클래스 라이브러리.