C++

<syntaxhighlight lang="cpp" line="1">

  1. include <iostream>

int main()
{
std::cout << "Hello, world!\n" ;return 0;
}
</syntaxhighlight>

{

TIOBE에서 선정한 프로그래밍 언어 월간 점유율 순위 (2017년 3월 기준)
자세한 내용은 이곳에서 확인할 수 있으며, 점유율을 정하는 기준은 다음과 같다.
1. Java2. C3. C++4. C\#5. Python
점유율 16.384%
작년 대비 4.14% 감소		점유율 7.742%
작년 대비 6.86% 감소		점유율 5.184%
작년 대비 1.54% 감소		점유율 4.409%
작년 대비 0.14% 증가		점유율 3.919%
작년 대비 0.34% 감소

1 개요

1983년 C 언어에서 직접적으로 파생된 프로그래밍 언어. 비야네 스트롭스트룹(Bjarne Stroustrup)[1]이 1980년대 C언어를 바탕으로 만든 언어이다. 참고로 C 계열 언어에서 "++"라는 것은 1을 더해서 원래 변수에 대입하라는 뜻이다.

쓸 때는 C++라고 쓰고 읽을 때는 시 플러스 플러스, 혹은 씨플플 이라고 읽는다. 연세가 꽤 있으신 교수님 중에는 간혹 C 더블 플러스라고 읽는 경우도 있다. 미국에서는 그냥 C plus plus 라고 읽는다. plus는 1음절이지만 한국어식으로 발음하면 3음절이 필요하다.

2 C와의 차이점

C의 문법에 OOP 개념을 추가하고 일반화 프로그래밍의 요소가 되는 STL을 붙였다. 그래서 대부분의 C 프로그램은 C++ 컴파일러에서도 문제없이 컴파일된다. 초기 C++ 컴파일러는 일단 C++ 코드를 C로 변환하고 그걸 C로 컴파일하는 방식을 사용했을 정도. 하지만 OOP나 일반화 프로그래밍이란 것은 단순한 문법이 아니라 코딩의 패러다임을 말한다. 그래서 C++ 방식으로 코딩하려면 해당 코드에서 C++에 새로 도입된 것을 추가하는 게 아니라 설계부터 시작해서 완전히 새로 해야 하는 경우가 많으므로, 초심자 입장에서는 서로 다른 별개의 언어로 보고 접근하는 것이 안전하다. 그래서 C로 프로그래밍에 발을 들어 놓은 후 C++/Java로 업그레이드(...) 테크를 타는 학생에게 C++ 프로그래밍을 해 오라 하면, 잘해봐야 C++의 입출력 객체를 이용하는 정도를 넘지 못하고 절차적 프로그래밍을 그대로 따라가는 영락없는 C 프로그램이 튀어나오기 일쑤다.

그 이유는 C++의 객체지향이 이해하기가 그렇게 만만한 개념이 아닌 데다가 C++의 객체지향은 C를 유지하면서 그대로 얹어놔서 기묘하기 그지없으므로 다른 객체지향 언어에서보다 잘 다루는데 더 많은 공부가 필요하다. 재밌는 것은, 반대로 C++ -> C 테크도 만만치가 않다.[2] C++이 C의 모든 기능을 포괄하고 있으므로 C++을 할 줄 알면 C도 할 줄 안다고 생각하기 쉽지만, 사실 C++ 이 명시적으로 비교적 간단히 사용할 수 있도록 제공하는 기능들을 C에서는 암묵적으로 여러가지 수많은 '트릭'을 통해서 쥐어짜 내듯이 만들어 사용하는 경우가 많다.[3] incomplete type declaration 트릭을 이용하여 캡슐화를 흉내내고, 매크로와 컴파일러 확장을 이용해서 type-generic function을 만들어 쓰고, struct hack을 이용하여 vector를 흉내 내는 식이다. 게다가, 저런 트릭은 언어 차원에서 정식으로 제공한다기보다 말 그대로 '트릭'에 가까우므로 이상한 조건들이 붙는 경우가 종종 있고, 그것들을 정확히 파악하고 있지 않으면 상당히 찾아내기 어려운 에러를 내는 경우도 많다. 말 그대로 C와 C++은 완전히 다른 언어로 파악하고 접근하는 것이 좋다. "잘 짜인 C 프로그램은 C++ 컴파일러로 컴파일할 수 있어야 한다"는 말도 C99가 나오면서 틀린 말이 되어버리기도 했고....

그래서 많은 대학에서 컴공 1학년 때 C를 먼저 가르치고 C++를 가르치지만, 교수가 절차지향이 머�리에 굳어버린다고 컴공에서 C 대신 C++ 과 객체를 먼저 가르치고 C는 아예 건드리지도 않고 다른 하드웨어 관련 학과에서만 가르치는 대학들도 많다. 객체지향만 배운다면 파이썬으로 가도 되지만, 포인터 등을 통해 메모리와 각종 Low Level 적인 프로그래밍과 객체지향을 함께 배울 수 있으니까....

C++는 서식을 이용한 일반화 프로그래밍을 악용[4]응용해서 컴파일 시점에 계산 등을 하는 TMP(Template MetaProgramming)이라는 것이 존재한다. 배우기는 어렵고 알아보기도 힘들고 오류 찾기도 힘들지만 알아 두면 은근 써먹을 데가 많다. O(1)의 위엄! 하지만 여차하다가 바이너리 크기가 n배 증가하는 대참사가 벌어질 수도 있다. 잘만 구현하면 실행 시간을 잃지 않으면서도 컴파일 시점에 다양한 처리나 계산이 가능하므로 라이브러리 구현에 종종 이용된다.[5] 이는 C++ 템플릿의 고유한 기능[6]을 이용하는 것으로 다른 언어에서는 비슷한 것도 찾기 힘들다.[7]

3 C++에서의 객체지향

C++은 객체지향 프로그래밍을 지원하지만, C++의 객체지향은 다른 객체지향 언어에서와는 성격이 좀 다르다. 대부분의 객체지향 언어에서는 많은 부분을 런타임에 처리하며 메모리를 자동으로 관리하는 반면, C++에서는 최대한 많은 것을 컴파일 타임에 처리하는 것을 지향하며 메모리 등을 프로그래머가 직접 관리하게 하기 때문에 전반적인 클래스 디자인 자체가 상당한 차이를 보이게 된다. Java 등의 다른 객체지향 언어에서와 같은 방식으로 C++ 클래스를 디자인하면 거의 틀림없이 컴파일이 제대로 안 되거나 메모리 문제가 발생한다. JAVA->C++ 테크를 탄 학생이라면 처음에는 메모리가 줄줄 새는 프로그램을 만들게 될 것이다. 반면 C++ 스타일로 다른 객체지향 언어에서 프로그래밍을 하는 경우 특별히 안 될 것은 없지만[8], 해당 언어의 스타일로 작성한 코드에 비해 시간이 많이 걸리고 너저분해 보이며 클래스 구조가 경직되어 수정하기 어려워진다.자바를 배우고 C++을 배우는 학생들은 C++이 객체지향인듯 객체지향아닌 객체지향같은 언어라서 공부를 던진다 카더라

대표적인 예가 함수 내부에서 객체를 동적으로 생성해서 그 포인터를 리턴하는 것. C++에서는 이는 메모리 문제를 일으키기 딱 맞는 방식이라서 클래스 디자인 단계에서 이런 종류의 함수가 필요없게 하기 위한 고려가 필요하지만[9], 가비지 컬렉션이 자동으로 되는 언어에서는 매우 흔히 사용되는 방법이다. 이런 차이 때문에, Java, Smalltalk 등의 언어를 먼저 접한 프로그래머들은 C++의 객체지향이 짝퉁이라며 싫어하기도 한다. 다만 이런 제한이 생기는 건 오래된 스타일의 C++ 코드에서나 그런 것이고, Modern C++에서는 스마트 포인터를[10] move하는 방식으로 완전히 같은 문법이 구현 가능하기 때문에 더이상 해당이 없는 사항이다.

이러한 차이가 생기는 것은 대부분의 객체지향 언어는 직접적으로 Smalltalk의 영향을 받은 반면, C++는 Smalltalk의 보다 먼저 객체지향의 초보적인 개념을 제시한 시뮬레이션 전용 언어인 Simula에서 직접 영향을 받았기 때문이다. 이는 C 프로그램과의 호환성을 고려한 결과이기도 하지만, 기본적으로 C++에서 프로그램의 성능을 희생시키지 않기 위해서였다. Smalltalk의 경우 당시의 기술적 한계도 있고 해서 C보다 대체로 수십 배 정도 느렸고, 이는 C++에서 지향하는 결과가 아니었기 때문이다.

객체지향 등이 일반화되면서 프로그래밍 환경도 점차 중요한 개념을 언어 안으로 숨기고 사용자에겐 그것을 간편히 다룰 수 있는 인터페이스만 제공하는 추세로 흘러가고 있는데, 이런 방식은 일반적인 상황에서 생산성을 높이기는 좋지만 특정한 상황에서 속도를 높이기는 어렵다. 일반적으로 만들려면 필연적으로 많은 상황을 처리할 수 있도록 강력하고 복잡하게 만들어야 하기 때문이다. 따라서 특정 목적이 필요할 경우 언어에서 쌓은 추상화의 장벽을 뚫고 하위(low level) 개념을 이용할 필요가 있다. 아마도 이것이 어째서 메모리 관리를 알아서 해 주는 자바를 하면서 메모리 관리를 알아야 하고, C++를 하면서 C를 알아야 하고, C를 하면서 하드웨어 아키텍처를 알아야 하는지에 대한 답일 것이다.

4 성능

일반적으로 추상화 수준이 높은 언어일수록 프로그래머 머리로 해야할 구체적인 것들을 컴퓨터가 대신 해주고, 이것이 항상 최적화된 방식은 아니기 때문에 프로그램의 실행 속도가 상대적으로 느리게 마련이지만, C++ 프로그램은 성능 하락이 거의 없다. 좀더 정확히 말하자면 C 가 제공하던 머신컨트롤의 저수준 작업들을[11] 포기하지 않고 그대로 지원하면서 그 위에 여러가지 추상적인 고수준 기능들을 집어넣어 추상적인 시스템 위에서만 노는 게 아니라, 저수준의 기계 제어까지 가능한 추상화라는 요상한 철학을 지지한다. 그래서, 자바 같은 언어들이 OOP를 구현하면서 동적 바인딩(가상 함수)을 디폴트로 쓰고 쓰레기 수집을 지원할 때 C++은 정적 바인딩을 디폴트로 하고 수동 메모리 관리를 유지한 것이다. 문제는, 저 저수준 제어와 고수준 추상화의 두 가지 개념은 서로 완전히 충돌하는 부분이 많기 때문에[12] 그러나, C++ 의 저수준 작업은 저런 디테일한 부분을 프로그래머가 신경끄지 못 하게 만든다. 그게 C++의 묘미이기도 하다 C++ 의 고수준 기능들은 C++ 방식으로 변형되어 적용되었거나 혹은 프로그래머가 저런 부분을 감안하여 사용해야 한다. RAII 등 독특한 C++만의 코딩 문화가 존재하는 것도 그 때문.

템플릿이 사용된 모든 타입에 대해 컴파일 시간에 확장하도록 설계된 이유 또한 실행 성능을 포기하지 않기 위해서이다. C++과 비슷한 정도의 기능을 가진 언어 중에서 C++만큼 빠른 실행 성능을 내는 언어 구현은 흔치 않다. 대신 프로그래머가 언어의 이상한 부분까지 신경쓰지 않으면 안 되는 디자인이 되어 제대로 쓰는 게 굉장히 어려운 언어가 되고 말았다.[13] 뭔가 딜레마같지만 C++과 비슷한 정도의 고수준 기능을 제공하는 언어는 절대로 C++보다 복잡하지 않다. 덤으로, 템플릿 같은 경우엔 실행 성능을 포기하지 않는 대신 컴파일 시간을 심각하게 포기했다. 심지어 디버깅도 힘들다. 템플릿 포함된 에러 메시지를 보면 정신이 아득해진다

애초에 C 언어의 기능을 모두 포함했던 이유는 생산성과 함께 C 언어를 대체하겠다는 두마리의 토끼가 목적이었기 때문이다. 그러나, OS 만드는 유닉스 커뮤니티들이 C++ 로의 전환을 거부해서 한마리 토끼는 놓쳤고... 그럼에도 자바라는 강력한 언어가 등장하기 전까지는 C 에 비해 압도적인 생산성으로 어플리케이션 소프트웨어쪽에서 순식간에 대세언어가 되었으나...자바의 등장과 각종 스크립트 언어들의 부상, 그리고 비주얼 베이직에서 파이썬으로 이어지는 하이퍼 고 생산성 언어들의 등쌀에 현재는 포지션이 좀 애매해진 경향이 있다. 애초에 C 언어의 기능을 전부 포함했던게 공짜로 된것이 아니라, 그만큼 고급기능이 복잡해지는 컴파일속도도 엄청나게 느려지는 역효과도 포함하고 있었고, 덕분에 자바나 기타 고생산성 언어들에 비해 생산성은 떨어지면서 정작 노리고 있던 C 언어의 대체도 날아간 상황. 현재는 퍼포먼스가 엄청나게 중요하면서 동시에 개발속도도 크리티컬한 게임이나 포토샵, 웹브라우저 등의 어플리케이션에 한정해서 주로 사용된다. 근데 포지션이 애매하긴 하지만, 그 애매한 포지션 자체가 사실 어플리케이션 쪽에서는 황금 포지션이다.

5 단점

어렵다. 'C++이 쉽다는 사람과는 상종하지 말라'는 말도 종종 보일 정도니... C++ 을 배우려는 초보자가 인터넷에 문의를 해보면 보통 초보자용 1개 중급자용 1개 STL 1개 등등등 해서 여러 개 읽으라는 답변들이 많이 달리며, 저 각각의 책들 부피는 보통 1000 페이지에 육박한다.[14] 300 페이지가 채 안 되며[15] 난이도도 그리 높지 않은 TCPL(The C Programming Language) 로 기본은 끝낼 수 있는 C 언어와 비교해보라. 보통 이 언어 저 언어 손댄 프로그래머들의 책장에도 C++ 관련 서적이 가장 많은 경우가 많다. 언어가 난해하면 단순히 난이도가 높은데서 끝나는 게 아니라, 저 진입장벽을 다 넘지 않은 프로그래머들이 많아진다는 것도 하나의 문제이다. 즉, 엉터리 코드가 범람하게 될 가능성도 높아지고 제대로 된 프로그래머를 찾기도 힘들어진다. C++ 비판론자들은 이부분을 주로 공격하여 저수준부터 시작해서 고수준까지 기능은 엄청나게 많지만 설계단계에서 그걸 제대로 묶어주는 일관성을 잃어버린 실패한 언어라고 비판한다. 그래서 C++에서 할 수 있는 것을 다 할 수 있는, 좀더 쉬운 D라는 언어도 만들어졌지만 생각보다 인기가 별로 없는 듯.

리눅스 진영의 두 주축인 리누스 토르발스[16][17]와 리처드 스톨먼은 둘다 C++ 을 신랄하게 비판하였다. 일반적으로 토르발스와 스톨먼은 서로 앙숙관계라, 엇박을 맞출 때가 많은데, C++ 을 비판할 때만은 한마음이 되었다.(...) 그럼에도 C++ 이 제공하는 기능들이 막강한지라, 리눅스 진영에서도 커다란 프로젝트에는 C++ 을 상당히 애용하고 있다.

6 역사

6.1 초창기

1979년 비야네 스트롭스트룹이 느리지만 객체지향적인 언어 Simula의 컨셉을 C 언어에 접목시키면서 C with Classes라는 이름으로 만든 게 최초이다. 이후 1983년, 1989년, 1990년에 언어를 버전업하면서 이름이 C++로 바뀌게 된다. 이 시점에서 이미 클래식 C++의 틀은 완전히 잡혔다고 할 수 있다. 이때까지는 거의 스트롭스트룹이 언어 개발을 전담하다시피 했고, 본인이 쓴 책 The C++ Programming Language을 통해 C++라는 언어를 정의하고 레퍼런스 컴파일러를 배포하는 식으로 개발되었다.

6.2 표준화

이후 C++가 안정적으로 정착하고 수요가 폭증함에 따라 여러 회사에서 상업용으로 컴파일러를 만들었고, 이에 따라 코드가 컴파일러에 따라 중구난방이 되는 것을 막기 위해 표준화의 필요성이 제기된다. 그래서 ISO에서 스트롭스트룹을 비롯한 프로그래밍 언어학자 및 컴파일러 제조사들을 모아 표준화 작업을 하기 시작한다. [18] 그렇게 1998년 최초로 표준안이 제정되었으며 이를 줄여 C++98[19]이라 부른다.

이후 2003년에 C++98 문서의 애매모호했던 부분들을 보완한 C++03[20]이 제정되었는데, 이는 그냥 표준화 문서 상 불명확했던 것을 교정한 버전이다. 예를 들어 std::vector가 배열처럼 연속된 메모리를 차지하도록 표준에 명시했다. 사실 당시 컴파일러들 대다수가 이미 C++03 제정 이전부터 이러한 부분들을 잘 구현한지라, 실제 프로그래머 입장에서 변한 건 없다.

2007년에 표준 라이브러리를 확장하는 것을 골자로 하는 테크니컬 리포트가 제정되었다. 이름은 C++TR1 [21]이며, 표준화 이후 사실상 언어에 변화를 가한 첫번째 확장안이나, 엄밀하게 표준이 아니라서 컴파일러 제작사가 원하면 넣고 아니면 마는 수준의 선택적인 확장안이었다. 그래서인지 전부 std 네임스페이스에 들어가 있지 않고 대신 std::tr1 네임스페이스로 분리되어 들어간다. 이후 이 TR1의 기능들은 C++11에 대부분 정식으로 흡수된다.

6.3 모던 C++

이후 10여년간 별다른 변화 없이 쓰였으나, 2011년부터 본격적으로 이미 강산이 변한 컴퓨팅 환경을 지원하기 위해 언어가 급격하게 변화하기 시작한다.

그 첫단추를 끊은 건 2011년 8월에 제정된 새로운 대규모 확장팩표준안 C++11[22]. 표준안 개발 당시 코드네임으로 C++0x라 불리었는데, 2000~2009년 중 언젠가 표준화가 될 것이라는 의미였다. 하지만 결국 2009년을 훌쩍 넘긴 2011년 8월에서야 정식 C++ 표준이 되어서 11이 붙었다. #. 여담이지만 추가된 많은 기능 중 상당수 항목들이 boost 라이브러리의 판박이라[23] 해도 과언이 아닐 정도로 많은 기능을 참조했다.

2014년 8월에 C++14[24]가 제정되었으며, 표준안 작성 당시 C++0x라 불리었던 C++11처럼 C++14도 C++1y라는 코드네임으로 불리었다. 주로 C++11에 추가된 요소들을 다듬고 확장하는 데 치중한, 비교적 마이너 표준안이다.

현재, 2017년에 표준으로 올릴 것을 목표로 하는 표준안인 C++17, 혹은 C++1z를 제정중이다. C++11의 요소들을 향상시키는데 주력했던 C++14에 비해, 언어 자체의 새로운 기능에 비교적 주력한다. 초안 단계에서부터 논란이 많은 표준안이기도 하다. C++11/14의 실정에 맞추어 옛날 기능을 삭제하자는 안이 많기 때문인데 [25], deprecated 판정을 받은 std::auto_ptr이나 삼중자(trigraph)[26] 등을 삭제하자는 안이 이미 올라온 상태다. 이러한 삭제안이 통과될 경우 옛 코드에 대한 호환성을 포기하는 것이기 때문에, 10년 이상 된 코드들이 최신 컴파일러에서 컴파일되지 않을 가능성이 크다. 이것 때문에 IBM에서 문자체계의 문제를 내세워 삼중자를 제거하지 말라고 회사 차원에서 표준화 위원회에 진정서까지 제출했을 정도이다. # 하지만 후방호환을 위해 옛 언어 요소를 그대로 계속 두면 추후 표준안이 점점 비대해지는 것도 나름 문제이니 골치가 아픈 상황. 거의 최종화된 C++17의 새로운 기능들에 대한 정리를 여기서 볼 수 있다.

각종 주요 컴파일러들과 모던 C++의 호환성은 여기서 볼 수 있다.

7 방언 및 확장

7.1 Managed C++

.NET의 CLR에 맞물려 동작하는 C++. 보통 프레임워크 정도로 제공되는 다른 라이브러리와 달리 .NET의 메모리 구조에 맞추어 언어 자체가 다르다.

초창기의 Managed C++은 정말 못 써먹을 언어였으나 그 후에 등장한 C++/CLI는 적어도 스펙상으로는 게임을 만들기에도[27][28] 부족함이 없는 고속의 언어임에도 생산성은 C++에 비해서 높다고 한다. 특히 C#과 C++을 이어주는 래퍼 등의 모듈을 만들기에는 아주 제격이며, C/C++로 만들어진 프로젝트를 시간적 여유를 두고 닷넷 기반으로 바꾸는 용도로도 많이 쓰이고 있다. 필요에 따라 단계적으로 모듈을 바꿔치기 하다보면 어느새 순수 닷넷 애플리케이션 완성. 다만 지원 및 이식성이 떨어져서 업계표준으로 쓰기에는 무리다.

여담이지만 .NET 출시 당시 마이크로소프트가 .Managed 언어를 강력하게 밀어(C\# 등) 기존에 쓰이던 Win32 API C++나 MFC는 찬밥 신세라는 인상을 줬었다. 특히 닷넷 기술이 막 도입되던 Visual Studio 2005 당시 C++와 C#를 비교해 보면 대놓고 C++를 죽이려 한다는 느낌이 팍팍 들 정도. 이후 MS도 현실을 직시하고 VS 2008부터는 지원이 다시 강화되는 추세이고, C++11/14/17 지원 및 C++ AMP의 도입 등 여러가지 확장을 하고 있다.

7.2 CUDA

NVIDIA의 GPU에서 동작하는 C++ 기반 GPGPU 언어. 자세한 것은 해당 항목 참조.

7.3 OpenCL

개방형 GPGPU 언어. 원래는 C 기반이었으나 OpenCL 2.1부터 C++14를 기반으로 문법이 확장되었다. 자세한 것은 해당 항목 참조.

8 관련 문서

9 외부 링크

  1. ↑ 읽는법 어떻게 읽어야하는지 자주 물어 보는지 아예 본인이 wav파일로 읽는법을 올려 두었다
  2. ↑ C -> C++은 절차지향 언어의 사고방식, C++ -> C는 객체지향 언어의 사고방식이 머릿속에 굳어버리기 때문이다.
  3. ↑ GNOME의 핵심 라이브러리인 Glib이 대표적으로 C 언어로 객체지향을 짜도록 구성되어 있다.
  4. ↑ C++의 템플릿을 모르고 보면 아예 이해불가이며, 템플릿을 배운 후 봐도 처음 보면 그 병맛에 입에서 WTF이 나오며, SFINAE (Function overloading을 함에 있어 조건에 따라 일부러 문법적으로 틀린 템플릿의 구현 코드를 발생시켜 틀리지 않은 문법이 되는 특정 overload만 선택되게 만드는 테크닉) 이나 expression template (템플릿을 재귀적으로 사용해서 lazy evaluation이 적용되는 효율적인 계산 코드를 컴파일시에 자동 생성하는 테크닉) 등 진정한 악용의 시점부터는 안드로메다를 느낄 수 있다.
  5. ↑ e.g., 표준 라이브러리의 type 관련 부분, C++ 기반 수학 라이브러리들 등
  6. ↑ C++ 템플릿이 코드를 컴파일 시점에 확장하는 방식이라는 것과, 비타입 인수도 줄 수 있다는 것을 이용한다.
  7. ↑ 참고로 자바나 C#에 있는 제네릭은 템플릿과는 아주 다르다. 자바로 TMP같은건 꿈도 못꾼다. 당연히 작성하기는 제네릭이 훨신 편하지만 (그리고 제네릭으로 하는 일은 C++에서 TMP가 아닌 일반적인 템플릿으로 작성한다) TMP의 의의는 컴파일 시간에 모든걸 해결하겠다는 진정한 성능덕질에 있다.
  8. ↑ 소멸자가 호출되지 않는 등의 차이점은 있지만 심각한 문제가 되는 경우는 많지 않다.
  9. ↑ 동적 할당을 해줬으면 해지도 해줘야 되는데, 클래스 사용자가 해줄 리가 없다(...)
  10. ↑ 동적 객체를 여러 곳에서 공유해야 하는 경우 std::shared_ptr (이 경우 garbage collection과 동일한 원리로 관리), 한 곳에서만 사용하는 경우 std::unique_ptr (shared_ptr에 비해 더 효율적) 를 사용한다.
  11. ↑ C 는 사실 UNIX 라는 OS를 만들기 위해 어셈블리 대체용으로 만들어진 언어라, 저런 머신컨트롤이 주된 임무 중 하나였다. 그리고, C++ 은 그 이름에서 보이듯이 사실상 C 를 대체하기 위한 언어였기 때문에 역시 저것들을 포기할 수 없었던 것이고.
  12. ↑ 추상화의 가장 큰 이유와 장점은 그것을 추상화시킴으로 해서 그 아래 감춰진 디테일한 부분을 신경쓸 필요가 없게 만드는 것이다.
  13. ↑ 대신 그만큼 섬세한 프로그래밍이 가능하다
  14. ↑ 당장 초보자용 1개를 끝내면 이해가 안되는 것들이 남지만 기초는 할 수 있을 텐데도, 문제를 풀어보려 하면 풀 수 있는 문제가 거의 없다. 실제로 사용하려면 STL까지 배워서 벡터와 그 주변 정도는 쓸 수 있어야 한다.
  15. ↑ 그것도 순수 튜토리얼 부분은 200 페이지가 채 안된다
  16. ↑ 초창기 리눅스 커널에서도 C++ 을 이용하려다 C 가 낫다며 다시 돌아온 흑역사가 있었다.
  17. ↑ 리누스 토르발스의 말에 의하면, C++는 고도로 숙련된 개발자가 조심하면서 코딩을 하지 않으면, 망쳐버린다고 한다.
  18. ↑ C++뿐 아니라 C, 파스칼 등 클래식 언어들이 전부 ISO에서 표준화되고 있다. 아예 이런 언어를 표준화하는 전문 태스크 팀 JTC1/SC22라는 게 있으며, 이중 C++는 21번째 그룹에 속한다
  19. ↑ 정식 명칭은 ISO/IEC 14882:1998
  20. ↑ 정식 명칭은 ISO/IEC 14882:2003
  21. ↑ 혹자는 이를 표준안과 동급으로 간주하고 C++07/TR1이라 부르기도 한다. 정식 명칭은 ISO/IEC TR 19768:2007.
  22. ↑ 정식 명칭은 ISO/IEC 14882:2011
  23. ↑ 아예 boost 라이브러리 개발진중 다수가 C++ 표준화 위원이기도 하다. 차세대 C++에 들어갈 요소를 표준화 위원들이 미리 개발해서 시험해본 것이라 봐도 무방.
  24. ↑ 정식 명칭은 ISO/IEC 14882:2014
  25. ↑ C++11 제정 당시에도 std::auto_ptr 등 많은 옛날 요소들이 deprecated로 명시되어 사용이 자제될 것을 권장받았으나, 이는 어디까지나 권고라 사용자가 맘 놓고 쓰려면 쓸 수 있었다. 이전 버전의 기능을 아예 죽여버린 사례는, C++98 시절에 실상 누구도 안 썼고 지금은 아예 용도가 바뀌어버린 auto 등 극소수만이 해당한다.
  26. ↑ C/C++의 특수기호는 미국의 부호체계인 ASCII를 기반으로 하고 있기 때문에 해당 영역에 다른 문자를 넣어 사용하던 유럽국가들의 코드페이지에서는 이상하게 표현되는 일이 있었다. 그래서 잘 사용하지 않는 문자의 조합으로 특수문자를 표기하는 방법. 문자 2개의 조합이면 digraph, 3개면 trigraph. 유니코드가 대세가 된 지금은 사실 필요 없고, 옛날 소스라고 해도 간단한 일괄 변환작업으로 새표준에 맞출 수 있기도 하다. 다만 표준에서 삭제처리를 할 경우 해당 문법이 다른 기능으로 대체될 수 있기 때문에 일괄변환이 언제나 될 것이라는 보증이 안되고, 후술하는 IBM 등 장기간의 낡은 코드와 관련된 이해관계자들 입장에서 떨떠름한 것은 사실.
  27. ↑ 게임은 일반적으로 생산성이 매우 중요한 거대 프로젝트이면서 하드웨어의 성능을 극한까지 끌어내야 하는, 속도와 효율에 매우 민감한 특수한 소프트웨어 분야이기 때문에 프로그래밍 개념을 따질 때는 매우 중요하다. 괜히 이런 이야기에 게임에 대한 언급이 잘 나오는 게 아니다.
  28. ↑ 초기의 Managed C++은 언어의 포지션도 상당히 애매한 물건이었다. 간단히 말하자면 닷넷 프레임워크와 레가시한 운영체제 프레임워크를 동시에 지원할 작정이었는데... 결과물은 글자 그대로 이도저도 아닌 물건. 차라리 닷넷 프레임워크가 COM을 지원하니 그런 걸 쓰는 게 낫지...