C++11로 시작하는 C++강의, 어떨까요?

klyx의 이미지

아는 분들은 아시겠지만, C++11부터는 여러가지 syntax sugar가 도입되고 표준라이브러리가 확장되어서 코드작성을 훨씬 쉽게 만들어줍니다.
예를 들면 auto를 이용한 변수 선언은 우변의 타입을 자동으로 추론해주기 때문에 일일이 타입을 작성할 필요가 없게해줍니다.
initializer_list는 std::vector나 std::array를 기본 배열처럼 초기화할 수 있게 해줍니다.
std::tuple은 간단하게 여러개의 값을 리턴하는 함수를 작성할 수 있게 해주며, std::tie등과 함께 사용하면 스크립트 언어에서나 보던 a, b = 1, 2; 와 유사한 구문도 가능케 해줍니다.
이외에도 많은 변화가 있는데, 이런걸 활용하면 마치 스크립트 언어를 가르치듯이 C++을 가르치는 것도 가능하지 않을까하는 생각이 듭니다.

물론 C++의 auto는 동적타이핑 언어의 변수선언과는 전혀 다릅니다.
auto를 쓴다고 해도 결국 변수의 타입은 처음에 선언할때 컴파일러에의해서 고정되버리고 다른 타입의 변수로는 사용할 수 없으니까요.

그렇다고는 해도, 예를 들어 처음에는 문자열이라는 걸 char[]로 가르치지 않고 std::string(또는 std::u16string)으로 가르칠 수 있을겁니다.
(비록 거짓말이지만)C++에서 문자열은 다음과 같이 이용하는 겁니다, 하는거지요.

auto str = std::string("문자열");
auto str2 = std::string("또 다른") + str;

C++11에서는 std::string을 포함한 대부분의 표준라이브러리 클래스들이 move constructor를 구현하고 있으므로 위와같은 코드가 딱히 비효율적인 코드가 되지도 않을겁니다.
한글을 쓰면 std::string의 size가 글자수가 아닌 바이트수가 되버리기 때문에 처음부터 std::u16string(일부를 제외하면 거의 1대1로 대응되니까요)을 문자열로 가르칠수도 있을겁니다.
이경우에는 표준 라이브러리에서 제공하지 않는 std::u16string을 위한 입출력을 구현해서 기본 해더같은 형식으로 제공해줘야겠지요.
아니면 그냥 "한글은 쓰지마!"라고 밖아놓고 시작해야 할테구요.

또, 배열 크기는 상수여야된다던가, 동적할당이라던가하는 복잡한 것을 설명할 것없이, 기본 배열타입으로는 무조건 std::vector를 가르칩니다.
range-based for는 많은 스크립트언어에서 제공하는 for-in 구문처럼 쓸수 있을테구요.

std::vector<int> array = {1, 2, 3, 4, 5};
int sum = 0;
for (auto val : array)
    sum += val;

혹은, vector대신에 기본 배열로 initalizer_list를 사용하면 auto 구문을 그대로 이용할 수도 있습니다.
이경우에는 vector는 더 편리한 배열로 소개되어야되고, initializer_list는 얕은 복사만된다는 점등이 문제가 될수도 있다는 걸 설명해야될겁니다.
어떤게 이해하기 좋을지는 고민을 해봐야겠지요.

좀더 간단하게 tuple등을 쓸수 있게 몇가지 using 선언이나 전역 템플릿함수, user-defined literal등을 선언한 해더파일을 제공해서 처음엔 의미를 몰라도 일단은 무조건 include하게 하는 방법도 있을 수 있습니다(위에서 언급한 std::u16string의 입출력함수도 여기에 들어가겠네요).

또 전역함수를 선언할때 함수가 아닌 lambda를 이용하거나 C++14까지 끌고오면 함수라도 리턴타입을 명시할 필요가 없고, generic lambda를 이용하는 경우엔 인자의 형을 선언할 필요까지 없어집니다.
단, 어차피 클래스로 들어가면 인자타입을 명시해줘야되니까 generic lambda로 속이는건 별로 좋지 않는 방법일수도 있겠습니다.

아무튼 여러가지 연구가 더 필요하긴 하겠지만, C++에의 입문을 매우 쉽게 만들어 주지 않을까 싶습니다.
물론 최종적으론 raw string(char[])같은 것도 다 가르쳐야겠지요.
하지만 거기까지 가기 전에 충분히 활용가능한 코드를 짤 수 있게될겁니다.
걱정되는 점은 오히려 이런 접근법이 혼동을 가중시키지는 않을까하는 점입니다.
예를 들면, 앞에서도 이미 한번 나왔듯이 어떤건 auto로 선언해도 되고 어떤건 auto로 선언하면안되고할 바엔 차라리 auto를 타입에 대한 개념을 먼저 잡고나서 가르치는게 나아보이기도 합니다.

여러분은 이런 C++교수법에 대해 어떻게 생각하시나요?
이 방법이 정말 C++의 문턱을 낮출 수 있다고 생각하시나요?
비단 C++11을 활용한 교수법뿐만 아니라, C++을 더 알기쉽게 가르치기 위해서 이렇게 하는게 좋다하는 것에 대해서 의견을 나누었으면 합니다.

그리고 C++11이 나온지도 몇년됬는데, 적어도 책까진 아니어도 온라인상에는 이런 비슷한 접근법의 강의가 있을법도 합니다.
혹시 아시는게 있으면 공유부탁드립니다.

어허야의 이미지

저도 C++을 처음 공부하는 입장에서 C++11은 선택이 아니라 필수라 생각합니다. 지금에 와서 C++11을 쓰지 않고 C++을 쓰는것은 엄청난 삽질같고요. 언급하신 auto만 해도 코드 가독성을 아주 많이 향상 시켜주니까요. 스마트포인터도 이제 표준라이브러리에서 제공해주는 이상 쓰지 않을 핑계가 없다고 봅니다.
C++11은 이미 The C++ Programming Language 4판에도 잘 반영되어 있습니다. 그리고 Bjarne Stroustrup은 A Tour of C++ 라는 책도 새로이 쓰셨더군요. 또 유명한 책중 하나인 Effective C++시리즈도 조만간 C++11내용이 반영된 새 책이 나오는것으로 알고 있습니다. 아직 읽어보진 못한 책이긴 한데 C++ Primer 5판의 경우 C++11을 감안해서 거의 처음부터 새로 썼다고 합니다.

yukariko의 이미지

auto는 자료형을 컴파일러가 판단해 주는것이지 그것으로 인해 가독성이 좋아지는것은 아니라고 봅니다.
오히려 다른사람의 소스를 읽는다고 할 때, auto형은 이것이 무슨 의미의 변수인가를 더 알기 어렵게 만들죠.
C++11은 물론 C++에 비해 좋은 기능들이 많이 생겼습니다만 결코 가독성이 좋다고 말하기는 힘들죠.
오히려 추가된 많은 기능들이 역으로 처음부터 배우기에 양이 많고 복잡하게 느껴질 수도 있으니까요.

yukariko의 이미지

스트링을 굳이 auto 구문을 사용할 필요 없이
String str = new String("문자열");
같이 사용할 수도 있죠. 이렇게 자료의 타입이 정의되어 있는것이 auto 보다 이해하기 쉽다고 생각합니다.
물론 변수 선언시마다 auto 를 써주면 편하겠지요.
어떻게 보면 언어를 이해하기 쉽다고 느껴질 수도 있습니다.
하지만 이것은 언어를 이해한것이 아니라, 이해가 필요없을 정도로 편의를 제공해준 것입니다.
그러나 이런 편의는 나중에 반드시 발목을 잡게 되지요.
auto str = std::string("문자열");
로 가르치면 된다고 말씀하셨는데,

문자열이라는 걸 char[]로 가르치지 않고 라는 발언에서 프로그래밍을 처음 배운다고 가정해보면,

제가 프로그래밍을 처음배우는 입장에서 저런 선언을 보게 된다면, auto는 단순히 변수를 선언해준다는 의미구나 라고 여기게 될 것입니다.
auto라는 단어의 사전식 정의는 무시되는 것이죠. 그렇다고 저 선언을 보여준 후에 auto는 변수의 형식을 자동으로 정해주는거야
라고 설명한다면 이 역시 와닿지 않을 것입니다. 사실은 int나 char float 등과 같은 여러 타입이 존재한다는것을 알고있을 때 비로소
auto라는 형식의 의미와, auto의 사전적 정의가 딱 들어맞게되어 이해가 잘 될것이라고 저는 생각합니다.

언어가 고차원적이 되고 사용하기 편하다해서 이해가 잘되는것은 아닙니다. 본래 이해해야 할것을 편의성이라는 단어앞에 감추고 있을 뿐이죠.
물론 처음배우는 사람은 저 개념을 이해하지 않고도 프로그래밍을 할 수 있게 될것입니다.
의미는 모르지만 auto를 쓰면 된다는것은 아니까요.
처음엔 모르고 쓰다가 점점 배우면서 깨닫게 되는것도 공부법의 한 종류라고 보지만, C++11 같은 경우는 그 모르고 쓰는 가지수가 너무 많아지는것이 아닌가 라고 생각합니다. 그럴바에는 C++로 시작해서 기초를다지고 C++11로 건너 뛰는것이 좋다고 생각합니다.

auto의 경우에도 제 발언과 역설적이지만, int char float 같은 형식을 설명해주고 난 후, auto형을 가르친다고 해서 잘 이해할것이라고는 생각하지 않습니다. int char float에 대한 개념은 배웠지만 아직 머리에 확실히 잡히지 않은 상태에서 auto를 가르친다고해도 뜬구름잡는 소리로 밖에 들리지 않을 가능성이 높다고 보기 때문이죠.

제가 실제로 본 교육에서의 예를 하나 들어보겠습니다.
두 곳에서 C를 가르치고 있다고 합시다. 한곳에선 C의 기초적인 개념보다는 그 결과를 보여줌으로써 학생이 각자 나름대로 이해하게끔 가르칩니다. 예를들면 포인터를 가르칠 때, 가장 흔히 swap 함수를 보여줍니다. call by value와 call by refference 의 차이를 보여주고, 간단한 설명을 덧붙여서 학생이 포인터의 의미를 나름대로 깨우쳐 가는 것이죠.

다른 한곳은 C의 기초적인 개념에 중시를 하며 가르칩니다. 말그대로 기본에 충실한 교육방법이죠. 이부분은 딱히 설명하지 않아도 될것 같군요.

이렇게 다른방법으로 학습한 학생들에게 문제를 하나 내보았습니다.

a의 아스키코드값이 97일 때, printf("%d",*(short *)&("baac"[1])); 의 결과는?

뭔가 복잡해보이지만, "baac"가 문자열 상수로 주소를 가리키는것과, [1]은 배열에서 두번째 원소를 가리키는것.
&는 변수의 주소를 나타내는것, (short *)는 short의 포인터형으로 형변환 한다는것. 맨 처음 *는 포인터 변수의 값을 불러온다는것을
이해하고 있으면 그다지 어려운 문제는 아닙니다.

결과는 후자의 교육을 받은 학생은 풀고, 전자의 교육을 받은 학생은 답을 적지 못했습니다.
나머지는 일반적인 문제를 내보았지만, 역시 전자가 풀지못한 문제를 후자가 푸는 경우는 있어도, 그 반대는 없었죠.

결론은 무언가를 가르칠 때 꼭 따라하기 쉽다고해서 이해가 쉬운것은 아니라는 겁니다. Greed와 DP의 차이랄까요? 바로바로 성과가 나타난다고 해도 결국은 개념을 쌓아온 사람에게 밀리게 된다고 생각하기 때문에, 개념위주의 교육이 필요하고, 개념위주의 교육에서 C++11은 가르쳐야 할것이 너무 많다고 생각되기 때문에 저는 공감이 가지 않습니다.

winner의 이미지

말씀하신 printf 문제는 실행환경에 따라 program 이 비정상종료될 수도 있는 정의되지 않는 행위입니다.
후자의 교육을 받은 학생의 대답이 궁금하군요.

아시겠지만 auto 는 C 와 함께 이야기하면 자동공간의 범위와 수명을 가지는 변수라고 표준에서 정의했다가 모두 안 쓰길래(쓸 필요가 없으니까...) 다르게 사용한 대표적인 사례인데요.
저도 int, char 혹은 float 을 다룰 수 있는 영역에서 auto 쓰라고 교육시키고 싶지 않습니다.
그러나 string 정도 되면 저는 다르게 생각합니다.
String s = new String("문자열");
이게 좋은 걸까요? 일단 제가 Java 를 한다면 다음과 같이 작성하겠군요.
String s = "문자열";

약간 비슷한 사례로 과거 C 동적할당에 대해서 이런 논의가 있었죠.
int* arr = (int*) malloc(sizeof (int) * 4);
malloc 앞의 (int*) 있는게 좋은가? 없는게 좋은가?
명시적인 것의 장단점도 이야기해볼 수 있지만 (int*) 가 없으면 C++ 는 compilation 되지 않는다는게 더 중요한 문제였다고 봅니다.
그리고 C++ 는 int* arr = new int[4]; 라고 쓰는 것을 권유하죠.

yukariko 님의 글을 읽으면서 고개가 끄덕여지는 것도 많았습니다만 아쉬운 점도 몇몇 보였습니다.
실례되는 말입니다만 이제는 전문가가된 자신의 눈높이로만 입문자들을 바라보지 않는가라는 생각이 듭니다.
저라면 입문자들에게 printf 사례를 언어 이해를 위한 문제로 내지는 않을 것입니다.

yukariko의 이미지

winner님의 댓글에 태클을 걸려는것이 아니라 제가 궁금해서 묻는것입니다..
어떤 환경에서 저 printf가 비정상종료 될 수 있는건가요?
정의되지 않은 행위라는것은 표준이 아니라는 의미로 들립니다만
상대적으로 형변환이 자유로운 C에서는 가능한것들 아닌가요?

winner의 이미지

Implementation defined. 그러니까 실행환경에서 명세가 되어야 하는 영역이네요.
물론 실행환경은 오류가 발생한다로 명세할 수도 있겠습니다만...

제가 염두한 것에 대한 검색어는 memory alignment restriction 입니다.
사실 저도 자신있게 이해하는 부분은 아닙니다만 C object 들은 자료형에 따라 적절한 memory 위치가 지정되는 것으로 알고 있습니다.
Wikipedia: http://en.wikipedia.org/wiki/Data_structure_alignment

KLDP 에서 관련질문이 있었습니다.
https://kldp.org/node/36069

제가 조사한 바에 의하면 unaligned 접근에 대해서 최근 유명한 CPU 들은 대부분 두번 이상의 명령수행을 통해 우회한다고 합니다.
약간 독특한 것이 이제는 사장된 IA-64 인데 이 녀석은 hardware 로 처리하는 것이 아니라 compiler 가 명령을 추가하는 식으로 처리한다고 하네요.
원래 IA-64 가 EPIC 을 지향했으니까 당연한 걸지도 모르겠습니다만...

그런데 말씀하신대로 C 는 변환이 너무 자유로워서 제시된 code 가 IA-64 환경에서 문제없도록 잘 compilation 될지 모르겠습니다.
통상 이 문제는 struct 나 union 에서 고민하는데 문자열 literal 을 가지고 직접 접근하는 것까지 compiler 가 잘 해줄까요?
일단 pointer 로 다른 함수로 넘겨서 처리하지 않고, object 가 정의된 영역내에서 모든 접근이 이루어지니까 똑똑한 compiler 는 잘 해줄지도 모르지만... 글쎄요...

C 의 변환이 자유롭다는 것은 막 해도 된다는 뜻이 아닙니다. 그만큼 programmer 에게 많은 책임을 미루고 있다는 뜻입니다.
C 와 같은 언어가 표준 분량이 작은 이유 중 하나가 될 수도 있겠네요.

february28의 이미지

사기와 기만만 안하면 누구라도 말이나양이나 알수 있습니다. 하지만 현실적으로 불가능하기에, 그것에 색깔이 어떠하다 정도만이라도 알려주면 다행이죠. 노 밥그릇한 견해로 c++는 클라스 코스가 우선이죠...

--------------------------------------------------------------------------------
open source, open teaching, 천기누설이 꿈~ 은 개뿔...
--------------------------------------------------------------------------------

mirheekl의 이미지

예로 들어주신 해당 기능들을 이미 좀더 매끄럽게 지원하고 있는 C#등의 언어를 사용하는 게 맞는 방법이라 생각하고요.

코드 생산 자체가 문제가 아니고 C++에 대한 좀 더 깊은 이해를 돕기 위한 교육이라면 그냥 처음부터 차근차근 하는 것이 낫지 않을까 하는 생각이 듭니다.

최근에 C/C++에 추가된 것들을 보고 있자면 진입장벽을 낮춰준다기보단 숙련자들의 생산성을 높이기 위한 것들이 더 많아 보여서 말이죠.

--

klyx의 이미지

사실 저도 기본부터 차근차근 해서, 특히 먼저 C++에 포함되어있는 C의 부분집합부터 익혀야한다고 계속 생각해왔습니다.
C++은 여러가지 장점이 있고, 그중에는 별도의 래퍼없이 바로 C와 연동할 수 있다는 매우 강력한 장점도 있는데, 문자열/포인터/배열/동적할당에 대한 개념이 제대로 잡혀있지 않으면 이게 사실상 불가능하기 때문이죠.

그런데 최근 C++11과 C++14를 보면서 느낀게, 뭔가 스크립트언어 같아, 라는 인상이었습니다.
여전히 컴파일타임과 런타임이 엄격하게 구분되는 경직된 컴파일 언어이기는 하지만요.
약간의 무리수처럼 보이지만 본문과 같은 생각을 하게된 것이, 수많은 '스크립트 언어는 쉽다!'라는 문구때문이었습니다.
이렇게 놓고 보면 딱히 C++이 스크립트보다 어려워야할 이유가 없어보이는데(사실 저는 파이썬같은 동적인 언어를 C++보다 더 어려워합니다), 그럼 C++을 스크립트 언어처럼 가르치면 사람들이 쉬워할까?라는 생각을하게 된거죠.

C++11이 나온 이후로, 많은 책이 C++11을 소개하고 있지만, 대부분의 책이 'C++11은 추가로 더 배워야할 무언가'라는 포지션에서 맨뒤에 별개의 장을 할당하여 소개하고 있습니다.
어혀야님께서 'C++ Primer 5판'은 완전히 다시쓰였다고 하셨는데, 이책에는 어떻게 들어가있나 다음에 서점가면 한번 찾아봐야겠습니다.

C++이 너무 방대하다는 소리도 있지만, 사실 C++표준위원회는 되도록이면 언어의 확장보다는 라이브러리의 확장을 선호하는 경향이 있기 때문에, 방대한 C++의 대부분을 차지하는 건 표준 라이브러리입니다.
그런데 이런거 사실 GUI까지 포함하는 Java의 라이브러리에 비하면 세발의 피일텐데 어째서 C++만 이렇게 욕을 먹을까 생각합니다.
심지어 어떤 사람은 TCPL은 3백쪽도 안되는데 TC++PL은 천쪽이나 된다면서 까는 사람도 있었습니다.
TC++PL에서 언어의 문법적 요소만 추려보면 4백쪽을 조금 넘는 수준인데도 불구하구요.
제가 보기에 방대함으로 따지면 Java가 훨씬 방대한데, 왜 사람들은 C++은 어렵고 자바는 쉽다고 할까라는 생각 참 많이합니다.
가비지 컬렉터야 스마트 포인터쓰면 될일이고, 사실 C++에서 포인터를 새로 할당해서 리턴하고 외부에서 해제해야하는 경우자체가 드뭅니다.
그러다보니 좀더 쉽게 사람들이 C++에 익숙해질 수 있는 방법이 없을까하는 생각을 하여 이런 글도 쓰게 됬네요.

아무튼, C++11은 매우 편리한 기능이 많이 추가되었음에도 불구하고, 'C++11은 또 뭐야 이건 또 언제해'라는 사람들도 본적이 있고 해서 아에 C++11을 맨앞으로 가져오는건 어떨까라는 생각이 들었습니다.
하지만 역시 전통적인 기본부터 하는게 좋다고 하시는 분들이 많으시네요.
그럼 기본부터 하는게 좋다고 하시는 분들은 C++11부분은 별개의 장으로 빼서 쓰는게 좋다고 생각하시나요, 아니면 중간중간 적당히 섞어서 문법과 함께 설명해버리는게 좋다고 생각하시나요?

yukariko의 이미지

제생각엔 별개의 장으로 빼되 그 순서를 C++과 섞는것이 좋다고 봅니다.
예를들어 어떤 장이 변수의 타입을 다루면 그 다음장엔 auto에 대한 설명 같은 느낌이랄까요
함수에 대해 다뤘으면 그 다음장은 람다에 대해 다루게끔요.

C++에 비해 자바가 쉽다고 하는것은 제생각에 라이브러리의 문제는 아니라고 봅니다.
자바도 고급 개발자가 될정도로 파려면 C++ 못지않죠
자바가 쉽다고 하는 사람들이 많은건
보통 사람들은 겉핥기 식으로 배우는 경우가 많기 때문에 포인터개념이 적게쓰이고
문법이 다 나와있는 개발에디터 이클립스의 영향이 크지 않나 싶습니다.

winner의 이미지

과거 Accelerated C++ 가 C++98 교육을 위해 같은 노선을 취해서 유명해졌고, 이제는 많이들 그렇게 하죠.
Accelerated C++ 가 쉬운 입문서인가라는 말을 하면 여전히 논란이 일어나지만 결과를 놓고 보면 분명 성공적이라고 봅니다.
Accelerated C++ 의 저자 Andrew Koneig 의 서문을 읽어보면 그런 학습법에 대해서 이야기합니다. C++ 의 추상화가 충분히 성숙되었기 때문에 그런 형태로 전환할 수 있었다고 말이죠.

추상화 구멍이라는 말을 통해 대학생들은 Java 같은 것 하지 말고 C 를 충분히 공부해야 한다고 Joel Spolsky 는 말했습니다. 물론 hacker 를 목표로 하자면 그것도 좋을 수 있습니다만 대부분의 programming 입문자는 그런 것을 고려하지 않습니다. 또한 bit 와 byte 를 알아야만 hacker 라고 불리워지는 시대도 지났습니다.

C++11 과 같이 표준에서 다루어지는 것은 많은 전문가들이 심도있게 고려해서 작업한 결과이고, 대부분 입문자들을 위한 추상화 완결성은 충족된다고 생각합니다.

입문자들에게 중요한 것은 깊이 있는 이해라기보다는 자신이 받아들일 수 있는 수준에서 작업이 이루어지고, 흥미를 잃지 않는 형태로 계속해서 작업하고, 학습할 수 있는 적정한 학습곡선과 작업편이성이라고 생각합니다.

대부분의 사람들은 하이젠베르크나 데데킨트의 연구결과를 모릅니다. 그러나 물리학과 수학의 기반 속에서 에너지를 쓰고 있고, 산수를 하면서 삶에 유용성을 얻고 있습니다.

winner의 이미지

C++ 는 여전히 유용한 분야가 많다고 생각합니다만 분명히 독보적이었던 15년 전과는 많이 다른데요.
체험해본 적은 없지만 요새는 game server 를 PHP 로 만든다는 어이없는 소리가 들리는데 말이죠.
뭐라더라... 자체적으로 구현한 server 보다는 web server - PHP 가 전체 중단사태도 적고, scaling out 이 용이하다는 등 굉장히 놀라운 이야기가 들리더군요. 거기에 mobile game 들은 TCP connection 상태가 불안정해서 HTTP 같은 connectionless 가 용이하다고 하는데요.
5년 전 즈음 C++ 가 가장 유용한 분야가 game server 라고 들었습니다만 세상은 정말 빠르게 변하더군요.
제가 보기에 C++ 가 여전히 중요한 분야는 computer engineer 들을 위한 계산집약적 도구, 그러니까 compiler, graphic rendering engine 정도만 남은게 아닌가 싶습니다.

Google 에서는 정적 build 되는 Go 언어를 만들었지만 GUI toolkit 은 만들지 않았죠. Go 언어를 주도한 Rob Pike 는 자신이 과거 동시성 지원 언어를 만들 때 했던 것이 GUI 개발 system 이었지만 Go 언어 에서 GUI toolkit 은 넣지 않은 이유가 이제 UI 의 중심은 web 이기 때문이라고 말했습니다.

klyx의 이미지

정말 C++의 입지가 점점 좁아지는 것에는 크게 공감합니다.
예나 지금이나 간단한거에 컴파일러 쓰는 경우는 거의 없고, 여전히 임베디드에서는 C가 강세고, 서버는 자바가 강세고...
저도 당장에 C++이 잘쓰이는 분야라고 하면 게임이랑 대규모 계산 정도밖에 떠오르지가 않네요.
뭐 어플리케이션 개발쪽으로도 old bad인 MFC나 최근 들어 엄청나게 상승세를 타고 있는 Qt가 있기는 하지만, 솔직히 다들 MFC싫어해서 MFC는 유지 보수 위주고, Qt는 리눅스이외의 플랫폼에선 마이너한 존재일 뿐이고...

그럼에도 불구하고 아직도 오래된 커리큘럼에서는 C->C++->자바 테크트리가 많이 쓰이는지, C++을 어려워하는 대학생들도 많이 보이고, (그들이 누군지는 모르겠지만)'C++은 어렵다'하는 사람들이 많아서 어떻게 하면 쉽게 이해할 수 있을까, 라는 생각에 이 글을 발제하게 되었는데, 딱히 어떤 타겟이라는 걸 생각한 건 아니었습니다.
말씀하신거처럼 정말 C++이 필요한 영역은 스크립트짜듯 쉽게 짜서 일단돌리는 코드짜기로는 안먹힐 듯한 분야라는 걸 생각하면 오히려 회의적인 입장을 취하게 되네요.

처음부터 STL과 std::string이 난무하는 Accelerated C++은 정말 독보적인 존재라고 할 수 있을 듯합니다.
사실 저도 처음에 Accelerated C++로 입문하려다가 쓴맛을 보고 윤성우씨의 C/C++ 입문서 두권 각각 읽고 입문했기 때문에, 이 글을 쓰면서도 그 결과가 Accelerated C++처럼 입문자를 위한 내용이지만 입문자에게는 오히려 난해한 내용이 되지 않을까 하는 걱정을 했습니다.
저에게 있어서 Accelerated C++은 오히려 C++을 알고 나서보니까, '그래 이게 C++이지'라는 생각을 들게 해준 책이었으니까요.

C++11에 맞춰서 새로 썼다는 C++ Primer 5판을 얼마전에 서점에서 읽어봤는데 딱히 C++11로 큰 구조가 바뀌었다는 느낌이 드는 책은 아니었고, 중간중간에 C++11에서 도입된 feature를 소개하는 듯한 느낌이라 큰 감흥은 없더군요...

Sdsf3qUr의 이미지

왜 'auto'라는 키워드가 생겼는 지 설명 하려면 결국 C++11 이전에 대해서 설명해야 하지 않을까요.