The Design of C++0x

The Design of C++0x는 Bjarne Stroustrup이 CUJ 2005년 5월호에 기고한 글이다. C++0x 디자인의 기본적인 정책에 대해 설명하고 있다.

먼저 C++0x에서의 언어 디자인에 관해서는 최대한 호환성을 고려할 것이지만, 충분한 이익을 얻을 수 있는 부문이라면 호환성에 있어서의 작은 희생도 감수하겠다고 얘기하고 있다.

C++0x will be almost 100-percent compatible with the existing Standard C++. … We aim for compatibility but realize that there may be cases where a large advantage is worth paying for by small incompatibilities.

그리고, C++의 강점은 일반성(generality)라고 얘기하고 있고, 이러한 장점을 강화하는 방향으로 갈 것이라고 얘기하고 있다.

C++’s emphasis on general features (notably classes) has been its main strength, and often its lack of specialized features (such as “properties” and threads0 has been seen as its main weakness. … Nevertheless, we must keep the focus on general features aimed at efficient abstraction; the huge diversity of the C++ community requires that. … The obvious areas where C++ could be improved for greater generality is through better support for generic programming and more flexible initialization/construction mechanisms. Is is also obvious that some support for concurrency is needed as many forms of concurrent, parallel, and distributed programming are becoming common.

프로그래머가 프로그래밍 언어를 대하는 태도에 관한 짤막한 의견.

You don’t want to become a language expert-you want to be (or become) an expert in your own field and know just enough of some programming language to get your work done.

type safety는 compiler optimization 등의 이점을 얻기 위한 중요한 C++의 특성임을 강조하고 있다. 언어의 변경을 위해서 완벽한 type safety를 얻기는 힘들지만, 표준 라이브러리를 통해서 이를 강화하겠다고 얘기하고 있다.

C++0x will not be able to close all the loopholes in the C++ type system, but it will not introduce new holes and it will provide ways of avoiding inherently unsafe facilities-primarily through the Standard Library providing (compile-time or run-time) type-safe alternatives.

C++의 중요한 원칙 중의 하나인 zero-overhead principle을 재확인하고 있다.

That is, the zero-overhead principle: “what you don’t use, you don’t pay for” and “what you use can be implemented without overhead compared with hand coding” is still the bedrock of C++.

라이브러리의 중요성.

A language cannot support everything, but conceivably, a large set of libraries could. … Library extensions will be preferred to language extensions.

표준 결정 과정에서 벤더들에 대한 고려(예를 들어 구현의 용이성)도 중요한 요소임을 강조하고 있다.

The development of C++0x must be timely and to gain acceptance from vendors, new language features must be easier to implement that the most difficult C++98 features. … we dislike dialects. … My suggestion is for programmers to avoid nonstandard features whenever possible.

C++ Programming Language를 읽어보신 분이라면, C++0x 또한 C++의 기본 철학에서 크게 벗어나지는 않는다는 것을 알 수 있을 것이다. 특히 눈에 띄는 점은 라이브러리에 대한 강조.

Whereas we’ll be cautious and skeptical about language extensions, we’ll be aggressive and opportunistic when in comes to new library-especially for libraries that extend the range of portable support for systems programming.

The New C++: Part I

Introduction

소프트웨어 개발자가 선택하는 언어는 개발 패러다임이 변화함에 따라, 어플리케이션 도메인이 변화함에 따라, 또는 외부적인 기술 변화에 따라 계속 변해왔다. 현대의 프로그래밍 언어에서는 이러한 변화가 비단 언어간의 선택에만 반영되는 것이 아니라, 이미 존재하는 언어에도 변화를 요구하는 것이 사실이다.

이 사실은 C++ Programming Language에 있어서도 예외가 아니다. 1998년에 처음으로 C++ Programming Language의 공식적인 표준 (ISO/IEC 14882:1988 International Standard. C++98)이 제정된 이후로 꾸준히 bug fix들이 – 이러한 bug fix 가운데 하나는 std::vector의 internal storage가 contiguous해야한다는 requirement가 추가되어야 한다는 것이다. 그래야만, 프로그래머는 vector 내의 한 element로의 pointer를 얻은 후 array처럼 pointer 연산을 통해 traverse할 수 있다 – 이루어져와서 작년(2003년)에 TC1을 포함한 새로운 표준 (ISO/IEC 14882:2003 International Standard. C++03)이 발표되었다.

현재 C++ Standards committee는 C++0x 표준안에 노력을 기울이고 있는데, 여기에는 기존과는 달리 C++의 언어 자체상의 변화와 표준 라이브러리 (흔히 STL이라고 불리는.. 이는 잘못된 이름이다) 상의 변화를 수반하고 있다. C++ Programming Language를 사용해서 개발하는 프로그래머라면, 이러한 변화에 대해서 미리 알고 있다면, 그동안, C++에서 부족했던 feature에 대해서 보완할 때, 미래의 C++을 미리 고려해서 결정할 수 있을 뿐만 아니라, C++이라는 언어가 현재까지 가져왔던 철학뿐만 아니라 앞으로 가질 철학에 대해서도 더욱 잘 이해할 수 있으리라고 믿는다.

이를 위해서 ISO C++ Standards committee의 의장(convener)이자 Exceptional C++/More Exceptional C++의 저자이면서 Micorosoft에서 Visual C++ architect로 일하고 있는 Herb SutterCUJ에 기고한 The New C++ 칼럼을 이해하기 쉽도록 정리해서 적어보고자 한다.

ISO C++ Standard Committee

ISO C++ Standard Committee에서 하고 있는 일들의 진행상황은 여기에서 볼 수 있다. 언어 자체상의 issue들 (The C++ Standard Core Issues List)이나 표준 라이브러리상의 issue들 (The C++ Standard Library Issues List), 또는 TR1에 들어갈 표준 라이브러리 extension의 draft 등을 해당 사이트에서 찾아볼 수 있다.

Issues List를 참고할 때, Issue들의 종류에는 크게 세가지가 있다.

  • Defect Reports: committee가 표준안 상에서 수정이 필요하다고 동의한 것들이다.
  • Active Issues: 현재 고려중인 issue들이다. 저번 meeting에서 제기된 새로운 issue들과 논의되고 있던 issue들뿐만 아니라, commit하기 전에 더 많은 작업을 필요로 하는 issue들도 필요로 한다.
  • Closed Issues: 더이상의 작업(표준상의 변화)이 필요없는 issue들이다.

The C++ Standards meeting에서 주로 작업하는 것들에는 다음과 같은 것들이 있다.

  • Defect Reports (DRs): 전체 미팅 시간의 반 정도를 현재의 표준안에 대한 질의에 대답하고 버그를 찾는데에 할당한다. TC1 (Technical Corrigendum 1) 이후의 bug fix들은 TC2 또는 C++ 표준안의 다음 revision인 C++0x에 들어가게 될 것이다.
  • Performance Technical Report (Performance TR): 하드웨어나 embedded system을 물론 C++ implementability (예를 들어 exception을 어떻게 좋은 성능으로 구현 및 사용할 것인가)에 초점을 맞추고 있다. 이 TR은 C++0x에 들어갈 예정이다.
  • Library Technical Report (Library TR): 표준 라이브러리에 새로운 기능을 추가하는 것에 대해서 다룬다. 특히, 언어 자체에 추가사항을 필요로 하지 않는 것에 대해서만 다루고 있다. 이 TR은 C++0x에 들어갈 예정이다. Library TR에서 다루는 대부분의 기능은 Boost에 구현되어있다. (그렇다고 해서 Boost의 구현이 표준이 되리라고 보장할 수는 없다는 점을 유의)
  • Evolution Working Group (Evolution WG): Library TR이 다루지 않는, 즉 언어 자체에 추가사항을 필요로 하는 것들을 다룬다.

이번에는 소개와 C++ Standards committee에 대해서 소개하는 내용밖에 없었지만 다음부터는 C++0x에 들어갈 내용 중, 프로그래머에게 가장 관심이 있을 부분인 Library TR와 Evolution WG에 approve된 내용들을 다루려고 한다. 일단 Part II에서는 현재 Libary TR과 Evolution WG에서 다루고 있는, 다음 내용들에 대한 간단한 설명부터 시작하고, 이후에 각각의 issue에 대해서 자세한 article을 써보는 것도 괜찮을 것 같다. C++에 관심있는 개발자라면, 간단히 적어놓은 아래의 리스트만 보아도 누구나 눈에 띄이는 내용들일 것이다.

  • Library TR
    • Smart pointers (shared_ptr, weak_ptr)
    • Tuple types (tuple)
    • Generalized function pointers (function)
    • Nearly complete C99 library compatibility
    • Hash-based container (unordered_set, unordered_map, unordered_multiset unordered_multimap)
    • Type traits (alignment_of, has_nothrow_copy, has_virtual_destructor, is_base_of, is_const, is_convertible, ..)
    • Regular expressions (basic_regex)
    • Random-number generation(random_device, poisson_distribution)
  • Evolution WG
    • C99 harmonization (long long, #scope/#endscope, ..)
    • Delegating constructors
    • Static (compile-time) assertions
    • Explicit conversion operators.
    • nullptr
    • Strongly typed enums

References