cpp,ryanjeong

style

int a {3};
int b(2);
int c = 4;
int d;
d=5;

vector v = {1,2,3};

dot asterisk operator in c++

https://stackoverflow.com/questions/2548555/dot-asterisk-operator-in-c

struct A {
    int a;
    int b;
};

int main() {
    A obj;
    int A::* ptr_to_memb = &A::b;

    obj.*ptr_to_memb = 5;

    ptr_to_memb = &A::a;

    obj.*ptr_to_memb = 7;

    // Both members of obj are now assigned
}

NL.25: Don't use void as an argument type

unique_ptr

#include <iostream>
#include <memory>

class T {
 public:
   ~T();
   int x;
};

T::~T() { std::cout << this->x << " Destructor\n"; }

std::unique_ptr<T> foo(int n) {
  std::unique_ptr<T> ptr(new T());
  ptr->x = n;
  std::cout << ptr->x << '\n';
  return std::move(ptr);
}

void bar(int n) {
  std::unique_ptr<T> ptr(new T());
  ptr->x = n;
  std::cout << ptr->x << '\n';
}

int main() {
  std::cout << "---before foo(100)---\n";
  auto ptr = foo(100);
  std::cout << "---after foo(100)---\n";

  std::cout << "---before bar(200)---\n";
  bar(200);
  std::cout << "---after bar(200)---\n";
  
  std::cout << "---before foo(300) and return its ref.---\n";
  const std::unique_ptr<T>& ref = foo(300);
  std::cout << "---after foo(300)---\n";

  return 0;
}

operator new and delete

ref: http://www.scs.stanford.edu/~dm/home/papers/c++-new.html

C++은 장난이다? - Bjarne Stroustrup 인터뷰
1998. 1. 1., Bjarne Stroustrup는 IEEE Computer지와 인터뷰 했다. 자연스럽게 편집자는 그가 C++을 창조한 당사자로서 7년간의 object-oriented 설계에 대한 종합적인 의견을 보여주리라 생각했다. 인터뷰가 끝날 즈음, Interviewer는 그의 기대 이상의 것을 알게 되었고, 편집자는 '산업계의 이익'을 위해 그 내용을 편집하기로 하였으나, 세상 만사가 그렇듯이 비밀은 없다. 다음은 편집되지 않은 완전한 대화 내용이며, 따라서 인터뷰 계획만큼 정리 되어 있진 않다.

Interviewer: 예, 당신이 소프트웨어 설계의 세계를 바꾼지도 수년이 지난 지금 어떻게 생각하십니까?
Stroustrup: 사실 당신이 도착하기 전 그것을 생각하고 있었죠. 기억하십니까? 모든 사람들이 'C'를 사용하고.. 문제는 그들이 아주 전문가였다는 점입니다. 대학에서도 C를 매우 훌륭히 가르쳤습니다. 졸업생들은 아주 유능했습니다. 이것이 문제가 되었습니다.

Interviewer: 문제요?
Stroustrup: 예. 모든 사람들이 코볼을 쓰던 시절을 기억하십니까?

Interviewer: 물론이죠.
Stroustrup: 글쎄요, 초창기에 이들은 거의 신이었죠. 높은 보수와 귀족 대우를 받았습니다.

Interviewer: 그런 시절이었죠.
Stroustrup: 그래요. 그래서 어떻게 되었습니까? IBM은 이것에 불만이었고 프로그래머들의 교육에 수백만불을 투자하여 마침내 백여명 정도의 인원을 길렀습니다.

Interviewer: 그게 바로 제가 그만둔 이유입니다. 보수가 1년만에 저널리스트 보다 적은 수준으로 떨어졌습니다.
Stroustrup: 그렇습니다. 'C'프로그래머에게도 마찬가지 일이 일어났죠.

Interviewer: 그렇군요, 근데 요점이 무었입니까?
Stroustrup: 글쎄요, 하루는 제 사무실에 앉아서 이 문제에 관해 수급 균형이 이뤄질 수 있게 할 작은 계획에 대해 생각했습니다. 이런 생각을 했죠.'무척 배우기 힘든 복잡한 언어가 있다면.. 그래서 아무도 감히 프로그래머가 되려고 하지 않을 만큼.. 과연 어떨까?' 실제로 많은 아이디어를 X 윈도우(X10)에서 가져왔습니다. 이 형편없는 그래픽 시스템은 Sun 3/60에서만 돌았습니다. 제가 원하는 모든 요소가 여기 있었죠. 우스꽝스러울 만큼 복잡한 문법, 애매한 함수, pseudo-OO 구조. 지금도 아무도 순전한 X 윈도우 코드를 작성치 않습니다. 제정신이라면 Motif만이 유일한 도구이죠.

Interviewer: 진심입니까..?
Stroustrup: 사실입니다. 실제로 다른 문제도 있었습니다. 유닉스가 C로 씌어졌지요, 즉 어떤 C 프로그래머도 쉽게 시스템 프로그래머가 될 수 있단 의미지요. 한때 메인프레임의 시스템 프로그래머가 얼마나 벌었는지 기억하십니까?

Interviewer: 물론입니다, 제가 한때 시스템 프로그램을 했었죠.
Stroustrup: 좋습니다, 따라서 유닉스와 언어를 결합하는 모든 시스템 콜들을 감춤으로써, 새로운 언어는 유닉스와의 결별하도록 해야 했습니다. 이는 DOS만 아는 사람들도 왠만한 소득을 벌 수 있게끔 했습니다.

Interviewer: 믿을 수 없는 예기군요...
Stroustrup: 글쎄요, 이미 시간이 지났지만 지금쯤은 사람들이 스스로 C++가 시간 낭비였다는 것 깨달았을 겁니다. 제 생각보다 훨씬 뒤늦은 일이지만요...

Interviewer: 그래서 실제로 어떤 식으로 하였습니까?
Stroustrup: 사실 단지 장난이었을 뿐이었습니다, 사람들이 제 책을 진지하게 받아들이리라 생각치 않았습니다. 두뇌가 반이라도 있다면 object-oriented 프로그래밍이 반직관적이고, 비논리적이고 비효율적이란 걸 알 수 있습니다.

Interviewer: 뭐라구요?
Stroustrup: 또 '재사용 가능 코드'를 보세요. 한번이라도 코드를 재사용하는 회사에 대해 들어 보셨습니까?

Interviewer: 글쎄요, 아니요, 하지만...
Stroustrup: 그렇습니다. 초기에 소수 회사가 시도는 했었죠. 오레곤의 Mentor Graphics사가 90, 91년도에 모든 코드를 C++로 재작성 하다가 크게 혼난적이 있습니다. 이에 대해 진심으로 유감스럽게 생각했었죠. 다만, 우리는 실수로부터 배워야 한다고 생각했습니다.

Interviewer: 물론입니다. 그래서 사람들이 교훈을 얻었습니까?
Stroustrup: 천만에요. 문제는, 대부분 회사들이 중요 실수들을 감추려 든다는 겁니다. 3천만불 손실을 주주들에게 설명하는 걸 어려워하지요. 그래도 공이 아주 없는 것은 아닙니다. 결국에는 뭔가 해내었지요.

Interviewer: 그래요? 글쎄, 그렇다면, OO가 성공했다는 거네요.
Stroustrup: 글쎄요, 거의.. 실행코드가 매우 컸습니다. 128MB RAM의 HP 웍스테이션에서 로드하는 데 5분 걸렸습니다. 실행는 더 엄청 오래 걸렸습니다. 실제 이것이 중요한 장애물이 되리라 생각했고 1주안에 모두 이를 알아차릴 것으로 짐작했습니다만, 아무도 신경쓰지 않더군요. Sun과 HP는 엄청난 파워의 머신을 판매하는 데 신이났죠, 단지 작은 프로그램들을 실행키 위해 엄청난 리소스를 필요로 하는.. ATT에서 첫 C++ 컴파일러를 가지고 'Hello world'를 컴파일 하고 2.1MB라는 믿을 수 없는 크기의 실행코드가 나왔었죠.

Interviewer: 네? 글쎄요, 컴파일러는 많이 개선되었죠, 그 이후로..
Stroustrup: 그럴까요? 최신 버젼의 g++에서 한번 해보세요. 1/2 메가 이상은 될겁니다. 또한, 세계 각지의 최근의 예들도 많습니다. British Telecom이 큰 위기를 당할뻔 했으나 운좋게 벗어나서 다시 시작할 수 있었습니다. 이들은 Australian Telecom보다 운이 좋았죠. 지금은 지멘스가 공룡을 만들고 있다는 군요. 실행코드를 저장하기 위한 하드웨어가 점점 커짐에 따라 우려도 커지고 있다고 합니다. 이래도 multiple inheritance가 좋습니까?

Interviewer: 예, 하지만 C++는 기본적으로 적절한 언어이지요.
Stroustrup: 그걸 믿습니까? 한번이라도 C++ 프로젝트를 해본 적이 있습니까? 사정은 이렇습니다:
아주 소규모의 프로젝트만이 첫 시도에 성공할 만큼 함정을 많이 만들었습니다. 연산자 overloading을 봅시다. 프로젝트가 끝날 무렵, 거의 모든 모듈에서 이걸 사용합니다. 보통, 사람들은 교육 과정에서 그랬듯이, 그래야만 한다고 생각하기 때문이죠. 같은 연산자가 각각의 모듈에서 제각기 다른 의미를 갖게 됩니다. 전부 모아 놓으면 백여개의 모듈이 됩니다. 이제 data hiding을 봅시다. 각 모듈들이 서로 대화하게 함으로써 문제를 만들어 내는 회사들을 보면 웃지 않을 수 없습니다. 'synergistic'이란 말은 프로젝트 관리자의 가슴을 후벼파기 위해 만들어 진 게 아닌가 합니다.

Interviewer: 정말 어처구니 없군요. 프로그래머의 보수를 높이기 위해 이 모든 걸 했다구요. 한심하군요.
Stroustrup: 꼭 그렇지만 않습니다. 누구나 선택이 있습니다. 이렇게 까지 문제가 커질 줄은 몰랐습니다. 어쨌든, 저는 기본적으로 성공했습니다. C++는 이제 죽어가고 있습니다. 하지만 프로그래머들은 여전히 높은 보수를 받습니다. 특히 이 모든 문제들을 관리하는 불쌍한 사람들은요.. 당신이 실제로 작성한 게 아니면, 방대한 C++ 소프트웨어 모듈을 관리하는 게 불가능 한 것을 알겁니다.

Interviewer: 어떻게요?
Stroustrup: 아는지 모르겠군요, typedef 기억하세요?

Interviewer: 그럼요.
Stroustrup: 변수 'RoofRaised'가 double precision 이란걸 겨우 찾아내기 위해 얼마나 오래 헤더 화일들을 뒤져야 하는지 아시죠? 대형 프로젝트에서 모든 클래스들에 있는 implicit한 typedef들을 찾는데 얼마나 걸릴지 생각해 보세요.

Interviewer: 그래서 어떻게 해서 성공했다는 거죠?

Stroustrup: 평균적인 'C' 프로젝트의 기간이 어느 정도 걸리죠? 약 6개월 입니다. 부인과 아이들이 있는 사람이 여유있게 살만큼 충분한 기간이 아닙니다. 동일한 프로젝트를 C++로 설계하면 어떨까요? 1년 내지 2년입니다. 대단하지요? 잘못된 결정이 이 모든 안정된 직업을 가져온 셈입니다. 또 있습니다. 오랜 기간 대학에서 C를 가르치지 않은 결과, 이제 훌륭한 C 프로그래머가 부족합니다. 특히 Unix 시스템 프로그래밍의 전문가가요. 오랫동안 'new'을 써온 지금, 'malloc'을 제대로 사용할 줄 아는 사람이 몇명이나 될까요? return 값을 체크하느라 신경쓰는 일도 없죠. 실제로 대부분 C++프로그래머들은 return값을 그냥 내버립니다. '-1'을 쓰는 일은 이제 추억이 되었습니다. 적어도 'throw', 'catch', 'try' 같은 걸 쫓아다니지 않고도 에러가 있다는 걸 알 수 있던 시절이었죠.

Interviewer: 하지만 inheritance는 시간 절약을 해주지 않습니까?
Stroustrup: 그럴까요? C프로젝트 계획과 C++프로젝트 계획의 차이를 아십니까? C++ 프로젝트의 계획 단계가 3배는 길게 걸립니다. 어떤 부분이 inherit를 해야 하고어떤 부분이 안되는지 정확히 가려내야 합니다. 그리고 나서는, 여전히 뭔가 잘못되어있지요. C 프로그램에서 memory leaks이 있을 수 있습니까? 지금은 이걸 찾는 게 회사들의 중요 일이 되었습니다. 대부분 회사들이 포기하고는 그냥 제품을 내놓습니다. leak이 있다는 걸 다 알면서도 단지 그걸 찾아내는 비용을 줄이기 위해서 입니다.

Interviewer: 그걸 해주는 tool들이 있쟎아요...
Stroustrup: 그것들의 대부분도 C++로 작성되었죠.

Interviewer: 이 인터뷰가 출판되면, 당신은 아마 린치를 당할 겁니다. 안그렇습니까?
Stroustrup: 글쎄요. 말씀 드렸듯이 C++는 이제 전성기를 지났습니다. 정상적인 회사라면 선행 시도(pilot trial)을 안해보고 C++ 프로젝트를 착수하지 않을 겁니다. 이를 통해서 재앙으로 가는 길이라는 걸 확인할 수 있어야 합니다. 그렇지 못하다면 그 결과는 그들의 책임입니다. 제가 Dennis Ritchie에게 C++로 Unix를 재작성토록 하려 했단 걸 아시죠?

Interviewer: 뭐라구요. 그가 뭐라고 했습니까?
Stroustrup: 다행히 그는 유머 감각이 있습니다. 그와 Brian이 제가 무슨 짓을 하고 있는지 알아냈다고 생각합니다. 그는 제가 좋아한다면, C++ 버젼의 DOS를 작성하는 걸 돕겠다고 했습니다.

Interviewer: 흥미가 있으셨습니까?
Stroustrup: 실제로 C++로 DOS를 작성했습니다. 끝나는 대로 demo를 드리겠습니다. 컴퓨터실의 Sparc 20상에서 실행시키고 있습니다. 4 CPU에서 엄청난 속도로 실행되고, 70메가 정도의 디스크를 차지합니다.

Interviewer: PC에서는 어떻습니까?
Stroustrup: 농담이십니까? Windows 95아시죠? 저는 Windows 95를 저의 최대 성공으로 생각합니다. 비록 제가 준비하기도 전에 시합을 끝낸 셈이지만요.

Interviewer: Unix++에 대한 아이디어는 정말 생각해볼만 합니다. 어디선가 누군가 시도를 하겠지요.
Stroustrup: 이 인터뷰를 읽은 다음엔 포기하겠죠.

Interviewer: 죄송합니다만, 이 인터뷰를 출판할 수 있을 것 같지 않군요.
Stroustrup: 하지만 이것은 세기의 스토리입니다. 제가 동료 프로그래머들을 위해 한 일로 인해 제가 기억되기를 바랄 뿐입니다. 오늘날 C++ 프로그래머들이 얼마나 버는지 아십니까?

Interviewer: 제가 알기로, 제일 잘나가는 프로그래머는 시간당 칠팔십불정도이지요.
Stroustrup: 그렇죠? 그 정도 될겁니다. 제가 C++에 집어넣은 모든 기능을 파악하는게 보통 일이 아닙니다. 그리고 전에 말씀드렸듯이, 모든 C++프로그래머들이 어떤 프로젝트를 하던지, C++의 그 모든 빌어먹을 요소들을 다 사용해야 한다는 강박관념 같은 걸 느낍니다. 이건 가끔 저를 화나게 합니다, 그게 아무리 저의 처음 의도 였지만요. 결국 저는 C++언어를 좋아합니다.

Interviewer: 전엔 좋아하지 않았습니까?
Stroustrup: 싫어했었죠. 심지어 C++가 지저분하지 않습니까? 하지만 책의 인세가 들어오기 시작하면서... 글쎄요, 아시겠지요?

Interviewer: 잠깐요. reference는 어떤가요? C 포인터보다 개선된 것 아닙니까?
Stroustrup: 음.. 그거에 대해 항상 의문이었습니다. 처음엔 개선이라고 여겼습니다. 근데, 하루는 C++를 처음부터 써온 친구와 얘기할 기회가 있었습니다. 그는 변수들이 reference되었는지 dereference되었는지 도무지 기억 할 수가 없어서 항상 포인터를 쓴다더군요. '*'덕분에 쉽게 알 수 있다더군요.

Interviewer: 글쎄요, 보통 이때쯤이면 '대단히 고맙습니다'라고 말하게 되는데 오늘은 그렇기 힘들겠는데요.
Stroustrup: 인터뷰를 출판해 주십시오. 요새 제 양심이 많이 좋아지고 있습니다.

Interviewer: 나중에 알려드리겠습니다만, 편집장께서 뭐라고 할지 알 수 있습니다.
Stroustrup: 어쨌든 누가 믿겠습니까? 테입 복사한 걸 보내주실 수 있습니까?

Interviewer: 그럼요.

The Real Stroustrup Interview
C++의 아버지가 설명하는, 표준 C++이 단순한 객체지향 언어가 아닌 이유
"IEEE Computer", pp.110-114, June, 1998.

C++의 디자인과 발전(Addison Wesley, 1994)에 있어서, Bjarne Stroustrup 은 아래와 같이 논의했다. "프로그래밍 언어는 실제로 세계(world)의 극히 작은 부분입니다. 그러므로 그것은 너무 심각하게 간주되어서는 안 됩니다. 일부분(proportion)의 감각(역자주: '프로그래밍 언어는 전 세계에 비하면, 매우 작은 부분이다'는 감각)을 유지하면서, 그리고 더욱 중요하게 유모어(humor) 감각을 유지해야 합니다. 중요한 프로그래밍 언어 중에서, C++는 익살과 농담의 풍부한 자원입니다. 그것은 우연이 아닙니다."

지난 몇 달 동안, Stroustrup과 Computer지와의 가짜(hoax) 인터뷰가 사이 버스페이스에서 회자(make round)되었다. 우리는 그 사건에 대해 유감스럽게 (regret) 생각한다. 하지만, 그것이 우리로 하여금 C++의 대부와, 표준 C++과 일반적인 소프트웨어 개발에 대한 그의 통찰력(insight)을 나눌 좋은 기회를 허락하였다. 우리는 또한 그의 지속적인 부분(proportion)과 유머(humor)에 대한 감각을 증명할 수 있었다(그는 그 우스꽝스러운 인터뷰를 만약 그 자신이 썼다면, 더 재미있는 개작(parody)이 되었을 거라고 제안했다).

Scott Hamilton, Computer
표준 C++(STANDARD C++)
Computer: ISO는 표준 C++을 1997년 11월 승인하였습니다. 그리고 당신은 당신의 책 The C++ Programming Language(Addison Wesley, 1997)의 3번째 판을 출판하였습니다. 지난 몇 년간 C++가 어떻게 발전하였으며, ISO 표 준이 C++ 공동체(community)에 무슨 의미를 갖는지 이야기해 주시겠습니까?

Stroustrup: 마침내 완벽하고(complete), 상세하며(detailed), 견고한(stable) C++의 정의를 내렸다는 것은 위대한 일입니다. 이것은 C++ 공동체에 직접적이고 간접적으로 무수한 도움이 될 것입니다. 컴파일러 제공자들은, 표준 위원회의 내용들을 따라가는 것(catching up with the standards committee)에서 이제는 구현의 질에 관한 논쟁으로 쟁점을 이동시키기 시작함에 따라서, 분명히 우리는 더 좋은 개발 환경을 접하게 될 것입니다. 이것은 이미 진행중입니다.

표준을 수용하는 구현은 툴의 혜택과 큰 공통 플랫폼을 제공하는 라이브러리 제공자의 혜택을 경험하게 할 것입니다.

표준은 프로그래머에게 새로운 기술과 함께 더 도전적인 기회를 제공할 것 입니다. 제품의 코드에서 비실제적인 코드를 사용했던 프로그래밍 양식은 실제적인 계획(proposition)이 되어가고 있습니다. 이처럼, 더 유연하고(flexible), 일반적이고(general), 빠른(faster), 그리고 더 유지하기 쉬운 코드를 사용할 수 있습니다.

일반적으로, 우리는 냉정을 유지해야 하고, "개선된" 기교의 주연(orgy)에 탐닉(indulge)해서는 안 됩니다(역자주: 개선된 C++의 기교를 사용하는 것은 중요한 일이 아니라는 주장). 기적은 여전히 없습니다. 그리고 좋은 코드는 여전히 탄탄한 디자인과 대부분 직접적으로 매치되는 코드입니다. 그러나, 바로 지금은, 어떤 기교가 특정한 사람, 조직, 혹은 프로젝트에 적당한지, 실험하고 살펴볼 시간입니다. The C++ Programming Language의 많은 부분은 이러한 기교와 그것들이 제공하는 흥정관계(trade-offs)를 기술하고 있습니다.

이러한 진보를 가능하게 하는, 우리가 눈으로 볼 수 있는 부분은, 언어의 새 로운 큰 기능 - 템플릿(template), 예외처리(exception), 실행시 형 정보 (runtime type information), 이름공간(namespace) - 과 표준 라이브러리입니다. 언어의 자세한 부분의 작은 개선 또한 중요합니다. 우리는 이제 여러 해 동안 사용 가능했던 유용한 것들을 대부분 가지게 되었습니다. 하지만, 호환성과 제품의 품질이 필요로 하는 곳에 대해서는 그것들에 크게 의존할 수 없었습니다. 이것은 우리로 하여금, 우리의 라이브러리와 응용프로그램을 설계하는 데 있어서 최적이 아닌 차선(suboptimal)을 선택하도록 하였습니다. 그러나, 곧(올 해 1998년) 모든 큰 구현이 표준 C++를 탄탄하게 지원하게 될 것입니 다.

언어와 프로그래밍 기교의 관점에서 C++에 가해진 가장 중요한 변화는, 정 적으로 검사 가능한 형 안정성(staticaly verifiable type safety)에 대한 강조의 계속적인 증가와 템플릿의 증가된 유연성입니다. 유연한 템플릿은 우아함 (elegance)(역자주: 명시적인 형 변환이 필요없는 C++ 프로그램은 읽기 쉽다. 이것을 우아하다고 표현한 것 같다)과 효율성(efficiency)에 주목하는 형 안정 성을 강조하기 위해서 필요합니다.
새로운 기술의 실행가능성(Feasibility of new techniques)
Computer: 당신은 말하기를 "숙련된 C++ 프로그래머조차도 지난 몇 년 동안 인지하지 못한 것은 그러한 새로운 기능이 아니라, 기본적인 새로운 프로그래밍 기교를 가능하게 하는 기능들간의 관계의 변화이다." 라고 하였습니다. 어떻게 이것이 표준 C++에 적용 가능한지 몇 가지 예를 들어주시겠습니까?

Stroustrup: 오버로딩이나 템플릿이 함께 사용되어 우아하고 효과적인 형 안정 컨테이너의 중요한 역할을 한다는 것을 모르고도, 오버로딩과 템플릿은 규칙들을 각각 공부하는 것은 쉽습니다. 이러한 연결(역자주: 오버로딩과 템플릿의 연결)은 컨테이너에서 공통적으로 많이 사용되는 근본적인 알고리즘을 자세하게 살펴볼 때에만 명확해 집니다. 그림 1a의 프로그램 조각(segment)을 고려해 봅시다. count()의 첫 번째 호출은 정수 벡터에서 7의 횟수를 헤아립니다. count()의 두 번째 호출은 스트링 리스트에서 "seven"의 횟수를 헤아립니다.

// Figure 1a:

void f(vector& vi, list& ls)
{
int n1 = count(vi.begin(),vi.end(),7);
int n2 = count(ls.begin(),ls.end(),"seven");
// ...
}

// Figure 1b:

template
int count(Iter first, Iter last, T value)
{
int c = 0;
while (first!=last) {
if (*first == value) c++;
++first;
}
return c;
}

그림 1. 기능들간의 관계의 차이는 근본적인 새로운 프로그래밍 기교를 가능하게 한다: (a) 정수 벡터의 7을 헤아리는 알고리즘과 스트링 리스트의 "seven"을 헤아리는 알고리즘이 템플릿을 이용하여 둘 모두를 다루는 (b) 로 구현할 수 있다.

오버로딩을 지원하는 각각의 언어에서 이것을 구현하는 방법은 다양합니다. 템플릿이 주어지면, 둘 모두의 호출을 다루는 하나의 함수를 그림 1b처럼 만들 수 있습니다. 이 템플릿은 둘의 호출에 대해 최적으로 확장(역자주: 실제로 템플릿 함수는 호출되는 것이 아니라, 컴파일 시간에 템플릿을 호출한 문법에 따라 각각의 경우로 만들어진다. 그리고 실제로 만들어진 이 함수가 호출된다. 이것을 확장(expansion)이라 한다)될 것입니다. 이 count()는 표준 라이브러리 의 count()와 거의 유사합니다. 그러므로 사용자가 count()를 직접 작성할 필 요는 없습니다. count()함수는 그 자체가 오버로딩에 의존하고 있습니다: 명확 히 등호 연산자 ==는 정수와 스트링에 대해 오버로딩되어 있습니다. 게다가 * 와 ++는 각각 벡터와 리스트를 위한 반복 형(iterator type)을 위하여 "역참조(dereference)"와 "다음 요소 참조"로 오버로딩되어 있습니다. 다시말하면, *와 ++는 포인터를 위해 그것들이 가지는 의미가 주어졌습니다.

count()의 이러한 정의는 C++ 표준 라이브러리의 컨테이너와 알고리즘에서 사용된 중요 기교의 결합을 설명합니다. 이러한 기교는 유용합니다. 그리고 그것은 오로지 기본적인 언어의 규칙에 의해서만 간단하게 기술할 수 없습니다.

// Figure 2a:

template
int count_if(Iter first, Iter last, Predicate pred)
{
int c = 0;
while (first!=last) {
if (pred(*first)) c++;
++first;
}
return c;
}

// Figure 2b:

bool less_than_7(int i) { return i<7; }

void f2(vector& vi, list& li)
{
int n1 = count_if(vi.begin(),vi.end(),less_than_7);
int n2 = count_if(li.begin(),li.end(),less_than_7);
// ...
}

그림 2. 카운트 예제의 더 진보된 버전: (a)는 predicate를 만족하는 요소의 개수를 헤아린다. 예를 들면 (b)는 7보다 작은 요소의 수를 헤아린다.

그림 2a에 제시된 좀 더 진보된 예를 참조해 봅시다. 값의 횟수를 헤아리는 대신에, count_if()는 predicate를 만족시키는 요소의 개수를 헤아립니다. 예를 들면, 그림 2b처럼 7보다 작은 값을 가지는 요소의 개수를 헤아릴 수 있습니다.

이러한 기교를 일반화하여, 어떠한 형의 어떠한 값도 비교하는 것을 다루기 위해서는 함수 객체(function object) - 그림 3a처럼 객체가 함수처럼 불러 내어질(invoke) 수 있는 클래스 - 를 선언하는 것이 필요합니다. 그림 3b처럼 생성자 비교를 원하는 값의 참조를 저장합니다. 그리고 () 연산자는 비교를 수행합니다. 바꾸어 말하면, vi에 있는 요소중에 7보다 작은 요소의 수를 헤아리고, ls에 있는 요소중에 "seven"보다 작은 요소의 수를 헤아립니다.

// Figure 3a:

template class Less_than {
const T v;
public:
Less_than(const T& vv) :v(vv) {} // constructor
bool operator()(const T& e) { return e };

// Figure 3b:

void f3(vector& vi, list& ls)
{
int n1 = count_if(vi.begin(),vi.end(),
Less_than(7));
int n2 = count_if(ls.begin(),ls.end(),
Less_than("seven"));
// ...
}

그림 3. 어떤 형의 어떤 값도 비교하는 것을 다루기 위해, 우리는 클래스의 객체가 함수처럼 불러낼 수 있는 (a) 클래스를 정의한다. 생성자는 (b)에서 처럼, 비교하고자 하는 값의 참조를 저장한다(역자주: count_if()의 세 번째 파라미터는 Less_than 객체를 생성하는 문장이다. 이 임시 객체가 파라미터로 전달된다. 물론 count_if()의 내부에서는 이 객체의 오버로딩된 연산자 ()를 사용한다).

생성된 코드는 매우 효율적이며, 특별히 비교를 수행하고, 다음 요소를 가져오는 등의 작업을 하는데, 함수 호출 - 혹은 비슷한 늦은 연산자 - 을 사용하지 않는다는 것(역자주: 자세한 사항은 '함수 객체'를 참고하라)은 언급할 만 합니다.

의심할 여지도 없이, 이 코드는 C++ 프로그래머가 아닌 사람에게, 혹은 템플릿과 오버로딩의 개념을 익히지 못한 C++ 프로그램머에게 조차도 이상하게 보일 것입니다. 물론 이것은 이 예제를 여기서 제시한 이유 중의 일부입니다. 그러나, 진짜 의도(bottom line)는 이 기교가 당신에게 효율적이고, 형 안정적 이고, 일반적인 코드를 작성하게 한다는 것입니다. 함수형 언어(functional language)(역자주: LIST같은 언어를 함수형 언어라 한다)에 익숙한 사람들은 이러한 기교가 그러한 언어에서 선구적으로 개척된 기교와 유사하다는 것을 알아차렸을 것입니다.

언어의 모습은 분리되었을 때 근본적으로 지루합니다. 그리고 그것은 좋은 시스템 설계로부터 흩뜨릴 수 있습니다(오직 언어가 살아남아야 할 프로그래밍 기교의 측면에서).
표준 라이브러리(The Standard Library)
Computer: 표준 라이브러리는 어떻습니까? 또한 그것이 C++ 공동체에 무슨 영향을 끼칠까요?

Stroustrup: 표준 라이브러리의 가장 새롭고 흥미로운 부분은 컨테이너와 알고리즘의 일반적이고 확장 가능한 골격(framework)입니다. 그것은 종종 STL 이라고 불리는데, 근본적으로 Alex Stepanov의 작품입니다(그 당시 Hewlett-Packard에서 지금은 Silicon Graphics에 있다).

Alex는 확고하게(uncompromisingly) 일반적이면서 효율적인 근본적인 알고리즘을 제공하기 위해 일을 했습니다. 예를 들면, 자료 구조에서 요소를 찾는 것, 컨테이너를 정렬하는 것, 자료 구조에서 값의 횟수를 헤아리는 것 등입니 다. 그러한 알고리즘은 많은 계산에서 근본적인 것입니다.

Alex는 많은 종류의 언어를 가지고 연구했습니다. 그리고 몇 년간 공동 연구자들이 있었습니다. 주목할만한 이들은 David Musser(Rensselaer Polytechnic Institute), Meng Lee(HP Labs), Andrew Koenig(AT&T Labs) 등 입니다. 제가 STL에 공헌한 부분은 매우 작지만 중요하다고 생각합니다: 저는 어댑터(adapter)라고 불리는 mem_fun()을 디자인했습니다. 그것은 다형 객체(polymorphic object)의 컨테이너를 위해서 표준 알고리즘이 사용되는 것을 제공합니다(역자주: 어댑터는 크기가 동적인 가변 객체를 컨테이너 연산의 대상으로 하기 위한 메모리 할당 및 처리 루틴을 말하는 것 같다). 이처럼, 객체 지향 기술을 시도하는 것이 깔끔하게 표준 라이브러리의 일반적인 프로그래밍 골격에 포함되었습니다.

다소 놀랍게도, STL은 제가 몇년 전에 개발한 C++을 위한 표준 컨테이너의 좋은 집합을 결정하는 판단기준과 일치되었습니다. 1년 후, STL에 대해 의논하고 마무리한 후, ISO C++ 위원회는 STL을 C++를 위한 표준 라이브러리의 중요한 부분으로 받아들였습니다. 저의 판단기준도 포함되었습니다.
간단한 기본 연산의 확고한 효율성(예를 들면, 배열의 인덱싱 (subscripting)이 함수 호출의 비용을 유발해서는 안 된다);

형 안정성(type-safety)(컨테이너로부터의 객체는 명시적인(explicit) 혹은 함축적인(implicit) 형 변환 없이 사용 가능해야 한다);

일반성(라이브러리는 벡터,리스트,맵 같은 몇 개의 컨테이터를 제공해야 한다);

확장성(내가 필요로하는 컨테이너를 라이브러리가 제공하지 못하는 경 우, 내가 컨테이터를 만들어 표준 컨테이너처럼 사용할 수 있어야 한다).
약간의 수정과 추가를 거친 STL을 채택함으로써, 위원회에서 해야 할 끔찍한 디자인을 피할 수 있었습니다.

명확히, C++ 표준 위원회의 시간제 근무자의 그룹이 프로그래머가 유용하 다고 판단하는 모든 라이브러리의 기능을 제공할 수 없습니다. 결과적으로 중 요한 쟁점은 무엇이 표준 라이브러리에 포함되어야 하고, 무엇이 기업과 개인 이 제공하는 것으로 남겨져야 하는 것을 결정하는 것이었습니다.

우리는 무엇이 포함되어야 하는가의 길잡이로 "독립적으로 개발된 라이브러 리 사이의 통신 역할을 하는데 필요한 것"을 사용하기로 하였습니다. 이처럼, I/O, 스트링, 컨테이너가 큰 촛점이 되었습니다. 우리는 표준 C 라이브러리와 수 계산을 위한 몇 기능을 역사적인 이유 때문에 포함시켰습니다. 하지만, 잠 재적으로 유용한 많은 기능들 - 날짜와 통화, 정규 표현 매칭, 그래픽 - 을 남겨두었습니다. 다행히도, 이러한 기능들은 공개 혹은 상업적으로 이용 가능 합니다.

표준 라이브러리는 프로그래머가 바퀴를 다시 발명하는 것을 구해냅니다. 특별히, 표준 컨테이너는 초보자나 숙련자 모두에게 높은 수준의 프로그램 (high level programming)을 허락합니다. 쉬운 일을 간단히 처리하는, 그림 4 의 간단한 프로그램을 고려해 봅시다.

// Figure 4:

int main()
{
cout << "Please enter your first name:\n";
string name;
cin >> name; // read into name cout
<< "Hello" << name << "!\n";
}

그림 4. 간단하게 일을 처리하는 "Hello" 프로그램

매크로도 이용하지 않고, 명시적인 메모리 관리나 다른 고 수준 언어의 기 능을 이용하지 않으며, 리소스의 제한도 받지 않습니다. 특별히, 만약 어떤 익살꾼(joker)이 자신의 첫 번째 이름으로 30,000자를 적는다고 하더라도, 에러 나 오버플로우 없이 프로그램은 충실히 이름을 출력할 것입니다.

표준 라이브러리를 이용하는 것은 C++가 배워지던 방법의 혁명을 일으킬 수 있고 일으켜야 합니다. 이제 C++을 고수준 언어로써 배우는 것이 가능합 니다. 학생들은 이제 필요할 때만 낮은 수준의 프로그래밍 기능들을 다루면 됩니다. 혹은 낮은 수준의 프로그래밍 기능들을 언급할 적절한 실력들이 쌓이 고 나서 보아도 됩니다.

이처럼, 표준 라이브러리는 도구와 교사로서의 역할을 할 것입니다.
복잡성, C++와 객체지향프로그래밍(COMPLEXITY, C++, AND OOP)
Computer: The C++ Programming Language에서 당신은 말하기를 "정상적 인 실용적인(practical) 프로그래머들은 생산성, 유지보수, 유연성과 어떠한 종 류와 스케일의 프로젝트에 대한 품질에 대해서도 놀랄만한 향상을 달성했다." 고 했습니다. 그러나 아직 몇몇 비평가들은 C++과 일반적인 OO는 여전히 너 무 복잡하고, 교정 유지보수(corrective-maintenance)문제를 일으키며, 큰 시스 템에서의 유지 문제가 있다고 합니다. 어쨌던 이러한 비평이, 당신 자신의 경 험으로 볼 때, C++로 설계하는 큰 시스템의 개발에 적용되는 것이라 생각합 니까?

Stroustrup: 저의 개인적인 경험으로, OO 설계와 OO 프로그래밍은 전통적인 절차적인 방법을 통해서 당신이 얻을 수 있는 것보다 좋은 코드를 제공할 것 입니다. 그러한 코드는 더욱 유연하고(flexible), 더욱 확장 가능하며 (extensible), 심각한 수행상의 부하(overhead)없이 유지 보수 가능한 (maintainable) 코드입니다. 위의 개인적인 의견에 반대되는 제가 좋아할 만한 강한 증거는 없습니다. 하지만, AT&T 내부에서의 몇몇 연구와 다른 연구들 은 이러한 의견을 지지합니다.

두 요소가 쟁점을 난처하게 합니다: "객체 지향적"인 것이 정말로 무엇인지 에 대한 일반적인 동의가 없습니다. 또한 토론은 좀체 경험을 충분히 설명하 지 못합니다. "OO의 문제"의 많은 부분은 정말로 OO가 무엇인지 모르는 부분적인 이해를 가진 사람들이 야망찬 프로젝트를 진행하는데서 비롯합니다.

그렇다면 OO는 무엇입니까? 확실히 좋은 프로그램 모두가 객체 지향적인 것은 아니며, 객체 지향적인 모든 프로그램이 좋은 것도 아닙니다. 만약 그렇 다면 "객체 지향적"인 것이 단순히 "좋은 것"을 의미합니다. 그리고 이것은 당신이 실제적인 결정을 내려야 할 때 개념을 혼동하게 하는 하나의 추가된 전공용어(buzzword)에 불과합니다. 저는 OOP를 클래스의 상속과 가상함수(어떤 언어에서는 메서드(method)라고 하는)를 많은 사용한 프로그램과 동일시하 곤 합니다. 이 정의는 역사적으로는 정확합니다. 왜냐하면, 클래스 계층과 가 상 함수는 그 당시 시뮬라(Simula)와 다른 언어를 구분짓는 철학이었기 때문 입니다. 사실, Smalltalk이 가장 중요하게 강조된 것은 시뮬라 유산의 이러한 관점 때문입니다.

클래스 계층과 가상 함수에 기초하여 OO를 정의하는 것은 OO가 성공할 것 같은 곳으로의 몇 지침을 제공하기 때문에 실용적입니다. 당신은, 정확하게 같 은 형이 아니지만 공통의 인터페이스로 조작될 수 있는 객체를 위한, 구현을 공유할 수 있는 개념들의 변체(variant)를 위한 계층적인 순서를 가진 개념들 을 찾습니다. 몇 예제와 약간의 경험을 한다면, 이것이 디자인을 위한 매우 강 력한 접근의 기초가 되는 것을 알것입니다.

그러나, 모든 개념이 자연스럽고 유용하게 계층(hierarchy)과 적합한 것은 아닙니다. 개념들간의 모든 관계가 계층적인 것도 아니고, 모든 문제에 대해 객체에 중심한 접근이 최선인 것도 아닙니다. 예를 들면, 몇 문제들은 근본적 으로 알고리즘적(algorithmic)입니다. 결론적으로, 일반 목적의 프로그래밍 언 어는 다양한 사고와 다양한 프로그래밍 스타일을 지원해야 합니다. 이러한 다 양성은 풀이해야 할 문제의 다양성과 문제 풀이의 다양성에 기인합니다. C++ 은 다양한 프로그래밍 스타일을 지원합니다. 그러므로, 객체 지향 언어라기 보다는 멀티패러다임(multiparadigm) - 이름을 꼭 붙여야 한다면 - 언어라고 불리는 것이 더 적당합니다.

"좋은 것" - 이해하기 쉽고, 유연하고, 효율적인 - 의 기준을 대부분 만족시 키는 디자인의 예로 전통적인 절차 코드를 사용한 재귀 경향 파서(recursive descent parser)가(역자주: 실행 가능한 코드를 생성하는 번역기를 파서 (parser)라 하는데, 재귀 호출을 사용하며, 주로 수식을 번역하기 위해 사용한 다) 있다. 다른 예로 STL이 있습니다. 이것은 전통적인 절차적인 코드와 파라미터적인 다형성(역자주: 이름에 의한 다형성이 아닌)에 전적으로 의존하는 컨테이너와 알고리즘을 포함한 일반 라이브러리입니다.

저는 단 하나의 프로그래밍 패러다임만 지원하는 언어는 제한적이라는 것을 발견했습니다. 그것은 간단함(simplicity)을 사는 대신, 프로그래머에게 구속복 (straitjacket)을 입히거나, 언어의 복잡함을 응용 프로그램의 복잡함으로 전가 시킵니다. 이것은 특정 목적 언어(special-purpose language)에는 적합하지만, 범용 언어(general-purpose language)에는 적합하지 않습니다.

저는 종종 C++를 시스템 프로그래밍으로 편향된 범용 언어라고 특징 지웁 니다. 다음을 지원하는 "더 나은 C"로 생각하는 것이죠.
데이터 추상화,

객체 지향 프로그래밍, 그리고

일반적인 프로르래밍(generic programming).
자연히, 이것은 하나의 접근법만을 허용하는 언어에 비해 복잡함을 증가시 킵니다. 저는 이러한 관점 - 문제 영역마다 최선인 각각의 디자인과 프로그래 밍 접근법이 있다 - 이 어떤 이들을 화나게 한다는 것을 주목했습니다. 확실 히, 모든 사람에게 혹은 모든 문제에 올바른 한가지 방법이 있다는 관점은 거 절합니다. 세계는 근본적으로 간단하다는 사실을 열정적으로 믿고 싶어하는 사람들은 제가 이것을 단지 프로그래밍 언어에 대해서만 적용한다는 사실과는 상관없이 격노(fury)합니다. 결국, 프로그래밍 언어는 시스템을 설계하기 위한 많은 도구들 중의 하나입니다.

이러한 두 관점을 모두 해결하는 이상적인 방법은 모든 프로그래밍 스타일 을 효율적으로 지원하는 간단한 프리미티브(primitive)의 집합을 지원하는 언 어를 가지는 것입니다. 이것이 반복적으로 계속 시도되기는 했지만, 달성되지 는 - 저의 의견에 - 못했습니다.
자바와 C++(JAVA AND C++)
Computer: 위에서와 같은 논쟁이 납득할만하게 자바(Java)로 확장 가능하다 고 봅니다. Sun이 주장하기를 700,000명의 자바 프로그래머가 있다고 합니다 (비교해서 C++ 프로그래머는 1,500,000명 정도). 당신은 C++가 C와 호환될 필 요도 없으며, 자바가 당신이 고안한 언어가 아니라는 주장을 고집합니다. 이러 한 질문을 1000번 이상 받았다면 당신은 무슨 말을 할 것입니까?

Stroustrup: 오늘날, 저는 항상 자바에 대해서 질문 받습니다. 그리고 항상 대답하기는 어렵습니다. 제가 만약 약간 부정적인 것을 말한다면, 무례한 것으로 느껴집니다. 제가 만약 약간 긍정적인 것을 말한다면, 자바를 둘러싼 상업 적인 공간(commercial hype)에 뛰어드는 것 같고, 자바 공동체의 부분으로부 터 흘러나오는 불운한 반 C++ 선전(the unfortunate anti-C++ propaganda)에 뛰어드는 느낌이 들기 때문입니다.

저는 사람들에게 상업적인 라이벌 상태가 아닌, 자신이 개발해야 하는 디자 인 기준에 따라 두 개의 언어 중 적절한 것을 선택하라고 권장합니다. 저는 C++을 위한 디자인 표준(cirteria)을 The Design and Evolution of C++에서 개괄해 놓았습니다. 그리고 자바는 이러한 기준을 만족시키는 시작조차 못하고 있습니다. 자바를 만병통치약으로 생각하지 않고 프로그래밍 언어의 하나로 생각하는 것은 좋습니다. 결국, C++는 자바의 디자인 목표와 완벽하게 일 치하지 않습니다. 그러나, 자바가 유일한 프로그래밍 언어로써 진급된다면, 자바의 결함과 제한은 심각하게 될 것입니다.

C++을 개발하는데 적용된 기준이 자바에는 적용되지 않는 몇 가지 예가 아래에 있습니다.
서로 다른 언어로부터 쓰여진 프로그램 부분들을 효과적으로 조합하는 능력

다양한 디자인 스타일과 프로그램 스타일

기정의 타입(built-in type)과 맞먹는 효율을 가진 사용자 정의 타입

기정의 타입과 사용자 정의 타입의 일관된 처리(treatment)

STL처럼 실행시 부담없는 일반 컨테이터(generic container)를 사용하는 능력
프로그래머들이 우아하고 효율적인 코드를 작성할 수 있도록 제가 C++을 디자인했습니다. 많은 응용프로그램을 위해서, 우아함과 효율성을 타협하기를 원하지 않을 때 C++은 여전히 최상의 선택입니다.

저는 어떻게 사람들이 "프로그래머"를 세는지 의문입니다. 학생이 프로그래 머입니까? PC에 컴파일러를 가진 사람은 모두 프로그래머입니까? 저는 C++ 을 위해서 인용된 숫자를 이해합니다. 그것은 보수적이고 그럴듯합니다. 그것 은 지난 해 실제 팔린 금액을 위한 C++ 프로그램의 수를 적절히 근사화한 것 입니다. 저는 Sun에서 주장하는 자바 프로그래머의 수가 같은 근거인지 의문 입니다. 부수적으로, 컴파일러 판매, 책 판매, C++ 수강생 수 등의 확실한 수 에 근거해서, 제가 추측하기로 C++ 프로그래머는 매년 10%∼20%증가하고 있 습니다.

그리고 저는 자바 팬(fan)이 아닙니다. 저는 과대 선전(hype)을 싫어합니다. 저는 프로그래머가 아닌 사람에게 프로그래밍 툴을 판매하는 시장 전략을 싫 어합니다. 저는 독점적인 언어를 싫어합니다. 그리고 저는 많은 프로그래밍 언 어를 좋아합니다. 기술적인 측면에서, 자바는 저에게 다른 언어에서 받았던 것 처럼, "와 깔끔한데!"란 인상을 주지 못했습니다. 자바는 제가 생각하기에 제한적인 형태로 다른 유명한 언어의 기능들을 제공합니다.

자바는 많은 것을 C++로부터 빌려 왔습니다. 하지만 그렇게 많이는 아니며, 원하는 만큼의 이해와 맛(taste)도 빌려오지 못했습니다. 자바를 위한 중요한 약속들을 지키기 위해선, 자바는 성장해야 합니다. 이러한 전개는 C++보다 간 단하게 라는 자바의 주장과 타협할지도 모릅니다. 그러나 저의 추측에 그러한 노력은 현재의 것보다 더 좋은 자바 언어를 만들 것입니다. 현재, 자바는 언어 의 특징들과 "표준" 라이브러리를 꽤(quite a pace) 축적하고 있는 것처럼 보 입니다. 저는 자바 버전의 템플릿이 나타날 것을 기대하고 있습니다.

자바와 그의 공동체가 성숙해가면서, 활기있고 활기있게 하는 철학 (live-and-let-live philosophy)을 희망적으로 채택할 것입니다. 이것은 자바가 프로 프로그래머들의 소중한 도구(tool chest)중의 한 언어로 자리잡게 할 것 입니다.
도구(TOOLS)
Computer: 지난 몇 년간 어떤 방법으로 시스템이 변화했습니까? 그리고 C++의 활동범위(arena)와 일반적인 시스템 디자인에 무엇이 더 필요합니까? C++가 비교적 성장한 이 시점에서, 사용할 수 있는 C++ 툴(tool)들을 어떻게 평가하겠습니까? 그리고 여전히 개선되어야 하는 것은 어떤 것들입니까?

Stroustrup: 먼저, 컴파일러, 디버거, 프로파일러(profiler)(역주: 프로그램의 성능 분석을 위한 도구), 데이터베이스 인터페이스, GUI 빌더, CAD 툴과 ISO 표준을 지원하는 기타 기본 툴들을 살펴보고자 합니다. 예를 들면, 저는 데이 터베이스 질의의 결과를 STL 컨테이너 혹은 적절한 객체 형의 istream으로 얻고 싶습니다. 툴 벤더(vendor)는 좋은 출발을 하였습니다. 하지만, 컴파일러나 다른 소스 코드 분석기에 의존적인 작업을 너무 많이 하였습니다.

제가 리스트한 기본 도구들은 무엇이 바뀐지에 대한 부분적인 대답에 불과 합니다. 과거 몇 년 동안, 많은 수의 프로그래머들이 훌륭한 도구와 시스템 기 능을 제공하는 인터페이스 코드에 의존해 왔습니다. 이러한 도구들은 지루하 고, 에러 발생이 쉬운 작업으로부터 프로그래머들을 구제하는데 필수적입니다. 하지만, 프로그래머가(혹은 고용인이) 툴 제공자의 포로가 되는 위험에 처해 있습니다.

종종 이러한 도구들은 전통적인 프로그래밍 언어에 비해 더욱 복잡하며, 표 준은 거의 없습니다. 저는 독점성이(nonproprietary) 없는 도구와 라이브러리 를 추천하고 싶습니다. 짧은 안목으로 보면, 예를 들면 10년 정도, 많은 그러 한 표준은 형식적인 ISO나 IEEE의 표준보다 산업계의 표준역할을 합니다. 하지만, 건강한 소프트웨어 산업을 위해, 중요 인터페이스는 잘 정의되고 대중 이 사용할 수 있는 것이 필수입니다.

COM이나 CORBA같은 시스템 레벨 객체를 위한 표준의 중요성이 증가하는 가운데, C++가 그러한 것들과 깨끗하고(clean), 잘 문서화되어, 사용하기 쉽게 결합될 수 있는 것은 특별히 중요합니다. 불행하게도, 그러한 "표준 작업" - 모두에게 이로운 - 은 누구에게도 짧은 안목의 이점을 제공하지 않기 때문에 소흘히 됩니다.

저는 사용 가능한 C++ 툴들을 평가하지 않겠습니다. 그것들은 매우 훌륭하 며, 다른 언어의 어떤 툴보다 더 좋습니다. 그러나, 프로그래머로서, 저는 당연 히 더 좋은 품질의 툴들을 바랍니다. 개인적으로, C++ 소스코드를 분석하는 더 좋은 툴들을 기대하고 있습니다. 저는 또한 C++ 컴파일러 벤더들이 신제 품을 개발하는 것보다, 자사 컴파일러의 품질과 수행 능력을 향상시키는데 예 산을 조금 더 투자하기를 기대합니다. 컴파일러의 실제적인 성능향상은 새로 운 버전의 완전한 C++ 컴파일러를 위한 시간보다 다소 저렴합니다. 그러나, 중요한 사용자들이 적응 테스팅(conformance testing)이나 벤치마킹 (benchmarking)을 요구하는 것을 시작하지 않는다면, 벤더들이 광고상 좋게 보이는 것을 위해 자원을 사용할 것을 느낍니다.
미래(THE FUTURE)
Computer: 저는 당신이 C++표준화 작업에 많이 참여한 것으로 알고있습니 다. 하지만, 현재 당신이 참여한 다른 프로젝트에는 어떤 것이 있으며, C++을 발전시키기 위해 어떤 작업을 계속할 것입니까?

Stroustrup: 나는 매우 큰 프로젝트를 성공적으로 완성하고 나서 고통받고 있습니다. ISO C++ 표준이 완성되었습니다. The C++ Programming Language의 제 3판에는 표준 C++이 무엇을 제공하는지 어떻게 가장 잘 사용 하는지 진지한 프로그래머들에게 알리고 있습니다. 그리고 Design and Evolution은 C++에 장착된(shaped) 디자인 결정들을 문서화하고 있습니다. 해 야할 것들이 아직 많습니다. 그러나 전시간 언어 디자이너를 필요로 하는 것 은 아무것도 없습니다. 이제 가능한 변화들에 집중하기 보다는, 코드를 작성함 으로써 C++의 힘과 유연성을 즐길 시간입니다.

그것과는 별도로, 저는 몇 가지 사실들을 배울 기회를 얻었습니다. 몇 가지 새로운 언어와 큰 사업에서 소프트웨어가 어떻게 사용되는지에 관한 것이 그것입 니다. 그리고 분산 컴퓨팅에서 몇 실험들을 계획중입니다.

방향

개론 (https://www.stroustrup.com/Programming/PPP-style.pdf)
클래스 (계산기 ~ 그래픽 프로그래밍)
STL

참고자료

https://www.stroustrup.com/programming_support.html

Is it better to use C void arguments "void foo(void)" or not "void foo()"?

There are two ways for specifying parameters in C. One is using an identifier list, and the other is using a parameter type list. The identifier list can be omitted, but the type list can not. So, to say that one function takes no arguments in a function definition you do this with an (omitted) identifier list

void f() {
    /* do something ... */
}

And this with a parameter type list:

void f(void) {
    /* do something ... */
}

If in a parameter type list the only one parameter type is void (it must have no name then), then that means the function takes no arguments. But those two ways of defining a function have a difference regarding what they declare.

Identifier lists
The first defines that the function takes a specific number of arguments, but neither the count is communicated nor the types of what is needed - as with all function declarations that use identifier lists. So the caller has to know the types and the count precisely before-hand. So if the caller calls the function giving it some argument, the behavior is undefined. The stack could become corrupted for example, because the called function expects a different layout when it gains control.

Using identifier lists in function parameters is deprecated. It was used in old days and is still present in lots of production code. They can cause severe danger because of those argument promotions (if the promoted argument type do not match the parameter type of the function definition, behavior is undefined either!) and are much less safe, of course. So always use the void thingy for functions without parameters, in both only-declarations and definitions of functions.

Parameter type list
The second one defines that the function takes zero arguments and also communicates that - like with all cases where the function is declared using a parameter type list, which is called a prototype. If the caller calls the function and gives it some argument, that is an error and the compiler spits out an appropriate error.

The second way of declaring a function has plenty of benefits. One of course is that amount and types of parameters are checked. Another difference is that because the compiler knows the parameter types, it can apply implicit conversions of the arguments to the type of the parameters. If no parameter type list is present, that can't be done, and arguments are converted to promoted types (that is called the default argument promotion). char will become int, for example, while float will become double.

Composite type for functions
By the way, if a file contains both an omitted identifier list and a parameter type list, the parameter type list "wins". The type of the function at the end contains a prototype:

void f();
void f(int a) {
    printf("%d", a);
}

// f has now a prototype.

That is because both declarations do not say anything contradictory. The second, however, had something to say in addition. Which is that one argument is accepted. The same can be done in reverse

void f(a) 
  int a;
{ 
    printf("%d", a);
}

void f(int);

The first defines a function using an identifier list, while the second then provides a prototype for it, using a declaration containing a parameter type list.
https://stackoverflow.com/questions/693788/is-it-better-to-use-c-void-arguments-void-foovoid-or-not-void-foo

ch04
ch05

상속 받은 클래스, 클래스 안에 정의된 클래스

#include <iostream>

class Foo {
 public:
  Foo() { std::cout << "+Foo" << std::endl; }
  ~Foo() { std::cout << "-Foo" << std::endl; }

  class Bar {
   public:
    Bar() { std::cout << "+Bar" << std::endl; }
    ~Bar() { std::cout << "-Bar" << std::endl; }
  };
};

int main() {
  Foo* f = new Foo;
  delete f;

  Foo::Bar* b = new Foo::Bar;
  delete b;

  return 0;
}

소멸자 호출 순서 확인할 것

ryanjeong / cpp Goto Github PK

cpp's Introduction

Hi there 👋

I love programming and problem-solving!

cpp's People

Contributors

Watchers

cpp's Issues

Recommend Projects

Recommend Topics

Recommend Org