김윤수의 이상계를 꿈꾸며

C++ 최근 소식

김윤수 — Mon, 8 Jul 2013 00:44:26 +0900

정말 오랜만의 포스팅입니다.

몇 가지 최근 C++ 소식 알려 드립니다.

1. C++14 Committee Draft가 벌써 나왔습니다. 다음은 PDF파일 다운받을 수 있는 링크입니다.

http://isocpp.org/files/papers/N3690.pdf

2. Herb Sutter씨가 최근 Microsoft channel 9에서 "The Future of C++"라고 강연한 내용에서도 C++14 feature가 간략하게 소개되고 있네요.

http://channel9.msdn.com/Events/Build/2013/2-306

3. Clang의 C++14 구현 상황입니다.

http://clang.llvm.org/cxx_status.html

4. g++의 C++14 구현 상황입니다.

http://gcc.gnu.org/projects/cxx1y.html

5. Visual Studio C++14 구현 계획입니다. MS는 C++11과 C++14을 한 묶음의 일로 보고 작업 중이라는군요.

http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-conformance-roadmap.aspx

6. 참고로 http://isocpp.org/ 는 얼마전에 만들어진 C++ 언어 포털이라고 할 수 있습니다.

C++11의 rvalue reference 흉내내기

김윤수 — Sun, 1 Jul 2012 22:40:36 +0900

C++11의 큰 특징 중의 하나로 rvalue reference라는 것이 도입되었습니다. reference라는 것이 기본적으로 lvalue로 작동할 수 있는 것인데 rvalue reference라는 개념이라는 게 있을 수가 있나 하는 생각이 들지만, 불필요한 임시객체 생성 및 삭제로 인한 성능 저하를 막기 위해 도입된 것이라 할 수 있습니다. 일명 move semantic과 perfect forwarding을 위한 것이라고 합니다.

성능이라는 단어가 나오면 보통 C++ 프로그래머들은 관심을 갖기 마련이고, 그런 좋은 것이 있다면 빨리 쓰고 싶기도 할 터인데요, C++11을 일부 지원하는 기능을 컴파일러가 시장에 나오긴 했더라도 자신이 속한 프로젝트에서는 정책상 C++11 기능을 사용하지 못하게 해 놓을 수도 있을 것입니다. 그렇다고 이 좋은 기능을 그냥 보고 넘어갈 수도 없는 노릇이겠지요.

그래서 한 번 생각해 봤습니다. rvalue reference를 흉내낼 수는 없을까하구요. 한 동안 고민하고 있었는데, 어느 순간 갑자기 아이디어가 떠오르더군요. 떠오른 생각을 빠르게 한 번 옮겨 봤습니다.

#include <iostream>

using namespace std;

namespace buffer {

// 테스트용 클래스

class Foo {

public:

Foo() {

cout << __PRETTY_FUNCTION__ << endl;

}

~Foo() {

cout << __PRETTY_FUNCTION__ << endl;

}

};

class BufferRvRef;

class Buffer {

public:

// 아래 template Move 함수의 일반적 정의를 위한 보조 타입

typedef BufferRvRef RvRef;

Buffer() : buf_(new Foo()), id_(id) {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

++id;

}

// move constructor

// rvalue reference를 받는 경우를 흉내내서 move semantic

// 구현

Buffer(const RvRef& rvref);

~Buffer() {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

delete buf_;

}

private:

// move semantic 구현. copy construction시 const 객체를

// 받으므로 const 멤버 함수로 정의함

Foo* release() const {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

Foo* ret = buf_;

buf_ = 0;

return ret;

}

// release() 함수에서 buf_ 조작을 위해서 mutable 붙임

mutable Foo* buf_;

// 화면 출력 메시지에서 각 객체 구분 용도. 실제 클래스라면 불필요

int id_;

// BufferRvRef가 release()를 호출할 수 있도록 하기 위해

// friend로 선언

friend class BufferRvRef;

static int id;

};

int Buffer::id = 0;

// Buffer 내부 데이터를 move 시키기 위한 임시 저장소 역할

class BufferRvRef {

public:

// const Buffer 객체를 임시로 저장함

explicit BufferRvRef(const Buffer& buf)

: buf_(buf.release()), id_(id) {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

++id;

}

BufferRvRef(const BufferRvRef& other)

: buf_(other.release()), id_(id) {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

++id;

}

// move semantic 구현

Foo* release() const {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

Foo* ret = buf_;

buf_ = 0;

return ret;

}

~BufferRvRef() {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

delete buf_;

}

private:

// release() 함수에서 buf_ 조작을 위해 mutable 붙임

mutable Foo* buf_;

// 화면 출력 메시지에서 각 객체 구분 용도. 실제 클래스라면 불필요

int id_;

static int id;

};

int BufferRvRef::id = 0;

inline Buffer::Buffer(const Buffer::RvRef& rvref)

: buf_(rvref.release()), id_(id) {

cout << __PRETTY_FUNCTION__ << " - " << id_ << endl;

++id;

}

// Move() 템플릿 함수가 하는 역할은 T를 T::RvRef로 형변환해주는 역할

// Buffer 라면 Buffer::RvRef(BufferRvRef형)로 형변환해주므로

// BufferRvRef(const Buffer&buf)가 호출되면서 Buffer.buf_가

// BufferRvRef.buf_로 옮겨감

template <typename T>

typename T::RvRef Move(const T& buf) {

cout << __PRETTY_FUNCTION__ << " starts" << endl;
return typename T::RvRef(buf);

}

// Buffer를 value로 반환하게 되는 함수는 이전과 다르게

// Move()를 호출할 경우, move semantic을 구현하는

// constructor가 호출됨

buffer::Buffer ReturnBuffer() {

cout << __PRETTY_FUNCTION__ << " starts" << endl;

return Move(buffer::Buffer());

}

int main() {

cout << __PRETTY_FUNCTION__ << " starts" << endl;

buffer::Buffer buf(ReturnBuffer());

cout << __PRETTY_FUNCTION__ << " ends" << endl;

}

위와 비슷한 형태로 작성하면 move semantic을 구현할 수 있을 것 같습니다. 중요한 것은 rvalue reference를 흉내낼수 있는 클래스(FooRvRef)를 각 클래스별(Foo)로 하나 정의하고, Foo --> FooRvRef 변환, FooRvRef --> Foo 변환이 가능하게 하고, 이 변환시 resource를 가져오는 방식으로 구현하면 될 것 같습니다. 물론 value를 반환하는 경우에 일관성있게 Move() 함수를 호출해 줘야만 원하는 변환이 일어날 수 있을 것입니다(ReturnBuffer() 참조). 마지막으로 Move()라는 함수 구현을 쉽게 할 수 있도록 move enable 시키고 싶은 클래스에는 일관성 있게 Foo::RvRef 라는 typedef 를 정의해 줘야합니다.

다음은 위 프로그램을 한 번 실행시켜본 결과입니다.

$ ./rvalemul

int main() starts

buffer::Buffer::RvRef ReturnBuffer() starts

buffer::Foo::Foo()

buffer::Buffer::Buffer() - 0 constructed

typename T::RvRef Move(const T&) [with T = buffer::Buffer, typename T::RvRef = buffer::BufferRvRef] starts

buffer::Foo* buffer::Buffer::release() const - 0

buffer::BufferRvRef::BufferRvRef(const buffer::Buffer&) - 0 move constructed

buffer::Buffer::~Buffer() - 0 destroyed

buffer::Foo* buffer::BufferRvRef::release() const - 0

buffer::Buffer::Buffer(const RvRef&) - 1 move constructed

buffer::BufferRvRef::~BufferRvRef() - 0 destroyed

int main() ends

buffer::Buffer::~Buffer() - 1 destroyed

buffer::Foo::~Foo()

위 출력 메시지를 자세히 쫒아가시면 BufferRvRef가 중간에 개입되어 main() 함수에 선언된 buf 객체가 move construction 되고 있는 것을 확인할 수 있습니다.

추가적으로 알아둘만한 점은 move semantic은 성능을 위해서도 좋지만, 예외 처리를 위해서도 좋다는 점입니다. 왜냐하면 copy construction이 deep copy가 일어난다면 통상 일시적으로 두 개의 copy가 생성되는 셈인데, 그 와중에 exception이 발생할 가능성이 아무래도 커지고, 메모리가 부족할 가능성이 있을 것이니 아무래도 value 반환을 위해서는 move semantic이 훨씬 안전한 방식이라고 생각이 됩니다.

마지막으로 한 가지 첨언하면 위 Buffer 클래스는 copy constructor를 정의하지 않았으므로 move-only 클래스라고 할 수 있습니다.

혹시 C++11 컴파일러를 아직 사용하지 못하시더라도 위와 같은 방식으로 rvalue reference의 유용성을 한 번 느껴보시는 것도 좋을 것 같습니다.

C++11 atomic 객체 맛보기

김윤수 — Sun, 1 Jul 2012 17:29:01 +0900

C++11 atomic을 이용해서 프로그래밍할 때 어떻게 해야 하는지 맛 보기 위해 간단한 예제를 작성해 봤습니다. multiple thread에서 공유 integer 변수를 loop 한번 당 매번 1씩 경쟁적으로 증가시키는 간단한 프로그램입니다.

일반 integer 변수와 atomic integer 변수로 비교해 보았고, 일반 integer 변수의 경우 역시 예상대로 정확한 결과가 나오지 않았고, atomic integer 변수는 정확한 결과가 나왔습니다.

또, 일반 integer 변수는 상당히 빠르게 수행되지만 atomic integer 변수는 상당히 느리다는 것을 확인할 수 있었습니다.

테스트 프로그램은 다음과 같습니다. C++11 프로그램인 만큼 몇 가지 C++11 스타일을 적용했습니다

#include <iostream>

#include <atomic>

#include <vector>

// C++11 <thread>가 있으나 버그가 있어 사용하지 못하고

// boost::thread 사용

#include <boost/thread.hpp>

using namespace std;

using boost::thread;

enum {

NTHREADS = 8, // Core i7 Desktop이라 8로 설정

NRUN = 10000000,

NLOOP = NRUN * 10

};

// atomic integer type. atomic<int>라고도 할 수 있음.

// atomic하게 증가됨

atomic_int an{0};

int n{0};

void increment_atomic(int id, int nloop) {

cout << __PRETTY_FUNCTION__

<< "(" << id << ") starts" << endl;

while (nloop-- > 0) {

// relaxed memory ordering.

// 단순 카운트인 경우에 충분

an.fetch_add(1, memory_order_relaxed);

// an.fetch_add(1, memory_order_seq_cst);

// or ++an; 일반 integer처럼 prefix ++ 지원

// 이 때 memory ordering은 memory_order_seq_cst

if (nloop % NRUN == 0)

cout << __PRETTY_FUNCTION__

<< "(" << id << ") running..." << endl;

}

cout << __PRETTY_FUNCTION__

<< "(" << id << ") exits" << endl;

}

void increment_int(int id, int nloop) {

cout << __PRETTY_FUNCTION__

<< "(" << id << ") starts" << endl;

while (nloop-- > 0) {

++n;

if (nloop % NRUN == 0)

cout << __PRETTY_FUNCTION__

<< "(" << id << ") running..." << endl;

}

cout << __PRETTY_FUNCTION__

<< "(" << id << ") exits" << endl;

}

void test_func(void (*incr)(int, int), void (*print)()) {

vector<thread> thrs{};

cout << "Creating threads" << endl;

for (int i = 0; i < NTHREADS; ++i) {

// 개선된 push_back()이라 할 수 있는

// emplace_back() 활용

thrs.emplace_back(thread(incr, i, NLOOP));

}

cout << "Waiting for all threads to terminate" << endl;

// lambda 함수 사용

for_each(thrs.begin(), thrs.end(), [](thread& thr) {

thr.join();

});

print();

}

void usage() {

cout << "Usage:" << endl;

cout << "test-atomic atomic|int" << endl;

}

int main(int argc, char* argv[]) {

if (argc == 2) {

string type{argv[1]};

if (type == "atomic") {

// lambda 함수 사용

test_func(increment_atomic, []() {

cout << "atomic int = " << an << endl;

});

}

else if (type == "int") {

// lambda 함수 사용

test_func(increment_int, []() {

cout << "int = " << n << endl;

});

}

else {

usage();

}

else {

usage();

}

컴파일 및 실행 환경은 다음과 같습니다.

$ uname -a

Linux ubuntu 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ g++ --version

g++-4.6.real (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

boost thread와 컴파일할 때는 다음과 같이 library를 명시해 줘야 합니다.

$ g++ --std=c++0x -o test-atomic test_atomic.cpp -lboost_thread-mt

실행한 결과는 다음과 같습니다.

$ ./test-atomic

Usage:

test-atomic atomic|int

$ time ./test-atomic atomic

Creating threads

void increment_atomic(int, int)(void increment_atomic(int, int)(void increment_atomic(int, int)(void increment_atomic(int, int)void increment_atomic(int, int)((24) starts) starts1

) starts

3) starts

0) starts

void increment_atomic(int, int)(6) starts

Waiting for all threads to terminate

void increment_atomic(int, int)(7) starts

void increment_atomic(int, int)(5) starts

void increment_atomic(int, int)(6) running...

void increment_atomic(int, int)(3) running...

void increment_atomic(int, int)(5) running...

void increment_atomic(int, int)(0) running...

void increment_atomic(int, int)(1) running...

void increment_atomic(int, int)(7) running...

void increment_atomic(int, int)(2) running...

void increment_atomic(int, int)(4) running...

void increment_atomic(int, int)(5) running...

...

void increment_atomic(int, int)(0) exits

void increment_atomic(int, int)(7) running...

void increment_atomic(int, int)(7) exits

void increment_atomic(int, int)(4) running...

void increment_atomic(int, int)(4) exits

void increment_atomic(int, int)(6) running...

void increment_atomic(int, int)(6) exits

void increment_atomic(int, int)(1) running...

void increment_atomic(int, int)(1) exits

void increment_atomic(int, int)(2) running...

void increment_atomic(int, int)(2) exits

atomic int = 800000000

real 0m14.613s

user 1m40.774s

sys 0m0.032s

$ time ./test-atomic int

Creating threads

void increment_int(int, int)(1) starts

void increment_int(int, int)(2) starts

void increment_int(int, int)(0) starts

void increment_int(int, int)(3) starts

void increment_int(int, int)(4) starts

void increment_int(int, int)(5) starts

Waiting for all threads to terminate

void increment_int(int, int)(6) starts

void increment_int(int, int)(7) starts

void increment_int(int, int)(4) running...

void increment_int(int, int)(1) running...

void increment_int(int, int)(7) running...

void increment_int(int, int)(2) running...

void increment_int(int, int)(4) running...

void increment_int(int, int)(5) running...

void increment_int(int, int)(6) running...

...

void increment_int(int, int)(3) running...

void increment_int(int, int)(2) running...

void increment_int(int, int)(2) exits

void increment_int(int, int)(0) running...

void increment_int(int, int)(0) exits

void increment_int(int, int)(6) running...

void increment_int(int, int)(3) running...

void increment_int(int, int)(6) running...

void increment_int(int, int)(3) running...

void increment_int(int, int)(3) exits

void increment_int(int, int)(6) running...

void increment_int(int, int)(6) exits

int = 117287057

real 0m2.518s

user 0m16.345s

sys 0m0.004s

atomic type 을 이용하여 lock-less data structure를 구현할 수 있다고 하더군요.

C++11 기능 소개: 중첩 '>' 문제 해결

김윤수 — Tue, 10 Apr 2012 12:30:00 +0900

여러 말로 설명하기 보다 관련 예제부터 한 번 보겠습니다.

map<string,vector<int>> heroChronicles;

C++98에서는 위 코드가 컴파일되지 않습니다. 왜냐하면 “>>”이 연속된 ‘>’으로 인식되는 것이 아니라 구문 분석 시작 전 어휘 분석 단계(lexical analysis)에서 최대 흡수(Maximal munch) 규칙에 따라 “>>” 토큰으로 인식되고 이는 다시 문법 단계에서 “>>” 연산자로 인식되고, ">>" 연산자 좌우로 int, heroChronicles 같은 토큰들이 있는 것으로 인식되기 때문입니다. 템플릿 초심자들이 많이 저지르는 실수이죠. 그래서 C++98에서는 다음과 같이 작성해야 했습니다.

map<string,vector<int> > heroChronicles;

이 뿐 아니라 새로운 형태의 형변환 연산자도 비슷한 문제가 있습니다.

static_cast<List>(ld);
// static_cast<List<(B>>(ld)); 로 해석

>>= 및 >= 도 비슷한 문제가 발생할 수 있습니다.

void func(List= default_val1);
// 원래 의도는 List lb = default_val1이나
// List<(B >= default_val1)); 으로 해석

void func(List<List>= default_val2);
// 원래 의도는 List<List> llb = default_val2이나
// List<List<(B>>= default_val2)); 으로 해석

템플릿이 많이 사용되면 많이 사용될 수록 이런 코드는 더 큰 문제가 될 것입니다.

애초에 C++98에서 이런 문제가 발생했던 것은 컴파일러가 이론적으로 어휘분석, 문법분석, 형식체크와 같이 몇 단계를 거쳐 처리하므로 이 문제를 해결하기 위해서는 어휘 분석 단계가 문법 분석 단계와 협력해야 하는 문제가 발생하게 되기 때문이었습니다. 결국 컴파일러 구현자들을 위한 결정이었던 것이죠.

그런데 시중에 출시된 C++ 컴파일러들이 이 문제를 인식하고 친철한 에러 메시지를 출력하고 있다는 것이 표준화를 진행하는 동안 밝혀졌습니다.

예를 들어, g++에서는 다음과 같은 에러 메시지를 출력하고 있었습니다.

error: ‘>>’ should be ‘> >’ within a nested template argument list

이 정도로 이미 컴파일러들이 이 문제를 나름대로 인식하고 해결하고 있었기 때문에 C++11에서는 어휘 분석 단계와 문법 분석 단계가 협력하여 문제를 해결하도록 표준에 명시하기에 이르렀습니다. 기본적으로 다음과 같은 규칙을 따르도록 되어 있습니다.

왼쪽 ‘<’ 이 ‘>’과 서로 매치가 되어 있지 않은 동안에는 >> 토큰은 오른쪽 shift 연산자가 아닌 두 개의 연속된 ‘>’로 인식되어야 한다.

위와 같은 규칙은 어휘 분석 단계와 문법 분석 단계가 긴밀하게 협력할 필요 없이 문법 분석 단계에서 간단한 검사만 하면 구현할 수 있을 정도이므로 컴파일러 구현에도 큰 문제가 되지는 않을 것입니다.

항상 그렇듯 이 규칙에도 예외가 있습니다.

다음 예제를 보시죠.

Y<X<6>>1>> x4;

코드를 보고 예측해 보건데 프로그래머는 6>>1의 결과값을 X 템플릿의 인자로 주고 싶었을 것입니다. 즉, 다음과 같은 의미였겠죠.

Y<X<(6>>1)>> x4;

이런 코드가 문제 없이 컴파일되도록 하기 위해서는 괄호 안에서는 위와 같은 규칙이 적용되지 않도록 해야하므로 다음과 같이 예외조항을 두어야 할 것입니다.

왼쪽 ‘<’ 이 ‘>’과 서로 매치가 되어 있지 않은 동안에는 >> 토큰은 오른쪽 shift 연산자가 아닌 두 개의 연속된 ‘>’로 인식되어야 한다. 단, 괄호쌍이나 대괄호쌍에 있는 >>는 예외이다.

이 규칙이 C++11에서 정하고 있는 것과 정확히 동일합니다. 이제 C++ 초심자들에게 템플릿을 가르칠 때, 중첩 템플릿 인자를 명시할 때는 반드시 한 칸을 띄어야 한다고 설명하면서 "왜 띄어야 하느냐?"라는 질문을 받을까봐 노심초사하는 일은 없어도 될 것 같습니다. ^^;

참고문헌

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
http://occamsrazr.net/tt/172

C++11 기능 소개: 상속생성자(Inheriting Constructor)

김윤수 — Wed, 28 Mar 2012 22:51:13 +0900

상속생성자란 기본클래스에 정의된 생성자를 상속받는 클래스에서 상속받을 수 있도록 하는 기능이다.

상속생성자는 컴파일러가 기본생성자와 복사생성자를 생성하는 규칙 때문에 발생하는 문제점을 해결하기 위한 기능이므로 우선 이 규칙을 이해할 필요가 있다. C++ 컴파일러는 프로그래머가 생성자를 정의하지 않으면 기본 생성자 및 복사생성자를 알아서 생성한다. 예를 들어,

class B {
int v_;

public:
int get();
void set(int v);
};

B b;

와 같은 코드가 아무런 문제 없이 컴파일되는 이유는 컴파일러가 기본생성자를 생성해 주기 때문이다. 그런데 B를 쓰다 보면 기본생성자에 의해 초기화되지 않은 멤버 변수 값 때문에 문제가 생기는 경우가 있기 마련이다. 예를 들어,

void f();

B b;
f(b.get());

와 같은 코드를 실행할 경우 b.v_에 담긴 쓰레기 값 때문에 문제가 발생할 수 있을 것이다. 이런 문제를 발견했을 때 상식있는 프로그래머라면 다음과 같이 생성자를 추가할 것이다.

class B {
int v_;

public:
B(int v) : v_(v) {}
int get();
void set(int v);
};

B b;

그러면 당장 다음과 같은 에러가 발생하게 된다.

error C2512: 'B' : 사용할 수 있는 적절한 기본 생성자가 없습니다.

그렇다. 프로그래머가 기본생성자가 아닌 생성자를 하나라도 추가하면 컴파일러가 기본생성자를 생성하지 않는 것이다. 이제 프로그래머가 직접 기본생성자를 작성해야 한다.

class B {
int v_;

public:
B() : B(0) {} // C++11의 위임생성자 기능 활용
B(int v) : v_(v) {}
int get();
void set(int v);
};

그런데 만약 B로부터 상속 받은 D라는 클래스가 있었다고 생각해 보자.

class D : public B {
public:
void compute();
};

B::B(int)가 추가된 이유를 이해하는 프로그래머라면 D를 사용할 때 다음과 같이 생성시 초기값을 제대로 지정하려고 할 것이다.

D d(10);

그렇지만 위 코드는 컴파일 에러를 발생시킨다. 왜냐하면 D::D(int)는 애초에 정의되어 있지 않기 때문이다. 결국 D를 작성한 프로그래머는 다음과 같이 D::D(int)를 추가해야 한다.

class D : public B {
public:
D(int v) : B(v) {}
void compute();
};

D d(10);

그렇다면 다음 코드는 어떨까?

D d2;
d2.set(10);

D::D(int)가 없었기 때문에 충분히 여러 차례 사용될만한 코드 패턴일 것이다. 그렇지만 D를 작성한 프로그래머가 D::D(int)를 추가한 순간 위와 같은 코드 패턴들은 모두 컴파일 에러를 일으키게 된다. D 클래스를 작성한 프로그래머와 위 코드를 작성한 프로그래머가 같다면 별 문제 없겠지만 다르다면 사무실 어느 구석에선가 “악~”하고 소리가 날 일이다. 결국 D는 다음과 같이 작성되어야 한다.

class D : public B {
public:
D() : B() {}
D(int v) : B(v) {}
void compute();
};

D d(10);
D d2;
d2.set(10);

창조적 귀차니즘이 있는 프로그래머라면 이쯤에서 의문이 하나 생긴다. “왜 이렇게 불편하게 해 놓았지? 애초에 D가 B의 생성자들을 다 물려받으면 되잖아. 상속에는 생성자 상속까지 포함되어야 하는 거 아닌가?”

상속생성자는 이런 의문에서 출발한 기능이다. 위 질문에 대한 해답으로 상속시에 생성자를 모두 물려받는 것으로 정하면 되지 않을까 하는 생각이 제일 먼저 들 것이다. 그렇지만 이렇게 상속의 의미를 수정할 경우 기존에 이미 존재하던 수많은 코드들이 컴파일되지 않거나 컴파일은 되는데 예상치 못한 실행시 에러가 발생할 수 있다. 언어가 발전함에 있어 이런 급작스런 변화는 거의 불가능하다고 볼 수 있다. 기존 코드를 모두 깨뜨려버린다면 누구도 새로운 기능들을 채택하려 하지 않을 것이기 때문이다.

그렇다면 결국 생성자를 따로 상속받을 수 있는 방법을 고안해 내야 할 것이다. C++11 표준화 논의 중에 여러가지 방법들이 제안되었지만 최종적으로는 다음과 같이 using 선언을 이용하여 생성자를 물려받을 수 있다.

class B {
int v_;

public:
B() : B(0) {} // C++11의 위임생성자 기능 활용
B(int v) : v_(v) {}
int get();
void set(int v);
};

class D : public B {
public:
using B::B;
void compute();
};

위와 같이 정의할 경우, D::D(int)가 암묵적으로 정의되며, 그 의미는 다음과 동일하다고 생각하면 된다.

class D : public B {
public:
D(int v) : B(v) {}
...
};

따라서 다음과 같이 D를 사용할 수 있게 된다.

D d1; // 암묵적으로 정의됨
D d2(10); // 상속을 통해 암묵적으로 정의됨
D d3(d2); // 암묵적으로 정의됨

D::D(int)가 “암묵적으로” 정의된다는 것은 기본생성자인 D::D()과 복사생성자인 D::D(const D&)가 암묵적으로 정의된다는 의미이다. 왜냐하면 D::D(int)를 프로그래머가 명시적으로 정의한 것은 아니기 때문에 기본생성자 및 복사생성자 생성규칙에 따라 암묵적으로 정의된 것이다.

이렇게 상속생성자가 동일한 signature를 갖는 생성자를 반복해서 작성해야 하는 수고로움은 덜어 줬지만 잘못하면 다른 문제를 일으킬 수도 있다. 다음 예제를 보자.

class B {
int v_;

public:
B() : B(0) {} // C++11의 위임생성자 기능 활용
B(int v) : v_(v) {}
int get();
void set(int v);
};

class D : public B {
float v2_; // 초기화 필요
public:
using B::B;
void compute();
};

D d3(25);

언뜻 보기에는 문제가 없어 보일 수 있으나 컴파일러가 생성한 D::D(int)는 B::B(int)를 뜻하므로 d3.v2_는 초기화되지 않은 채로 사용될 것이다. 이쯤에서 우리는 다음과 같은 프로그래밍 경구를 기억할 수 밖에 없다.

“초기화되지 않은 변수를 사용하지 말라”

구식 방법으로 D::D(int)를 직접 작성하여 초기화할 수도 있지만, C++11에 새롭게 추가된 멤버초기화 기능을 이용하여 더 멋지게 해결할 수도 있다.

class D : public B {
float v2_{0.0}; // 멤버초기화 기능 이용
public:
using B::B;
void compute();
};

D d3(25); // v2_는 0.0으로 초기화 됨

참고문헌
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1890.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1898.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1583.pdf
http://www2.research.att.com/~bs/C++0xFAQ.html#inheriting
http://occamsrazr.net/tt/205

C++ 이야기: 예외 처리와 관련된 고전 글 번역

김윤수 — Wed, 30 Jun 2010 23:14:24 +0900

다음 글은 예외 처리 기능이 C++에 도입된지 얼마되지 않아 C++ 커뮤니티에서 예외를 사용할 때 유의해야할 점에 대해 잘 깨닫지 못하고 있을 때, 예외에 대한 새로운 통찰력을 제공해 주고, 예외 처리를 위한 다양한 기법들의 시발점이 된 고전 Tom Cargill 의 Exception handling: a false sense of security 를 번역한 것입니다. 원문은 이 링크에서 보실 수 있고, 원문에서 약간 코드 상 잘못된 부분들(template 키워드 뒤에 <class T>가 따라오지 않는다던지 literal string 이 ""..."" 과 같이 되어 있다던지)을 수정하고 영문과 한글을 대조하면서 보실 수 있도록 했습니다. C++ 로 프로그래밍 하시는 분이라면 필독해야 할 글이라고 할 수 있습니다.

그렇지만 이 글만 읽지 마시고, 2009/09/25 - [S/W개발/C++ 이야기] - C++ 이야기 서른한번째: 왜 예외를 쓰는 게 좋을까요? 와 비교해서 읽어 보시면 예외의 장점과 단점을 어느 정도 파악하실 수 있을 거라 생각합니다. 이 글만 읽으시면 마치 예외가 문제를 더 많이 일으키는 것 같지만, 이 글이 문제점을 제기한 이후에 많은 분들이 예외 안전성을 확보할 수 있는 프로그래밍 기법들을 알아내어 그 방법대로 프로그래밍하면 별 문제 될것이 없습니다. 다만, 이런 프로그래밍 기법을 공부하는데 어느 정도 시간이 필요한 것이 더 문제겠지요. 또 이 글만 읽고 예외는 절대 쓰면 안된다는 결론에 빠지지 않기를 바랍니다.

EXCEPTION HANDLING:

A FALSE SENSE OF SECURITY

예외 처리: 잘못된 안정감

Tom Cargill 저

김윤수 역

This article first appeared in C++ Report, Volume 6, Number 9, November-December 1994.

이 글은 C++ Report, 6권, 1994년 11월, 12월, 9번째판에 처음 게제됐습니다.

I suspect that most members of the C++ community vastly underestimate the skills needed to program with exceptions and therefore underestimate the true costs of their use. The popular belief is that exceptions provide a straightforward mechanism for adding reliable error handling to our programs. On the contrary, I see exceptions as a mechanism that may cause more ills than it cures. Without extraordinary care, the addition of exceptions to most software is likely to diminish overall reliability and impede the software development process.

저는 C++ 사용자 대부분이 예외를 사용하는 프로그램을 작성하는 데 필요한 노련미를 너무 무시하고 있지 않는지, 그럼으로 인해 예외를 사용할 때, 진정 치뤄야할 대가를 무시하고 있지는 않은지 염려스럽습니다. 오히려 대부분은 예외를 사용하면 바로 신뢰성 있는 에러 처리가 가능하다고 믿는 것 같습니다. 저는, 이와는 반대로, 예외를 사용하면 해결되는 문제보다는 새롭게 발생하는 문제가 많다고 생각합니다. 정말 정말 조심하지 않고 예외를 사용하면, 소프트웨어의 전반적인 신뢰성이 훼손되고 소프트웨어 개발 과정이 지연될 가능성이 높아집니다.

This "extraordinary care" demanded by exceptions originates in the subtle interactions among language features that can arise in exception handling. Counter-intuitively, the hard part of coding exceptions is not the explicit throws and catches. The really hard part of using exceptions is to write all the intervening code in such a way that an arbitrary exception can propagate from its throw site to its handler, arriving safely and without damaging other parts of the program along the way.

이렇게 정말 정말 조심해야 하는 이유는 예외 처리 과정에서 발생하는 언어의 다양한 특징들간 미묘한 상호 작용때문입니다. 언뜻 보기와는 달리 예외를 사용하여 코딩할 때, 가장 어려운 부분은 눈에 보이는 throw와 catch가 아닙니다. 정말 어려운 부분은 어떤 예외라도 발생 지점으로부터 처리 지점까지 프로그램 상태를 해치지 않고 안전하게 도달할 수 있도록 코딩하는 것입니다.

In the October 1993 issue of the C++ Report, David Reed argues in favor of exceptions that: "Robust reusable types require a robust error handling mechanism that can be used in a consistent way across different reusable class libraries." While entirely in favor of robust error handling, I have serious doubts that exceptions will engender software that is any more robust than that achieved by other means. I am concerned that exceptions will lull programmers into a false sense of security, believing that their code is handling errors when in reality the exceptions are actually compounding errors and hindering the software.

C++ Report 1993년 10월판에서 David Reed는 "강인한 재사용 형식은 여러 클래스 라이브러리에 걸쳐 일관되게 사용할 수 있는 강인한 오류 처리 방법을 필요로 한다"며 예외를 옹호하는 주장을 했습니다. 강인한 오류 처리가 필요하다는 건 십분 동의하지만, 다른 에러 처리 방법에 비해 예외가 더 강인한 소프트웨어를 만들게 한다는 건 정말 동의하기 어렵습니다. 오히려 프로그래머들이 예외를 사용하면서 내 프로그램은 오류 처리를 하고 있으니 안전할꺼야라며 안심하게 될까봐 걱정스럽습니다. 실제로는 예외가 오류를 더 복잡하게 하고, 소프트웨어 동작을 방해하게 됩니다.

To illustrate my concerns concretely I will examine the code that appeared in Reed's article. The code (page 42, October 1993) is a Stack class template. To reduce the size of Reed's code for presentation purposes, I have made two changes. First, instead of throwing Exception objects, my version simply throws literal character strings. The detailed encoding of the exception object is irrelevant for my purposes, because we will see no extraction of information from an exception object. Second, to avoid having to break long lines of source text, I have abbreviated the identifier current_index to top. Reed's code follows. Spend a few minutes studying it before reading on. Pay particular attention to its exception handling. [Hint: Look for any of the classic problems associated with delete, such as too few delete operations, too many delete operations or access to memory after its delete.]

제가 걱정하는 바를 구체적으로 설명하기 위해 Reed의 글에 있는 코드를 한 번 살펴 보겠습니다. 1993년 10월판 42페이지에 제시된 코드는 Stack 클래스 템플릿입니다. 설명을 위해 Reed의 코드를 줄일 필요가 있어서 두 가지를 수정했습니다. 첫 번째로 Exception 객체를 던지지 않고, 그냥 문자열을 던집니다. 어차피 예외 객체러부터 어떤 정보도 꺼내지 않을 것이므로 예외 객체를 어떻게 부호화하는지는 제 논의와 별 상관이 없습니다. 두 번째로 긴 소스 줄을 끊어야 하는 불편을 피하기 위해 current_index 식별자를 top이라고 줄였습니다. 다음은 Reed의 코드입니다. 계속 읽기 전에 한 번 몇 분간 깊이 분석해 보시기 바랍니다. 특히 예외 처리에 주목해 보시기 바랍니다. [힌트: delete 연산을 필요한 만큼 호출하지 않는다던지, 필요보다 더 많이 호출한다던지, delete 한 후에 메모리를 사용한다던지하는 delete와 관련된 고전적인 문제를 찾아 보시기 바랍니다.]

template <class T>

class Stack

{

unsigned nelems;

int top;

T* v;

public:

unsigned count();

void push(T);

T pop();

Stack();

~Stack();

Stack(const Stack&);

Stack& operator=(const Stack&);

};

template <class T>

Stack::Stack()

{

top = -1;

v = new T[nelems=10];

if( v == 0 )

throw "out of memory";

}

template <class T>

Stack::Stack(const Stack& s)

{

v = new T[nelems = s.nelems];

if( v == 0 )

throw "out of memory";

if( s.top > -1 ){

for(top = 0; top <= s.top; top++)

v[top] = s.v[top];

top--;

}

template <class T>

Stack::~Stack()

{

delete [] v;

}

template <class T>

void Stack::push(T element)

{

top++;

if( top == nelems-1 ){

T* new_buffer = new T[nelems+=10];

if( new_buffer == 0 )

throw "out of memory";

for(int i = 0; i < top; i++)

new_buffer[i] = v[i];

delete [] v;

v = new_buffer;

}

v[top] = element;

}

template <class T>

T Stack::pop()

{

if( top < 0 )

throw "pop on empty stack";

return v[top--];

}

template <class T>

unsigned Stack::count()

{

return top+1;

}

template <class T>

Stack&

Stack::operator=(const Stack& s)

{

delete [] v;

v = new T[nelems=s.nelems];

if( v == 0 )

throw "out of memory";

if( s.top > -1 ){

for(top = 0; top <= s.top; top++)

v[top] = s.v[top];

top--;

}

return *this;

}

My examination of the code is in three phases. First, I study the code's behavior along its "normal," exception-free execution paths, those in which no exceptions are thrown. Second, I study the consequences of exceptions thrown explicitly by the member functions of Stack. Third, I study the consequences of exceptions thrown by the T objects that are manipulated by Stack. Of these three phases, it is unquestionably the third that involves the most demanding analysis.

저는 세 단계로 이 코드를 분석해 보려고 합니다. 우선, 정상적인, 즉, 예외가 없는 실행 경로를 따로 코드가 잘 동작하는지 분석할 것입니다. 그 다음에는 Stack의 멤버 함수가 예외를 던질 때 어떻게 되는지 분석할 것입니다. 마지막으로 Stack이 처리하는 T 객체가 예외를 던질 때 어떻게 되는지 분석할 것입니다. 당연히 이 세 단계 중 마지막 단계를 가장 철저히 분석해야겠지요.

Normal Execution Paths / 정상적 실행 경로

Consider the following code, which uses assignment to make a copy of an empty stack:

다음 코드는 비어 있는 스택 복사본을 만들기 위해 할당을 사용하고 있습니다:

Stack y;

Stack x = y;

assert( y.count() == 0 );

printf( "%u\n", x.count() );

17736

The object x should be made empty, since it is copied from an empty master. However, x is not empty according to x.count(); the value 17736 appears because x.topis not set by the copy constructor when copying an empty object. The test that suppresses the copy loop for an empty object also suppresses the setting of top. The value that top assumes is determined by the contents of its memory as left by the last occupant.

x는 비어 있는 원본에서 복사됐으니 당연히 비어 있어야 함에도 불구하고 x.count() 결과로 보면 비어 있질 않습니다; 빈 객체를 복사할 때 복사 생성자가 x.top을 설정하지 않기 때문에 17736이라는 값이 출력된 것입니다. 빈 객체에 대해서 복사 루프를 돌지 않게 하는 조건문 때문에 top 변수도 설정되지 않게 됩니다. top 변수의 값은 마지막으로 해당 메모리를 사용했던 객체가 남겨 놓은 값이겠지요.

Now consider a similar situation with respect to assignment:

할당과 관련된 비슷한 경우을 하나 더 생각해 보겠습니다:

Stack a, b;

a.push(0);

a = b;

printf( ""%u\n"", a.count() );

Again, the object a should be empty. Again, it isn't. The boundary condition fault seen in the copy constructor also appears in operator=, so the value of a.top is not set to the value of b.top. There is a second bug in operator=. It does nothing to protect itself against self-assignment, that is, where the left-hand and right-hand sides of the assignment are the same object. Such an assignment would cause operator= to attempt to access deleted memory, with undefined results.

여기에서도 객체 a는 비어 있어야 하지만 그렇지 않습니다. 경계 조건을 잘못 처리했던 복사 생성자의 결함이 operator=에도 있기 때문에 a.top 변수값이 b.top 변수값으로 설정되지 않습니다. operator=에는 버그가 또 하나 있습니다. 바로 자기 할당-좌변 객체와 우변 객체가 동일한 경우를 말함-을 별도로 처리하지 않고 있습니다. 자기 할당시에는 operator=가 delete된 메모리를 접근하게 되고, 그렇게 되면 예상치 못한 결과가 초래될 것입니다.

Exceptions Thrown by Stack / Stack 이 던지는 예외

There are five explicit throw sites in Stack: four report memory exhaustion from operator new, and one reports stack underflow on a pop operation. (Stack assumes that on memory exhaustion operator new returns a null pointer. However, some implementations of operator new throw an exception instead. I will probably address exceptions thrown by operator new in a later column.)

Stack은 다섯 군데에서 예외를 발생시키고 있습니다. 그 중 넷은 new 연산자가 메모리 고갈을 알려준 것을 보고하는 것이고, 나머지 하나는 pop 연산을 수행할 때 언더플로가 발생했다는 것을 보고하는 것입니다.(Stack 은 new 연산자가 메모리 고갈시 널 포인터를 리턴하는 것으로 가정하고 있습니다. 그렇지만 일부 컴파일러에서는 new 연산자가 예외를 던지는 방식으로 작동합니다. 나중에 쓰게 될 칼럼에서 new 연산자가 예외를 던지는 문제를 다뤄 보겠습니다.)

The throw expressions in the default constructor and copy constructor of Stack are benign, by and large. When either of these constructors throws an exception, no Stack object remains and there is little left to say. (The little that does remain is sufficiently subtle that I will defer it to a later column as well.)

Stack의 기본 생성자와 복사 생성자가 던지는 예외는 대체로 별 문제가 없습니다. 이 두 생성자에서 예외가 발생하면 어차피 Stack 객체가 남아 있질 않게 되니 할 말이 거의 없습니다.(아주 조금 할 얘기가 있습니다만 이것도 다음 칼럼에서 얘기하도록 하겠습니다.)

The throw from push is more interesting. Clearly, a Stack object that throws from a push operation has rejected the pushed value. However, when rejecting the operation, in what state should push leave its object? On push failure, this stack class takes its object into an inconsistent state, because the increment of top precedes a check to see that any necessary growth can be accomplished. The stack object is in an inconsistent state because the value of top indicates the presence of an element for which there is no corresponding entry in the allocated array.

push 연산이 던지는 예외는 좀 더 흥미롭습니다. push 연산 실행 도중 예외가 발생하면 Stack 객체는 push된 값을 저장하지 않습니다. 그럴 경우 push 완료 후Stack 객체가 어떤 상태가 될까요? push가 실패하면 Stack 객체 상태가 불일치하게 됩니다. 왜냐하면 메모리 공간을 확실히 확보했는지 확인하기 전에 미리 top을 증가시켜 버리기 때문입니다. 예외가 발생하면 top 변수값이 실제로는 있지도 않은 객체를 가리키게 되므로 서로 불일치하게 됩니다.

Of course, the stack class might be documented to indicate that a throw from its push leaves the object in a state in which further member functions (count, push and pop) can no longer be used. However, it is simpler to correct the code. The push member function could be modified so that if an exception is thrown, the object is left in the state that it occupied before the push was attempted. Exceptions do not provide a rationale for an object to enter an inconsistent state, thus requiring clients to know which member functions may be called.

물론 Stack 클래스 문서에 push 도중 예외가 발생하면 더 이상 다른 멤버 함수들(count, push 및 pop 등)을 사용할 수 없다고 기술할 수도 있겠지만, 그러느니 코드를 고치는 게 훨씬 간단할 것입니다. push 안에서 예외가 발생하더라도 객체 상태를 push 호출 전 상태에 머무르도록 push 멤버 함수를 수정할 수 있을 것입니다. 예외가 발생했다고 하여 불일치 상태가 되어서는 안될 것입니다. 그렇게 하면, Stack 사용자가 예외 발생 후에 일일이 어떤 멤버 함수를 호출할 수 있는지를알아야 하니까요.

A similar problem arises in operator=, which disposes of the original array before successfully allocating a new one. If x and y are Stack objects and x=y throws the out-of-memory exception from x.operator=, the state of x is inconsistent. The value returned by x.count() does not reflect the number of elements that can be popped off the stack because the array of stacked elements no longer exists.

operator=에도 비슷한 문제가 있습니다. 즉, 새로운 배열을 성공적으로 할당하기 전에 원래 배열을 반납해 버리고 있습니다. x와 y가 Stack 객체이고, x=y 수행 도중 메모리가 고갈되었다는 예외가 발생했다면 x의 상태는 불일치하게 됩니다. 스택에 저장된 객체 배열이 더 이상 존재하지 않으므로 x.count() 가 돌려주는 값은 실제 스택에서 꺼낼 수 있는 객체 개수를 정확히 반영하지 못하게 됩니다.

Exceptions Thrown by T / T가 던지는 예외

The member functions of Stack create and copy arbitrary T objects. If T is a built-in type, such as int or double, then operations that copy T objects do not throw exceptions. However, if T is another class type there is no such guarantee. The default constructor, copy constructor and assignment operator of T may throw exceptions just as the corresponding members of Stack do. Even if our program contains no other classes, client code might instantiate Stack<Stack<int> >. We must therefore analyze the effect of an operation on a T object that throws an exception when called from a member function of Stack.

Stack 멤버 함수들은 T 객체를 생성하기도 하고 복사하기도 하고 있습니다. T 가 int나 double과 같은 내장 형식이라면 T 객체를 복사하는 동안 예외가 발생할 리가 없습니다. 그렇지만 T가 클래스 형식이라면 얘기가 달라집니다. T의 기본 생성자, 복사 생성자, 할당 연산자 모두가 Stack과 마찬가지로 예외를 발생시킬 수 있습니다. 우리 프로그램안에 다른 클래스를 정의하지 않았다 하더라도 Stack을 사용하는 코드가 적어도 Stack<Stack<int> >를 생성할 수도 있는 노릇입니다. 그러니 Stack 멤버 함수에서 활용하는 T 객체 연산이 예외를 발생시킬 때, 어떤 일이 벌어질지 분석해 보아야만 하겠지요.

The behavior of Stack should be "exception neutral" with respect to T. The Stack class must let exceptions propagate correctly through its member functions without causing a failure of Stack. This is much easier said than done.

Stack은 T 객체에 대해 "예외 중립적(exception-neutral)"이어야 합니다. 즉, Stack 클래스는 T 객체에서 발생한 예외가 자신을 망가뜨리지 않으면서 멤버함수들을 통과하도록 해야 한다는 것입니다. 이게 정말 말처럼 쉬운 것은 아닙니다.

Consider an exception thrown by the assignment operation in the for loop of the copy constructor:

복사 생성자에 있는 for 루프에서 할당 연산이 예외를 던지를 경우를 살펴 보겠습니다:

template <class T>

Stack::Stack(const Stack& s)

{

v = new T[nelems = s.nelems]; // leak

if( v == 0 )

throw "out of memory";

if( s.top > -1 ){

for(top = 0; top <= s.top; top++)

v[top] = s.v[top]; // throw

top--;

}

Since the copy constructor does not catch it, the exception propagates to the context in which the Stack object is being created. Because the exception came from a constructor, the creating context assumes that no object has been constructed. The destructor for Stack does not execute. Therefore, no attempt is made to delete the array of T objects allocated by the copy constructor. This array has leaked. The memory can never be recovered. Perhaps some programs can tolerate limited memory leaks. Many others cannot. A long-lived system, one that catches and successfully recovers from this exception, may eventually be throttled by the memory leaked in the copy constructor.

복사 생성자가 예외를 잡지 않고 있으므로 Stack 객체를 생성하려고 했던 문맥까지 예외가 전파됩니다. 예외가 생성자 내부에서 시작됐으므로 객체가 아예 생성되지 않은 것이므로 소멸자도 호출되지 않게 됩니다. 그러니 복사 생성자가 할당했던 T 객체 배열을 삭제하지 않게 되고, 결국 해당 배열은 줄줄 세게 됩니다. 해당 메모리를 회복할 수 없습니다. 몇 몇 프로그램은 어느 정도 메모리 누수를 견딜 수 있겠지만 많은 프로그램들이 그럴 수 없습니다. 오랫 동안 실행되어야 하는 시스템은 이런 예외를 잡아서 정상 상태를 회복하면서 계속 실행하려고 노력할 것이고, 복사 생성자에서 발생한 메모리 누수로 인해 결국 메모리 부족으로 허덕이게 될 것입니다.

A second memory leak can be found in push. An exception thrown from the assignment of T in the for loop in push propagates out of the function, thereby leaking the newly allocated array, to which only new_buffer. points:

push에서도 메모리 누수가 발생합니다. push 안에 for 루프에서 T 할당시 예외가 발생하면 함수를 빠져 나가면서 new_buffer 가 가리키는 새 배열을 놓치게 됩니다:

template <class T>

void Stack::push(T element)

{

top++;

if( top == nelems-1 ){

T* new_buffer = new T[nelems+=10]; // leak

if( new_buffer == 0 )

throw "out of memory";

for(int i = 0; i < top; i++)

new_buffer[i] = v[i]; // throw

delete [] v;

v = new_buffer;

}

v[top] = element;

}

The next operation on T we examine is the copy construction of the T object returned from pop:

다음으로 pop 에서 T 객체를 되돌려 줄 때 호출되는 T 객체 복사 생성자를 살펴 보겠습니다:

template <class T>

T Stack::pop()

{

if( top < 0 )

throw "pop on empty stack";

return v[top--]; // throw

}

What happens if the copy construction of this object throws an exception? The pop operation fails because the object at the top of the stack cannot be copied (not because the stack is empty). Clearly, the caller does not receive a T object. But what should happen to the state of the stack object on which a pop operation fails in this way? A simple policy would be that if an operation on a stack throws an exception, the state of the stack is unchanged. A caller that removes the exception's cause can then repeat the pop operation, perhaps successfully.

T 객체 복사 생성자가 예외를 던지면 무슨 일이 벌어질까요? 스택 꼭대기에 있는 객체가 복사될 수 없으니 pop 연산이 실패할 것입니다. 호출자는 당연히 T 객체를 못 받겠지요. pop 연산이 실패한 스택 객체의 상태는 어떻게 되어야 할까요? 스택 객체에 어떤 연산을 수행하더라도 예외가 발생한 경우, 스택 상태가 바뀌지 않아야 한다는 단순한 정책을 따를 수 있을 것입니다. 이렇게 정해 놓으면 호출자는 예외 원인을 제거하고 다시 pop 연산을 다시 호출할 수 있을 것입니다.

However, pop does change the state of the stack when the copy construction of its result fails. The post-decrement of top appears in an argument expression to the copy constructor for T. Argument expressions are fully evaluated before their function is called. So top is decremented before the copy construction. It is therefore impossible for a caller to recover from this exception and repeat the pop operation to retrieve that element off the stack.

그렇지만, Stack의 pop은 되돌려 줄 값을 복사 생성할 때 실패하더라도 스택 상태를 바꿔 놓아 버립니다. v[top--] 수식이 T 복사 생성자의 인자로 들어갈텐데 이 수식이 완전히 평가된 후에 복사 생성자가 호출되므로 top 값이 감소된 후에 복사 생성자가 호출됩니다. 그러므로 호출자가 복사 생성자에서 발생한 예외로부터 회복하여 pop 연산을 반복하더라도 스택에서 마지막에 꺼내려던 그 객체를 꺼낼 수는없습니다.

Finally, consider an exception thrown by the default constructor for T during the creation of the dynamic array of T in operator=:

마지막으로 operator=에서 T 배열을 생성할 때 호출되는 기본 생성자가 예외를 발생시키는 경우를 살펴 보겠습니다:

template <class T>

Stack&

Stack::operator=(const Stack& s)

{

delete [] v; // v undefined

v = new T[nelems=s.nelems]; // throw

if( v == 0 )

throw "out of memory";

if( s.top > -1 ){

for(top = 0; top <= s.top; top++)

v[top] = s.v[top];

top--;

}

return *this;

}

The delete expression in operator= deletes the old array for the object on the left-hand side of the assignment. The delete operator leaves the value of v undefined. Most implementations leave v dangling unchanged, still pointing to the old array that has been returned to the heap. Suppose the exception from T::T() is thrown from within this assignment:

operator=에서 delete 수식은 할당식 좌변 객체가 사용하는 배열을 삭제해 버립니다. delete 연산자를 수행하고 나면 v 값은 어떻게 될지 알 수 없습니다. 대부분 컴파일러들은 v 가 이미 힙으로 반납된 이전 배열을 가리키도록 그대로 놓아 둡니다. 그럼 할당 연산 안에서 T::T()를 수행하는 동안 예외가 발생했다고 가정해 보겠습니다:

{

Stack x, y;

y = x; // throw

} // double delete

As the exception propagates out of y.operator=, y.v is left pointing to the deallocated array. When the destructor for y executes at the end of the block, y.v still points to the deallocated array. The delete in the Stack destructor therefore has undefined results - it is illegal to delete the array twice.

y.operator= 수행 도중 예외가 발생하면 y.v 는 반납된 메모리를 가리킨 채로 남게 됩니다. 이제 블록을 벗어 나려는 순간 y 에 대해 소멸자가 호출될 것인데, y.v 는 반납된 메모리를 여전히 가리키고 있으므로 어떤 일이 벌어질지 알 수가 없습니다 - 배열을 두 번 삭제하는 건 불법이죠.

An Invitation / 초대

Regular readers of this column might now expect to see a presentation of my version of Stack. In this case, I have no code to offer, at least at present. Although I can see how to correct many of the faults in Reed's Stack, I am not confident that I can produce a exception-correct version. Quite simply, I don't think that I understand all the exception related interactions against which Stack must defend itself. Rather, I invite Reed (or anyone else) to publish an exception-correct version of Stack. This task involves more than just addressing the faults I have enumerated here, because I have chosen not to identify all the problems that I found in Stack. This omission is intended to encourage others to think exhaustively about the issues, and perhaps uncover situations that I have missed. If I did offer all of my analysis, while there is no guarantee of it completeness, it might discourage others from looking further. I don't know for sure how many bugs must be corrected in Stack to make it exception-correct.

이제 독자 여러분은 제가 개선된 Stack을 제시해 주길 바라실 것 같습니다. 그렇지만 적어도 지금은 제시할만한 코드가 없습니다. Reed의 Stack에서 여러 결함을 어떻게 수정해야 할지는 알겠지만 제가 예외를 제대로 처리하는 버전을 만들 수 있을지는 확신하기 어렵습니다. 솔직히 저도 Stack이 처리해야만 하는 예외와 관련된 모든 상호 작용들을 완벽하게 이해하고 있지는 못하기 때문입니다. 그래서 Reed에게 (혹은 누구든지) 예외를 제대로 처리하는 Stack 을 공개하도록 초청하는 바입니다. 제가 이 글에서 제시했던 결함들만 해결한다고 예외를 제대로 처리하는 Stack 이라고 할 수 없습니다. 왜냐하면 제가 발견했던 모든 문제를 설명하진 않았기 때문입니다. 다른 분들도 이 문제에 대해 더 철저히 생각하여 제가 놓쳤던 문제들을 밝혀 내길 바라는 마음에 일부러 생략하였습니다. 제가 분석했던 내용이 어차피 완벽하지도 않겠지만 그걸 모두 제시해 버린다면 다른 분들이 더 깊이 보려고 하지 않을 터이니까요. Stack이 예외를 제대로 처리하게 하려면 얼마나 많은 버그를 수정해야 할지 저로서도 잘 모르겠습니다.

C++ 이야기 서른두번째: 예외가 성능에 미치는 영향

김윤수 — Mon, 21 Jun 2010 00:01:54 +0900

2009/09/25 - [S/W개발/C++ 이야기] - C++ 이야기 서른한번째: 왜 예외를 쓰는 게 좋을까요? 에서 왜 예외를 쓰는 것이 좋은지에 대해 얘기를 해 봤습니다. 정리해서 말씀드리자면 결함내성 특성(fault-tolerant)을 가진 소프트웨어를 작성하기 쉽게 해주기 때문에 예외를 쓰는 것이 좋다라고 말씀드렸습니다.

그런데 폴리비님께서 다음과 같은 댓글을 남겨 주셨습니다.

예외 처리기능이 C++에 들어가서 좋지만, 속도 저하가 약간 있어서 꺼리는 경우도 있어요.
스트롭 할아버지는 별로 속도 저하 없으니 꼭 쓰라고 하지만 RTTI처럼 속도 때문에 꺼려지는 점이 있긴 하죠!
STL도 vector에 대해 at 메소드는 예외처리를 하지만, 완전 동일한 기능인 [] 연산자에서는 예외처리를 하지만, 많은 반복 예상되는 단순한 코드같은 경우 예외 처리가 꼭 필요하지는 않으면서도 예외 처리를 할 경우 성능을 떨어뜨리는 경우도 있습니다.

예외 처리 기능을 활용하면 성능을 떨어뜨리니 무조건 쓰는 건 좋지 않다라는 말씀이겠죠. 이 댓글을 보고 예외가 성능에 도대체 어느 정도나 영향을 미치는지 알아보고 싶어서 실험을 해 봤습니다.

예외 처리가 성능에 미치는 영향을 측정하기 위해서는 어떻게 실험해야할까요? 예외 처리 기능을 사용하는 프로그램과 사용하지 않는 프로그램의 실행 시간을 비교해봐야겠다는 생각이 자연스럽게 떠오릅니다. 그렇지만 이 둘만 비교해서는 예외가 성능에 미치는 영향을 정확히 파악할 수 없을 것입니다. 왜냐하면, 단순히 try/catch 문을 사용했을 경우와 실제로 예외가 발생한 경우에 발생하는 overhead가 다를 것이기 때문입니다. try/catch 문만을 사용했을 경우에는 예외 처리를 위한 준비과정만 부가적인 overhead가 되겠지만, 예외가 실제로 발생한 경우에는 예외를 처리하는 과정(대표적으로 stack unwinding)이 overhead가 될 것이기 때문입니다.

예외가 발생하는 경우도 호출 깊이(call depth)가 어느 정도이냐에 따라 overhead가 달라질 수 있을 것이므로 호출 깊이도 달리 하면서 실험할 필요가 있을 것입니다. 마지막으로 호출 깊이가 깊어지는 경우 중간에 예외 처리기가 여러번 중첩될 수도 있고, 이런 예외 처리기에서 예외를 재발생시키거나(rethrow) 다른 예외로 매핑하는 경우도 있을 것입니다. 따라서 이러한 경우도 분리해서 테스트할 필요가 있을 것입니다.

정리하자면 다음 네 가지 경우에 대해 호출 깊이를 달리하여 테스트하면 어느 정도 예외가 성능에 미치는 영향에 대해 윤곽을 잡을 수 있을 것 같습니다.

1. 예외 처리를 사용하지 않는 프로그램

2. 예외 처리를 사용하나 예외를 발생시키지 않는 프로그램

3. 예외 처리를 사용하고 예외를 발생시키나 재발생시키지는 않는 프로그램

4. 예외 처리를 사용하고 예외를 발생시키며 재발생시키기도 하는 프로그램

호출 깊이를 달리하는 것은 동일한 함수를 재귀 호출하는 회수를 달리하면 될 것입니다.

이 네 가지 경우를 다음과 같이 별도의 함수로 작성하였습니다.

먼저, 1. 예외 처리를 사용하지 않는 프로그램입니다.

void NoTry(long long& r, int& rcnt) {

shared_ptr<Foo> p(new Foo());

r += (rand() % 100);

if (--rcnt)

NoTry(r, rcnt);

}

Foo 라는 클래스는 class Foo {}; 라고 비어 있는 클래스로 정의했습니다. rcnt 는 호출 깊이를 조절하기 위한 변수로 0이 되면 더 이상 재귀적으로 호출하지 않습니다. 함수 본문에서는 shared_ptr 로 Foo 라는 객체를 할당했다가 함수에서 리턴할 때 자동해제 되도록 하였고, r 이라는 참조 변수를 rand() % 100 결과값만큼 증가시키도록 하여 혹시 있을지도 모르는 컴파일러 최적화를 피하도록 했습니다. 더불어 함수 본문에서 어느 정도 시간이 걸리도록 하여 단순 함수 호출 overhead가 실행시간의 대부분을 차지하지 않도록 해 보았습니다.

그 다음은 2. 예외 처리를 사용하나 예외를 발생시키지 않는 프로그램입니다.

void TryNoException(long long& r, int& rcnt) {

try {

shared_ptr<Foo> p(new Foo());

r += (rand() % 100);

if (--rcnt)

TryNoException(r, rcnt);

}

catch (const Ex&) {

}

NoTry와 거의 동일하나 함수 본문을 try/catch로 둘러 쌓았다는 점만 다릅니다. 실제로 예외는 발생하지 않으므로 try/catch 로 인한 overhead만을 측정할 수 있을 것입니다. 예외 클래스 Ex 는 Foo와 비슷하게 class Ex {}; 로 비어 있는 클래스로 정의했습니다.

다음은 3. 예외 처리를 사용하고 예외를 발생시키나 재발생시키지는 않는 프로그램입니다.

void TryException(long long& r, int& rcnt) {

try {

shared_ptr<Foo> p(new Foo());

r += (rand() % 100);

if (--rcnt)

TryException(r, rcnt);

else

throw Ex();

}

catch (const Ex&) {

}

2번 프로그램과 거의 비슷하지만, 재귀적으로 계속 호출하다가 제일 마지막에 Ex() 예외를 발생시킵니다. 그리고, catch 문에서 Ex 예외를 잡고 있으니 가장 깊은 호출 스택에서 예외 처리기가 동작하여 예외를 처리한 후, 그 다음부터는 단순한 함수 리턴과정을 거치게 될 것입니다. 정리하자면, 호출 깊이가 깊어지더라도 예외 처리로 인한 overhead는 한 번만 발생하게 될 것입니다.

마지막으로 4. 예외 처리를 사용하고 예외를 발생시키며 재발생시키기도 하는 프로그램입니다.

int rethrowCnt = 0;

void TryRethrowException(long long& r, int& rcnt) {

try {

shared_ptr<Foo> p(new Foo());

r += (rand() % 100);

if (--rcnt)

TryRethrowException(r, rcnt);

else

throw Ex();

}

catch (const Ex&) {

if (--rethrowCnt)

throw;

}

3.번하고 거의 동일한데, 예외 처리기 안에서 rethrowCnt 값을 하나씩 감소시키면서 예외를 재발생시키고 있습니다. 이렇게 하면 호출 경로상의 가장 상위 스택에서는 예외를 처리하게 되지만 다른 스택에서는 예외를 처리하기도 하고, 재발생시키기도 하게 될 것입니다. 이렇게 할 경우 예외를 발생시키고 처리하는 overhead가 호출 깊이 만큼 발생하게 됩니다. 이를 위해서는 전역변수인 rethrowCnt가 호출 깊이와 동일한 값으로 설정되어야겠지요.

이 함수들 실행시간을 비교해야 하는데, 한 번만 수행할 경우 너무 짧은 시간에 실행이 끝나 버릴테니, 여러번 수행한 후, CPU 사용량을 측정해야 할 것입니다. 실행 시작전 시각과 실행 완료 후 시각의 차로 실행시간을 측정할 경우에는 중간에 OS가 다른 프로그램을 스케쥴링하면서 실제 이 함수들에 의한 실행시간 외에 다른 시간이 끼어들 수 있으므로 CPU 사용량을 측정해야 합니다. CPU 사용량을 측정하기 위해서 time 이라는 시스템 유틸리티를 사용했습니다.

위 함수들을 여러 번 수행하기 위해 다음과 같은 함수를 작성했습니다.

typedef void (*F)(long long&, int&);

long long RunLoop(long long n, F f, int recursionCnt) {

long long r = 0;

for (; n >= 0; --n) {

int rcnt = recursionCnt;

rethrowCnt = recursionCnt;

f(r, rcnt);

}

return r;

}

주어진 함수 f를 n 번만큼 수행하는 함수입니다. 원하는 재귀 호출 회수도 인자로 받아서 f 함수에 넘겨 줍니다. 그리고, 전역변수인 rethrowCnt를 recursionCnt 값으로 설정해 줍니다. 이는 TryRethrowException() 함수가 각 호출 단계에서 예외를 재발생시키고 최상위 호출 단계에서는 예외를 처리하도록 하기 위한 것입니다.

이 RunLoop를 활용하여 각 함수를 여러번 수행해 주는 main 함수는 다음과 같이 작성했습니다.

void Usage() {

cout << "Please, specify test case number and call depth" << endl;

cout << "1 means no try/catch block" << endl;

cout << "2 means try/catch block but no exception" << endl;

cout << "3 means try/catch block and exception" << endl;

cout << "4 means try/catch block and rethrow exception" << endl;

}

const string noTryCase = "1";

const string tryNoExCase = "2";

const string tryExCase = "3";

const string tryRethrowCase = "4";

int main (int argc, char * const argv[]) {

if (argc != 3) {

Usage();

return -1;

}

srand((unsigned)time(0));

F f = 0;

if (noTryCase == argv[1]) {

f = NoTry;

}

else if (tryNoExCase == argv[1]) {

f = TryNoException;

}

else if (tryExCase == argv[1]) {

f = TryException;

}

else if (tryRethrowCase == argv[1]) {

f = TryRethrowException;

}

else {

Usage();

return -1;

}

int callDepth = atoi(argv[2]);

if (callDepth <= 0)

callDepth = 1;

return RunLoop(10000000, f, callDepth);

}

보시는 것처럼 명령행 인자로부터 test case 번호와 호출 깊이를 받도록 하였습니다. 이렇게 할 경우, 순수하게 함수를 수행하는 시간 외에 명령행 인자를 해석하고 필요한 변수를 초기화하는 overhead가 끼어들긴 하겠지만, 각 함수를 수행하는 회수를 충분히 크게 해주면-위 예제는 10000000번-이 overhead 가 차지하는 시간이 아주 작아지게 될 것입니다.

그리고, 각 test case를 한번씩만 수행할 경우, 실행 당시 시스템 상태에 따라 실행 시간이 달라질 수 있으므로, 다음과 같은 shell script 를 이용하여 각 test case를 10번씩 수행하고 그 평균 값을 서로 비교하였습니다.

$ cat test.sh

#!/bin/sh

run_test() {

test_case=$1

test_run=$2

while [ $test_run -gt 0 ]; do

echo

echo "time ./extest $test_case $3"

time ./extest $test_case $3

test_run=`expr $test_run - 1`

echo

done

}

call_depth=1

while [ $call_depth -le 5 ]; do

run_test 1 10 $call_depth

call_depth=`expr $call_depth + 1`

done

call_depth=1

while [ $call_depth -le 5 ]; do

run_test 2 10 $call_depth

call_depth=`expr $call_depth + 1`

done

call_depth=1

while [ $call_depth -le 5 ]; do

run_test 3 10 $call_depth

call_depth=`expr $call_depth + 1`

done

call_depth=1

while [ $call_depth -le 5 ]; do

run_test 4 10 $call_depth

call_depth=`expr $call_depth + 1`

done

그럼 실제 실험 결과를 보실까요?

결과에서 확인하실 수 있는 것처럼 try/catch 를 사용하지 않는 함수와 try/catch를 사용하되 예외를 발생하지 않는 경우는 거의 차이가 없음을 확인할 수 있습니다. 그래프에서 보면 TryNoException이 초록색인데 NoTry 파란색에 가려 전혀 보이질 않고 있습니다. 이 결과는 저로서도 약간 의외였는데요. 아무리 최적화된 try/catch를 구현하더라도 예외 처리 준비 작업이 어느 정도 필요하기 때문에 overhead가 어느 정도는 있을 줄 알았는데 실제로는 거의 차이가 없음을 확인할 수 있었습니다. 이것은 제가 사용하고 있는 컴파일러가 상당히 최적화된 예외 처리 메커니즘을 구현하고 있기 때문인 것 같습니다. C++ 철학중 하나인 수익자 부담의 원칙을 잘 따르고 있는 컴파일러라고 생각이 됩니다.

다음으로 TryException 과 NoTry, TryNoException 케이스를 비교하면 호출 깊이에 따라 실행시간이 늘어나는 비율(기울기)은 거의 비슷한데, 위 아래로 간격이 상당히 떨어져 있음을 확인할 수 있습니다. TryException의 경우 한 번 예외가 발생하여 처리된 이후에는 계속해서 TryNoException과 거의 동일한 overhead만 발생할 것이기 때문에, 이것은 한 번 발생한 예외로 인한 overhead가 상당히 크다는 것을 증명한다고 해석해야 할 것입니다. 이것은 TryRethrowException 케이스에 의해 더 확실해집니다. TryRethrowException의 경우 각 호출 단계에서 예외를 발생시키고 처리하기 때문에 호출 깊이에 비례해서 예외 발생 및 처리 overhead가 발생하기 때문입니다. 그래서 다른 세가지 케이스에 비해 기울기가 훨씬 가파른 것을 확인할 수 있습니다.

실제 제가 위 네 가지 경우에 대해 선형 회귀식을 구했을 때 다음과 같은 결과가 나왔습니다.

NoTry: y = 5.0897x - 1.9361, R^2 = 0.9984

TryNoException: y = 4.7766x - 1.3758, R^2 = 0.999

TryException: y = 5.2183x + 48.001, R^2 = 0.9971

TryRethrowException: y = 130.36x - 79.22, R^2 = 09985

예외가 한 번 발생했을 때, 처리하는 overhead가 상당한 것을 확인할 수 있습니다.

이상을 종합해 보면 다음과 같이 결론 내릴 수 있을 것 같습니다.

1. 단순히 예외 처리를 위해 try/catch 구조를 사용한다고 하여 overhead가 발생하지는 않는다.

2. 예외 발생/처리 overhead는 상당히 크다.

이 결론은 우리에게 시사하는 바가 상당히 크다고 생각합니다.

1) 예외가 성능을 많이 저하시킨다는 막연한 생각에 아예 예외를 쓰지 않는 것도 피해야 할 것이고, 2) 예외를 예외 답지 않게 사용하는 것-즉, 에러 상황이 아닌 상당히 자주 발생할 수 있는 상황을 예외로 처리하는 경우-도 피해야 할 것이고, 3) 실시간성이 중요한 프로그램에서 호출 경로상 예외가 발생했을 경우 실시간성 검증 없이 예외를 사용하는 경우도 피해야 할 것입니다.

제가 테스트한 환경은 다음과 같습니다.

$ uname -a

Darwin MyMac.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

$ g++ --version

i686-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5564)

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

컴파일 할 때는 다음과 같은 옵션을 주었습니다.

$ g++ -O3 -o extest -I /usr/local/include/boost-1_36 main.cpp

여러분들도 무작정 예외 처리 기능을 쓰지 않거나 혹은 쓰는 것이 아니라 자신이 개발하는 환경에서 실제 테스트를 해 보신 후에 데이터를 기반으로 예외 처리 기능을 사용할 것인지 말 것인지를 의사결정한다면 함께 일하는 분들 간에 동일한 생각으로 일할 수 있을 것입니다.

여러분도 자신의 개발 환경에서 테스트해 보신 후에 결과를 트랙백으로 한 번 연결해 주시면 감사하겠습니다.

(테스트 함수를 구현한 소스와 shell script를 첨부합니다. 그리고 한 가지, TryRethrowException의 경우 실험 시간이 너무 오래 걸려 천만번이 아닌 백만번만 수행한 결과를 단순 10배 한 결과를 서로 비교하였다는 것을 알려 드려야 할 것 같습니다. 철저하게 하려면 실제로 천만번 수행한 후에 결과를 비교해야겠지만 블로그 글감으로 쓰기에는 이런 정도로 해도 될 것 같아서 이렇게 결과를 올립니다)

main.cpp

test.sh

최근 C++ 소식

김윤수 — Thu, 29 Apr 2010 21:58:13 +0900

1. C++0x Final Committee Draft(FCD)가 릴리즈됐습니다: Draft는 여기서 다운받을 수 있습니다. 표준화 과정 중에 논의된 내용들을 더 자세히 알고 싶으시면 이 링크를 보시면 됩니다. Draft는 무려 1310페이지에 달합니다. 읽어보실 분은 미리 각오하시고 읽어 보시는 게 나을 것 같습니다. ^^

2. C++0x FCD를 읽고 comment 할 것들이 있다면 여기에 가서 comment를 남기시면 됩니다. 이제 final draft인 상태이기 때문에 주로 wording에 관련된 comment를 받아들이겠죠? 새로운 feature 추가하자 그러면 아마 받아들이지 못하겠죠. C++에 새로운 feature 를 추가하고 싶다면 여기를 한 번 보시고 페이지 관리자에게 메일 보내보시면 될 듯(저도 보내보진 않았어요).

3. Visual Studio 2010에 포함된 VC++이 지원하는 C++0x feature 구현 상태는 여기에서 보시면 됩니다.

4. GCC에서 지원하는 C++0x feature 구현 상태는 여기에서 보시면 됩니다.

5. 각 컴파일러의 C++0x feature 구현 상태는 여기에 정리되어 있네요.

6. C++ & Beyond 2010 Event가 열린답니다. 유명한 C++ 책 저자인 Herb Sutter, Scott Meyers , Andrei Alexandrescu 이 세 분이 주축이 돼서 진행하는 이벤트인가 보네요. 60명만 참가할 수 있답니다. 관심있으신 분은 여기서 등록하시구요. 누군가 저를 스폰서 해 주실 분이 계시다면 저도 가보고 싶은데 말입니다. ㅠ.ㅠ

C++ 이야기 서른한번째: 왜 예외를 쓰는 게 좋을까요?

김윤수 — Fri, 25 Sep 2009 23:59:16 +0900

If you're an English speaker, please follow this link

이글의 최신본은 항상 여기에 있습니다. 최신본은 코드에 syntax highlighting도 되어 있고, 철자법도 맞추고 부가정보도 계속 업데이트 하고 있습니다.

여러분은 서브루틴에 에러가 발생했다는 걸 알려주려 할 때 C++ 예외를 사용하시나요? 쓰시지 않는다면, 왠가요? 에러를 나타내는 특별한 에러 코드를 되돌려주면 되기 때문에 전혀 사용할 필요가 없다라고 답변하실지도 모르겠습니다. 사용하신다면, 왠가요? 이 질문에 대해서는 다른 방법이 있나요?라고 오히려 반문하시는 분이 있을지도 모르겠네요.

C++에 예외가 도입된 이유를 밝하기 위해 이 글을 작성하게 됐습니다. 이 설명을 통해 위에 두 부류의 분들 모두 예외에 대해 더 잘 이해하게 되고, 예외를 이용하여 더 좋은 코드를 작성하는데 도움이 되시리라 생각합니다.

C++에 왜 예외에 도입되었다고 생각하세요? 왜 아직도 Java나 C#같은 언어가 C++의 예외를 물려 받았다고 생각하세요? 그런데는 틀림없이 어떤 이유가 있을 것입니다. 그 이유는 바로 결함내성(fault-tolerant) 소프트웨어를 쉽게 작성하도록 하기 위한 것입니다.

C/C++ 같이 상태를 갖는 프로그래밍 언어에서 에러 처리를 한 후에도 일관성있는 상태를 유지해야 한다는 건 결함내성을 달성하는데 있어 정말 까다로운 문제입니다.

예를 들어, 다음과 같이 어떤 파일을 열고 데이터를 읽어들이는 짤막한 C 코드를 생각해 보기로 하겠습니다.

char*
OpenAndRead(char* fn, char* mode)
{
  FILE* fp = fopen(fn, mode);
  char *buf = malloc(BUF_SZ);
  fgets(buf, BUF_SZ, fp);
  return buf;
}

OpenAndRead()의 목적이 워낙 간단하고 분명하니, 그 구현도 무척이나 간단하고 읽기도 쉽고 이해하기도 쉽습니다. 위 코드는 모든 서브루틴이 잘 수행된다면 잘 작동할 것입니다. 그렇지만 'fn' 파일이 없거나 파일에 대한 접근 권한이 없다면 어떻게 될까요? malloc() 이나 fgets() 이 실패하면 어떻게 될까요? 위 코드를 결함내성이 있게 만들려면 각 서브루틴 호출 후에 에러가 발생했는지 확인해보고, 에러가 발생했다면 어떤 행동을 취해야할 것인지 결정해야 합니다. 그 취해야할 행동이 여기서는 단순히 에러 메시지를 출력하고 획득했던 자원들을 해제하고, -1 을 리턴하는 걸로 가정해 보겠습니다. 그렇다면 코드를 다음과 같이 수정할 수 있겠지요.

int
OpenAndRead(char* fn, char* mode, char** data)
{
  *data = NULL;
  char* buf = NULL;
  FILE* fp = fopen(fn, mode);
  if (!fp) {
    printf("Can't open %s\n", fn);
    return -1;
  }
 
  buf = malloc(BUF_SZ);
  if (!buf) {
    printf("Can't allocate memory for data\n");
    fclose(fp);
    return -1;
  }
 
  if (!fgets(buf, BUF_SZ, fp)) {
    printf("Can't read data from %s\n", fn);
    free(buf);
    fclose(fp);
    return -1;
  }
 
  *data = buf;
 
  return 0;
}

두 개의 코드를 비교해 보니 느낌이 어떠세요? 두번째 버전은 주 알고리즘을 처리하는 부분과 에러를 처리하는 부분이 막 섞여 있어서 읽기도 힘들고 이해도 힘들어졌습니다. 게다가 라인수도 많아져서 일을 더 많이해야하네요.

예외를 사용하면 이런 문제가 발생하지 않습니다. 한 번 fopen(), malloc(), fgets() 이 FileDoesNotExist, FileNotAccessible, MemoryExhausted, EndOfFile 라는 예외를 발생시킨다고 가정해 보겠습니다. 그렇다면 다음과 같이 코드를 변화시킬 수 있을 것입니다.

int
OpenAndRead(char* fn, char* mode, char** data)
{
  *data = NULL;
  char* buf = NULL;
  FILE* fp = NULL;
  try {
    fp = fopen(fn, mode);
    buf = malloc(BUF_SZ);
    fgets(buf, BUF_SZ, fp);
    *data = buf;
    return 0;
  }
  catch (const FileDoesNotExist&) {
    printf("Can't open %s\n", fn);
  }
  catch (const FileNotAccessible&) {
    printf("The access %s is not permissible for %s\n", mode, fn);
  }
  catch (const MemoryExhausted&) {
    printf("Can't allocate memory for data\n");
    fclose(fp);
  }
  catch (const EndOfFile&) {
    printf("Can't read data from %s\n", fn);
    fclose(fp);
    free(buf);
  }
 
  return -1;
}

OpenAndRead() 주 제어 흐름이 이제 에러 처리와 깔끔하게 분리가 된 걸 보실 수 있겠죠? OpenAndRead() 이 버전은 좀 더 읽기 쉽게 됐네요. 그렇지만 아직도 라인수가 좀 많은 편입니다. 실상 예외가 발생했을 때 이루어지는 "스택 풀기(stack unwinding)"이라는 과정을 이해하시면 더 적은 코드로 동일한 효과를 낼 수 있답니다.

예외가 발생하고 나서 그 예외를 처리할 수 있는 예외 처리기를 만날 때까지 스택을 풀어나가면서, C++ 실행 환경은 try 블록부터 생성됐던 모든 자동 객체들에 대해 소멸자를 불러주게 됩니다. 이 과정을 "스택 풀기"라고 합니다. 자동 객체들은 생성됐던 반대 순서로 소멸됩니다.

이런 원리에 따라 자원을 소유하는 객체들을 자동 객체로 정의하게 되면 예외가 발생하더라도 그런 객체들이 자동적으로 소멸되는 것이지요. 이런 프로그래밍을 가능케 하는 자원 소유 객체들이 파일이나 메모리에 대해 이미 정의되어 있습니다. 파일 자원용으로는 std::fstream을 사용할 수 있고, 메모리 자원용으로는 boost::scoped_ptr을 사용할 수 있습니다. OpenAndRead()를 다시 한 번 아래와 같이 구현할 수 있을 것입니다.

char*
OpenAndRead(const std::string& fn, std::ios_base::openmode mode)
{
  try {
    std::fstream fs(fn.c_str(), mode);
    boost::scoped_ptr buf(new char[BUF_SZ+1]);
    fs.getline(buf.get(), BUF_SZ);
    return buf.get();
  }
  catch (const std::ios_base::failure&) {
    std::cout << "Can't open or read data from " << fn << std::endl;
  }
  catch (const std::bad_alloc&) {
    std::cout << "Can't allocate memory for data" << std::endl;
  }
 
  return 0;
}

C++ 실행기(run-time)가 모든 자원 해제를 알아서 하게 됩니다. 그래서 에러 처리 코드에 자원 해제 코드를 추가할 필요가 없게 됩니다. OpenAndread() 가 상당히 간단해지고, 읽기도 쉬워졌죠?

예외가 발생하게 되면 C++ 실행기가 예외 처리기를 만날 때까지 소멸자를 역순으로 호출하면서 스택 풀기를 수행할 것입니다. 위 경우에는 동일한 스택 프레임에 예외 처리기가 있고, 두 개의 자동 객체, fs와 buf가 있습니다. 예외 처리기로 제어권이 넘어가기 전에 fs와 buf의 소멸자가 호출될 것이고, 소멸자는 내부 자원을 해제하게 될 것입니다.

위와 같은 방식은 예외에 대한 반응이 워낙 간단하기 때문에 만족스럽지 않을 거라 생각합니다. 위와 같은 방식으로는 OpenAndRead()의 호출자가 그저 성공 또는 실패 정도만 나타낼 수 있는 정상 포인터 또는 널 포인터를 받을 뿐이기 때문입니다. 호출자 입장에서 생각해 보면, 왜 실패했는지를 알지 못한 상태에서 널 포인터로 할 수 있는 게 없습니다.

위에서 알 수 있듯이, 에러에 어떻게 반응할지를 결정하는 것이 결함 내성 소프트웨어를 작성하는 데 겪는 또 다른 어려움입니다. 에러가 발생한 상황(context)과 원인이 에러에 대한 반응을 결정하는 데 있어 필수적인 정보라 할 수 있습니다. 그런데 그런 정보들은 여기 저기 흩어져 있기 마련입니다. 에러 처리에는 보통 두가지 부분의 코드가 관련이 있습니다. 하나는 호출자이고 또 하나는 피호출자입니다. 피호출자는 에러가 발생한 원인은 알지만 상황은 잘 모를 가능성이 높고, 반대로, 호출자는 상황은 알지만 이유를 모를 가능성이 높습니다. 이런 상황을 어떻게 극복할 수 있을까요?

피호출자가 충분한 상황을 알고 있는 호출자에게 최대한 정확히 에러가 발생한 원인을 알려준다면 분명한 해결책이 될 수 있을 것 같습니다. 그렇지만 호출자가 피호출자를 직접 호출한 게 아니었다면 어떻게 될까요? 충분한 상황 정보를 가지고 에러에 대한 반응을 결정할 수 있는 호출자가 에러가 발생한 원인을 정확히 알고 있는 피호출자로부터 멀리 떨어져 있다면, 중간 함수가 에러가 발생한 상세 원인을 무시해 버리고 그냥 성공 또는 실패만을 나타내는 코드를 되돌려 주는 일이 자주 발생합니다. 예제를 통해서 확인해 볼까요?

int
OpenAndRead(char* fn, char* mode, char** data)
{
  *data = NULL;
  char* buf = NULL;
  FILE* fp = fopen(fn, mode);
  if (!fp) {
    printf("Can't open %s\n", fn);
    return -1;
  }
 
  buf = malloc(BUF_SZ);
  if (!buf) {
    printf("Can't allocate memory for data\n");
    fclose(fp);
    return -2;
  }
 
  if (!fgets(buf, BUF_SZ, fp)) {
    printf("Can't read data from %s\n", fn);
    free(buf);
    fclose(fp);
    return -3;
  }
 
  *data = buf;
 
  return 0;
}
 
char* foo(char* fn, char* mode)
{
  char* data = 0;
  if (OpenAndRead(fn, mode, &data) >= 0)
    return data;
  else
    return 0;
}
 
void bar()
{
  ...... // fn과 mode를 얻어낸다
  char* data = foo(fn, mode);
  if (data) {
    ...... // 정상 처리
  }
  else {
    ...... // bar()가 뭘 할 수 있을까요?
  }
}

OpenAndRead()는 되돌림 코드(return code)를 통해 에러를 구분하려고 하고 있습니다. 근데 foo()는 그걸 무시하고 그냥 널 포인터나 정상 포인터를 되돌려 주고 마네요. 이래서는 bar()가 진짜 무슨 일이 벌어지고 있는지 알아낼 수가 없게 되고, 널 포인터로는 뭔가 할 수 있는 게 없어집니다. 아마도 bar()가 할 수 있는 거라곤 에러 메시지를 출력하고 그냥 종료하거나 가능하다면 에러를 무시해 버리는 거겠죠. 호출 경로 상의 각 함수들은 어떻게든 에러 처리에 관여할 수 밖에 없기 때문에 예외가 없이는 이런 상황이 더 심각해 질 수 밖에 없습니다. 어떤 함수 작성자는 되돌림 코드가 뭘 의미하지 모를 수도 있고, 에러가 뭘 의미하는지 별로 상관하지 않을 수도 있고, 아니면 충분한 상황을 알지 못해 어떤 처리를 해야할지 결정을 못할 수 있습니다. 그래서 호출 경로 상의 어딘가에서 되돌림 에러 코드가 그냥 실패를 나타내는 값으로 바뀌어 버리게 되는 거죠.

예외를 사용한다면 이런 문제를 해결할 수 있습니다. 호출 경로상의 어떤 함수가 예외를 처리하지 못하겠다면 그 함수는 그냥 예외를 잡지(catch) 말고 무시해 버리면 됩니다. 진짜 처리할 수 있는 예외만 처리하면 되는 것이지요.

자~ 이제 마지막으로 한번 만 더 OpenAndRead()를 변형시켜 보겠습니다. 일단 OpenAndRead()와 foo()는 예외를 어떻게 처리해야 할지 모른다고 가정하고, bar()는 처리할 수 있다고 가정해 보겠습니다.

char*
OpenAndRead(const std::string& fn, std::ios_base::openmode mode)
{
  std::fstream fs(fn.c_str(), mode); // std::ios_base::failure() 가 발생할지 모릅니다.
  boost::scoped_ptr buf(new char[BUF_SZ+1]);  // std::bad_alloc() 가 발생할지 모릅니다
  fs.getline(buf.get(), BUF_SZ);
  return buf.get();
}
 
char* foo(char* fn, char* mode)
{
  // 아무런 예외도 잡지 않고 있습니다
  return OpenAndRead(fn, mode);
}
 
void bar()
{
  ...... // fn과 mode를 알아냅니다
  try {
    char* data = foo(fn, mode);
  }
  catch (const std::ios_base::failure&) {
    std::cout << "Can't open or read data from " << fn << std::endl;
    // 왜 fn 열어서 데이터를 읽으려고 했는지를 안다면 좀 더 정확한 진단 메시지를 출력하고,
    // 사용자에게 뭔가 조치를 취하라고 알려줄 수 있습니다
  }
  catch (const std::bad_alloc&) {
    std::cout << "Can't allocate memory for data" << std::endl;
    // 이런 경우를 대비해 메모리를 미리 따로 마련해 놓았다면 bad_alloc()를 
    // 좀 더 부드럽게 처리할 수도 있을 것입니다.
  }
}

위 코드에서 볼 수 있듯이, OpenAndRead()와 foo()가 다시 간단해 졌고, bar()만 에러 처리에 관여하고 있습니다. 게다가 예외가 뭘 의미하는지 알고 충분한 상황 정보기 있기 때문에 예외를 정말 절 처리할 수 있게 됐습니다.

예외의 또 한 가지 장점은 예외는 그 자체로서 객체라는 것입니다. 이건 예외를 발생시킬 때 될 수 있으면 많은 정보를 담아서 발생시킬 수 있다는 것입니다. 다시 말해 예외는 되돌림 코드보다 훨씬 표현력이 좋다고 할 수 있습니다. 그렇다면, 예외 처리기는 그 정보들을 접근할 수 있게 되고, 그 정보들은 어떤 일이 벌어지고 있는지를 정확히 알아내는 데 큰 도움이 될 것입니다.

이제 여러분에게 "C++ 예외를 사용하고 싶으세요"라고 묻고 싶군요. 뭐라고 답변하시겠어요? "당연히 써야죠"라는 답변을 들었으면 하네요.

위키 업데이트 상황

김윤수 — Tue, 22 Sep 2009 23:27:56 +0900

얼마전에 제가 블로그 글들 옮깁니다라는 글에서 소프트웨어 개발 관련 글들을 위키로 차례 차례 옮길 것이라고 공지를 드렸습니다. 그 이후에 짬이 나는 대로 옮기고 있는데, 블로그와 위키와의 차이점 때문에 그것도 그리 쉬운 것만은 아니네요. 일일이 하나씩 옮겨야 하니... 암튼 지금까지는 13개의 글을 옮겼습니다.

어떻게 옮기고 있는지 궁금하신 분들은 한 번 들러보시기 바랍니다.

글 옮기는 거 외에도 한번 Why Exceptions?라는 제목으로 C++ exception을 쓰면 어떤 점이 좋은지에 대해 영어로 글을 써 봤습니다. 영어 잘 한다고 자랑하려는 건 아니구요(어차피 잘하지도 못하지만), 국내에만 머무르는 사람이 되지 않기 위해 영어로 작성해 보고 있습니다. 영어에 자신 있으신 분들은 여기에 한글 번역된 것을 올리기 전에 먼저 읽어 보시고 Comment 주시면 감사하겠습니다.

위키 주소는 http://opensw.wikidot.com 입니다. 많은 관심과 격려 부탁드립니다. ^^

미투데이 대 트위터

김윤수 — Sun, 13 Sep 2009 12:12:30 +0900

미투데이와 트위터의 차이점: 미투데이는 초기부터 API를 써서 3rd party 응용을 위한 환경을 조성하긴 했지만 twitter 만큼은 open 하지 못했다. 왜냐면 traffic을 외부로 잘 넘겨주지 않는 내부완결형 구조 특성이 있다.(2tw 미투데이 트위터 차이점)2009-09-13 11:12:35
트위터는 140자 제한마저 외부 서비스를 활성화하는데 사용하고 있으나 미투데이는 링크를 표현하기 위한 별도의 방법을 정의했다. 이 때문에 미투데이가 풍부한 내용을 담을 수 있다는 장점이 있지만 에코시스템 창출에는 트위터가 나은 것 같다(2tw 미투데이 트위터 차이점)2009-09-13 11:15:58
물론 미투데이가 훨씬 우리나라 사람들 스타일에 맞는 것 같긴 하다.(2tw 미투데이 트위터 차이점)2009-09-13 11:16:59
그리고, 사진이랑 비디오를 flickr, youtube에 upload 하긴 하지만 in place로 보여주는 점 등이 그 예이다. 3rd party service가 활성화되기 위한 필요 조건이 traffic 분산이 아닐까 생각해 본다.(2tw 미투데이 트위터 차이점)2009-09-13 11:23:23
미투데이는 이제 인기를 끌기 시작했고, 트위터는 이미 사용자가 폭발한 상태이니 지금 시점에서 직접 비교하긴 힘들지만 나중에 어떻게 될까 상당히 궁금해지는 대목이다.(2tw 미투데이 트위터 차이점)2009-09-13 11:30:06
미투데이가 훌륭한 점 중에 하나는 태그가 따로 있다는 것이다. 짧은 글들이라도 모이면 상당히 중요한 정보가 될 수 있는 것인데, 태그가 그 역할을 충실히 해주고 있다.(2tw 미투데이 트위터 차이점)2009-09-13 11:32:24
트위터도 해쉬태그가 있지만 해쉬태그는 영어밖에 안된다는 문제가 있고, 해쉬태그 여러개 주면 글 쓸 공간이 금방 부족해져 버린다. 다른 사람 글에 대해 핑백으로 링크를 달 수 있는 것도 좋은 점 중의 하나이다.(2tw 미투데이 트위터 차이점)2009-09-13 11:35:02
트위터에서는 다른 사람 글도 보이고 자기 생각도 보이고 싶더라도 공간이 부족해서 그렇게 하질 못한다. 결국 원문을 편집하거나 자기 생각은 거의 없이 그냥 RT를 하게 되는 경우가 종종 있다.(2tw 미투데이 트위터 차이점)2009-09-13 11:36:43
다분히 유명인 위주로 다른 사람들은 그저 정보를 확산시키는 매개체로 작용할 가능성이 충분히 있다는 얘기다. 각 개개인의 개성은 몰살되고, 마케팅을 위한 채널 정도로만 악용될 가능성이 충분히 있다.(2tw 미투데이 트위터 차이점)2009-09-13 11:38:16
트위터에서는 친구라는 개념이 없고 팔로워라는 개념이 있는데, 팔로워는 미투데이의 구독개념과 비슷하다고 볼 수 있다. 친구만큼 깊은 관계를 맺고 싶진 않지만, 그 사람이 생성하는 정보에 대해서는 관심이 있다라는 정도라고 할 수 있다.(2tw 미투데이 트위터 차이점)2009-09-13 11:44:24
물론 때에 따라서는 팔로워가 친구만큼 가까운 관계인 경우도 있지만, 아주 실리적으로 관계를 맺는 약한 관계라고 할 수 있다. 미투데이 친구는 상호간에 관계를 맺지만, 트위터는 한쪽에서 일방적으로 팔로우하면 된다.(2tw 미투데이 트위터 차이점)2009-09-13 11:46:40
그래서 그런지 트위터 내에서는 하루에도 수많은 사람들이 팔로우를 했다가 얼마있다가 언팔로우를 했다가 하는 일이 비일비재하다. 그렇게 별 이유없이 팔로우는 하는 사람들은 대부분 자기를 팔로우하기를 바라는 마음에서 팔로우를 한다.(2tw 미투데이 트위터 차이점)2009-09-13 11:48:04
트위터 내에서는 팔로워의 수가 기본적인 영향력의 지수가 될 수 있고, 영향력이 높다는 얘기는 마케팅 효과가 크다는 얘기가 될 수 있다. 그래서 트위터 내에서는 매일 매일 자신의 팔로워 수를 높이려는 사람들이 무차별적으로 팔로우를 한다.(2tw 미투데이 트위터 차이점)2009-09-13 11:50:07
물론 기존에 이미 유명했던 사람들은 굳이 팔로우를 하지 않지만 유명하지 않았던 사람들이 자신의 영향력을 높이기 위해 그렇게 하고 있다는 것이다. 그렇게 되면 아마도 기업 마케팅 부서에서 연락을 해 올 가능성이 높을 것이기 때문이다.(2tw 미투데이 트위터 차이점)2009-09-13 11:52:39
이런 무차별적이고 실용적인 관계가 과연 요즘과 같은 주목경제에서 효과를 발휘할 수 있을지는 의문이다. 정보의 홍수 속에서 차라리 기존보다 가까운 지인들의 영향력이 커질 수 있는데, 약한 관계를 바탕으로 한 마케팅이 효과를 볼 수 있을지 의문이다.(2tw 미투데이 트위터 차이점)2009-09-13 11:54:46

이 글은 김윤수님의 2009년 9월 13일의 미투데이 내용입니다.

블로그 글들 옮깁니다.

김윤수 — Sun, 6 Sep 2009 18:00:01 +0900

안녕하세요. 제 블로그를 아껴주시는 독자여러분.

아주 오랫동안 블로그를 버려 두다 시피하여 이젠 많은 분들이 관심을 잊어 버렸을 것 같기도 합니다만, 그럼에도 불구하고 여전히 구독해지 않고 기다려 주신분들께 우선 감사의 말씀드립니다.

제 글의 성격상 블로그라는 미디어의 형식에 어울리지 않는 것 같아 앞으로는 개발 관련 글들은 블로그에 작성하지 않고 위키 서비스에 올릴 생각입니다. 위키 서비스를 검색하던 차에 wikidot.com 이라는 괜찮은 서비스를 찾아서 여기 있는 글들을 차츰 차츰 옮길 생각입니다. 물론 여기에도 그대로 놔두긴 하겠지만 글들을 검토하면서 좀 더 다듬고 하는 것은 위키에서만 하게 될 것 같습니다.

아직은 이제 막 싸이트를 개설하고 위키 문법 공부하고 있는 중이라 글을 본격적으로 옮기진 못했구요. 앞으로 짬 날때마다 옮길 생각입니다.

위키 싸이트는 전 세계의 좀 더 많은 분들 소통하기 위해 한글과 영문 두 언어로 작성할 생각입니다.

위키 사이트 주소는 http://opensw.wikidot.com 입니다. 많은 관심 부탁드립니다.

어느 정도 글들을 옮긴 이후에 다시 공지드리도록 하겠습니다.

C++ 이야기 서른번째: boost::shared_ptr performance

김윤수 — Sun, 28 Jun 2009 13:44:49 +0900

최근 제가 진행하던 프로젝트에서 boost::shared_ptr를 상당히 많이 사용해 왔었는데, 성능이 좋게 나오질 않아서 혹시나 해서 오늘 성능을 간단하게 측정해 봤더니 속도 차이가 상당히 많이 나는군요. 성능이 좀 느리겠거니 했는데 상상 이상이었습니다.(실은 이 문제 때문에 한바탕 홍역을 치뤘죠. ㅠ.ㅠ)

다음은 테스트 프로그램입니다.

$ cat shared.cpp
#include <iostream>
#include <boost/shared_ptr.hpp>

using namespace std;
using namespace boost;

class AClass
{
public:
 void Op() const
 {
 ++i;
 }

 int Get() const
 {
 return i;
 }

private:
 mutable int i;
};

#ifdef SHARED_PTR
void Foo(const shared_ptr<AClass>& p)
{
 p->Op();
}
#elif defined(SHARED_PTR_COPY)
void Foo(shared_ptr<AClass> p)
{
 p->Op();
}
#else
void Foo(AClass* p)
{
 p->Op();
}
#endif

int
main(int argc, char* argv[])
{
#if defined(SHARED_PTR) || defined(SHARED_PTR_COPY)
 shared_ptr<AClass> p(new AClass());
#else
 AClass* p = new AClass();
#endif

 int maxCnt = 1000000000;
 if (argc >= 2)
 maxCnt = atoi(argv[1]);

 for (int i = 0; i < maxCnt; ++i)
 {
 Foo(p);
 }

 cout << p->Get() << endl;

 return 0;
}

이 테스트 프로그램은 세 가지 경우를 테스트하기 위한 것입니다.

1. raw pointer를 사용하는 경우: SHARED_PTR 또는 SHARED_PTR_COPY 가 정의되지 않은 경우입니다.
2. shared_ptr을 사용하는 경우: SHARED_PTR 이 정의된 경우입니다. Foo()를 호출할 때, const shared_ptr reference를 넘기기 때문에 복사가 일어나질 않습니다.
3. shared_ptr을 쓰면서 복사를 하는 경우: SHARED_PTR_COPY가 정의된 경우입니다. Foo()를 호출할 때, shared_ptr 객체를 넘기기 때문에 복사가 한 번 발생하고 이때, shared_ptr의 복사 생성자가 수행되면서 내부적으로 reference count를 증가시키고, 다시 함수에서 리턴될 때, reference count를 감소시키게 됩니다. 그리고 reference count 증가 및 감소는 보통 atomic operation으로 수행되기 때문에 보통의 증가/감소보다는 속도가 느린 걸로 알고 있습니다.

이 세가지에 대해 컴파일러 최적화 옵션 및 BOOST 옵션을 약간 달리 하면서 실행을 해 보았습니다. 다음은 테스트를 위한 Makefile 입니다.

$ cat Makefile
all: shared1 shared2 shared3 shared_copy1 shared_copy2 shared_copy3 plain1 plain2 plain3

#CFLAGS=-pg -g
#LDFLAGS=-pg -g
# CASE #1
CFLAGS1=
# CASE #2
CFLAGS2=-O3
# CASE #3
CFLAGS3=-O3 -DBOOST_SP_DISABLE_THREADS
LDFLAGS=

shared1: shared1.o
 g++ $(LDFLAGS) -o shared1 shared1.o

shared_copy1: shared_copy1.o
 g++ $(LDFLAGS) -o shared_copy1 shared_copy1.o

plain1: plain1.o
 g++ $(LDFLAGS) -o plain1 plain1.o

shared1.o: shared.cpp
 g++ $(CFLAGS1) -c -o shared1.o -DSHARED_PTR shared.cpp

shared_copy1.o: shared.cpp
 g++ $(CFLAGS1) -c -o shared_copy1.o -DSHARED_PTR_COPY shared.cpp

plain1.o: shared.cpp
 g++ $(CFLAGS1) -c -o plain1.o -DPLAIN shared.cpp

shared2: shared2.o
 g++ $(LDFLAGS) -o shared2 shared2.o

shared_copy2: shared_copy2.o
 g++ $(LDFLAGS) -o shared_copy2 shared_copy2.o

plain2: plain2.o
 g++ $(LDFLAGS) -o plain2 plain2.o

shared2.o: shared.cpp
 g++ $(CFLAGS2) -c -o shared2.o -DSHARED_PTR shared.cpp

shared_copy2.o: shared.cpp
 g++ $(CFLAGS2) -c -o shared_copy2.o -DSHARED_PTR_COPY shared.cpp

plain2.o: shared.cpp
 g++ $(CFLAGS2) -c -o plain2.o -DPLAIN shared.cpp

shared3: shared3.o
 g++ $(LDFLAGS) -o shared3 shared3.o

shared_copy3: shared_copy3.o
 g++ $(LDFLAGS) -o shared_copy3 shared_copy3.o

plain3: plain3.o
 g++ $(LDFLAGS) -o plain3 plain3.o

shared3.o: shared.cpp
 g++ $(CFLAGS3) -c -o shared3.o -DSHARED_PTR shared.cpp

shared_copy3.o: shared.cpp
 g++ $(CFLAGS3) -c -o shared_copy3.o -DSHARED_PTR_COPY shared.cpp

plain3.o: shared.cpp
 g++ $(CFLAGS3) -c -o plain3.o -DPLAIN shared.cpp

test: test1 test2 test3

test1: shared1_test shared1_copy_test plain1_test

shared1_test: shared1
 time ./shared1 $(CNT)

shared1_copy_test: shared_copy1
 time ./shared_copy1 $(CNT)

plain1_test: plain1
 time ./plain1 $(CNT)

test2: shared2_test shared2_copy_test plain2_test

shared2_test: shared2
 time ./shared2 $(CNT)

shared2_copy_test: shared_copy2
 time ./shared_copy2 $(CNT)

plain2_test: plain2
 time ./plain2 $(CNT)

test3: shared3_test shared3_copy_test plain3_test

shared3_test: shared3
 time ./shared3 $(CNT)

shared3_copy_test: shared_copy3
 time ./shared_copy3 $(CNT)

plain3_test: plain3
 time ./plain3 $(CNT)

clean:
 rm -rf *.o *.dSYM shared1 shared2 shared3 shared_copy1 shared_copy2 shared_copy3 plain1 plain2 plain3 core* gmon.*

1. 테스트 케이스 1: 컴파일러 옵션으로 아무것도 주지 않을 경우 --> CFLGAS1 사용
2. 테스트 케이스 2: 컴파일러 옵션으로 -O3 를 준 경우 --> CFLAGS2 사용
3. 테스트 케이스 3: 컴파일러 옵션으로 -O3 -DBOOST_SP_DISABLE_THREADS 사용. BOOST_SP_DISABLE_THREADS를 켜면 reference count 값을 변경시킬 때, atomic operation을 사용하지 않게 됩니다.

이렇게 테스트 프로그램을 작성하고, 테스트를 해 봤더니 다음과 같은 결과가 나오더군요.

$ make
$ make test
time ./shared1 1000000000
1000000000
 15.66 real 15.52 user 0.04 sys
time ./shared_copy1 1000000000
1000000000
 93.33 real 92.58 user 0.24 sys
time ./plain1 1000000000
1000000000
 8.54 real 8.48 user 0.02 sys
time ./shared2 1000000000
1000000000
 2.81 real 2.79 user 0.00 sys
time ./shared_copy2 1000000000
1000000000
 37.86 real 37.62 user 0.08 sys
time ./plain2 1000000000
1000000000
 0.66 real 0.66 user 0.00 sys
time ./shared3 1000000000
1000000000
 2.84 real 2.79 user 0.00 sys
time ./shared_copy3 1000000000
1000000000
 5.74 real 5.70 user 0.01 sys
time ./plain3 1000000000
1000000000
 0.66 real 0.66 user 0.00 sys

(위 테스트는 looping overhead, function call overhead 를 정확히 측정하지 않았기 때문에 아주 정확한 수치라고는 주장할 수 없음을 미리 밝힙니다. 정확한 수치를 알아내기 위해서는 좀 더 잘 설계된 테스트 케이스를 사용해야 할 것입니다. 다만 위 테스트 결과를 사용하더라도 이 글에서 주장하고자 하는 바를 위한 충분한 근거가 되리라고 생각합니다.)

우선 테스트 케이스1와 테스트 케이스2, 테스트 케이스 3에서 공히 shared_copy > shared > plain 결과가 나온다는 걸 확인할 수 있습니다. BOOST_SP_DISABLE_THREADS 를 켜게 되면 shared_copy에만 영향을 미친다는 걸 알 수 있습니다. 이건 아까 말씀드린 대로 atomic operation이 disable되기 때문인 것으로 추측됩니다. 이상 결과로 보건대 shared_ptr을 쓰실 때는 다음과 같은 점에 유의하셔야 할 것 같습니다.

1. No free lunch. 좋은 게 있으면 그에 대한 비용이 있기 마련이라는 것이죠. shared_ptr는 일반 포인터에 비해 overhead가 있다는 점을 염두해 두셔야겠습니다.
2. 단순 접근하는 overhead도 2.81/0.66(테스트 케이스 2)으로 상당합니다.
3. 복사 생성자 overhead는 37.86/0.66(테스트 케이스 2)으로 더 크다는 것을 확인할 수 있습니다. BOOST_SP_DISABLE_THREADS를 켜더라도 5.74/0.66으로 여전히 크다는 것을 알 수 있습니다. 따라서 될 수 있으면 복사를 shared_ptr도 복사는 피하셔야 하겠습니다.

제가 테스트한 환경은 다음과 같습니다.

$ uname -a
Darwin MyMac.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
$ g++ --version
i686-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5564)

여러분 환경에서는 어떤 결과가 나오는지 실험해 보시고, 트랙백 한 번 남겨 주시면 감사하겠습니다. ^^

소스 코드 첨부합니다(looping overhead를 측정하기 위해 본문 소스에서 약간 더 수정했습니다).

shared.tar.gz

김윤수의 인터넷 오늘은 - 2009년 1월 22일

김윤수 — Fri, 23 Jan 2009 04:33:07 +0900

개발자를 위한 글꼴! 나눔고딕_코딩 글꼴 공개! 우왕 멋집니다. 감동입니다. 바로 다운로드 들어가야 함다.(네이버 폰트공개 나눔고딕코딩)2009-01-22 17:41:04

이 글은 김윤수님의 2009년 1월 22일의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2009년 1월 4일

김윤수 — Tue, 6 Jan 2009 04:34:55 +0900

I'm back!2009-01-04 01:08:35

이 글은 김윤수님의 2009년 1월 4일의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2008년 12월 24일

김윤수 — Thu, 25 Dec 2008 04:32:32 +0900

Merry Christmas & Happy New Year! 전 11일 장기 휴가 돌입합니다. 저 없는 동안 잘 지내세요~ 인터넷 접속 안하기 한 번 실천해 봐야겠습니다.(인터넷생활)2008-12-24 18:09:36

이 글은 김윤수님의 2008년 12월 24일의 미투데이 내용입니다.

C++이야기 스물아홉번째: Portable C++ Timer Class #2

김윤수 — Mon, 22 Dec 2008 22:35:29 +0900

If you are an English speaker, then follow this link.
C++ Tips 29th: Portable C++ Timer Class #2

이번에는 timer 관련 클래스들에 어떤 멤버 함수와 멤버 변수를 정의해야할지에 대해 자세히 알아보겠습니다. 사용자가 가장 많이 사용하게될 클래스는 TimerDriver일테니 이것부터 시작해 보도록 하겠습니다.

저번글에서 말씀드렸던 것처럼 TimerDriver는 등록된 타이머들이 정확한 시간에 expire되도록 해주는 클래스입니다. 이점을 고려하면 타이머 인스턴스들을 등록하고 등록해제하는 멤버 함수는 누가 봐도 필요할 것 같습니다.

class TimerDriver {
public:
TimerId RegisterTimer(const Timer& t);
void UnregisterTimer(TimerId tid);
};

이 인터페이스를 정의하고 나면 등록된 타이머 인스턴스들을 저장해 놓을 저장 공간이 필요하다는 걸 금방 알게 됩니다. 그럼 어떤 데이터 구조가 저장 공간으로 적당할까요? 가장 적당한 데이터 구조를 택하려면 아무래도 사용자가 TimerDriver를 사용하는 패턴을 먼저 알아야 할 것 같습니다.

지금까지 정의한 멤버 함수는 RegisterTimer(), UnregisterTimer() 두 개가 있고, 이 둘은 결국 삽입과 삭제에 해당합니다. 그리고 타이머 인스턴스들 하나 하나를 건드리면서 드라이브 할 수 있습니다. 그렇지만 사용자가 정렬된 타이머 리스트를 필요로 하거나, 타이머 인스턴스를 직접 접근하거나, 타이머 인스턴스를 상당히 빠르게 검색해야할 필요성은 없을 것입니다.

그래서 저는 std::list가 등록된 타이머 인스턴스 저장 데이터 구조로 가장 적당하다고 생각합니다.

#include <list>

class Timer;

class TimerDriver {
public:
TimerId RegisterTimer(const Timer& t);
void UnregisterTimer(TimerId tid);

private:
std::list<Timer> timer_list_;
};

다음으로 RegisterTimer() 와 UnregisterTimer()의 입력 인자와 리턴값에 대해 생각해 보겠습니다.

제가 RegisterTimer()의 리턴값과 UnregisterTimer()의 입력인자로 TimerId라는 타입을 도입했습니다. 'TimerId' 타입의 필요성은 분명해 보이는데... 어떤식으로 'TimerId' 타입을 정의해야할까요? TimerDriver가 내부적으로 식별자 풀(identifier pool)을 관리해야할까요 아니면 TimerId가 그냥 Timer*이면 될까요? 식별자 풀을 관리한다면 각 타이머 인스턴스에 할당된 식별자는 어디에 저장해야할까요? timer_list_는 list<Timer>라고 선언해도 무방할까요 아니면 다른 뭔가로 선언해야할까요? 예를 들어, list<Timer*>와 같이 말이죠. 우리가 결론에 도달할 때까지는 이런 수 많은 질문들이 머리속을 맴돌게 됩니다. 혼란 그 자체죠? 이런 간단한 클래스를 설계하는데도 말입니다.

그렇지만, 소프트웨어 개발자로서 선택에 대한 분명한 이유를 찾아가며 이런 혼란스러움을 해결해 가야 합니다. 삶이란 게 문제로 가득차 있고, 산다는 것 자체가 해답을 찾아가는 과정 아닐까요? 그러니 너무 괴로워하지 마시고 맘을 가다듬어 보시죠. 사실 이 모든 문제들이 서로 연결되어 있습니다. 한 문제에 대한 해결책을 찾게 되면... 짠! 하고 다른 모든 문제들에 대한 해결책도 찾을 수 있게 될테니까요.

그럼 문제점을 하나씩 해결해 보시죠. 숨을 기~~~~~~~~~~~~~피 들이 쉬시고~~~

TimerId! TimerDriver가 식별자 풀을 관리해야할까요? 가능한 해결책이죠. 사용자가 RegisterTimer()를 호출하여 타이머 인스턴스를 등록해달라고 하면 TimerDriver가 식별자 풀에서 할당되지 않은 ID를 새로 등록할 타이머 인스턴스에 할당할 수 있을 것입니다. 그리고, 나중에 UnregisterTimer()를 호출했을 때, 삭제하려면 할당된 그 ID를 어딘가에 저장해야 합니다.

그런데 저는 정말 식별자 풀을 관리하고 싶지는 않네요. 현재 요구사항에 비해 너무 복잡한 해결책이거든요. 저는 간단한 해결책을 훨씬 선호합니다. 그렇게 하면 코드량도 적어지고, 버그고 적어질 테니까요. 그래서 식별자 풀은 설계 대안에서 제외하기로 했습니다. 그럼 다른 대안이 있을까요? TimerId를 그냥 Timer*로 선언하면 어떨까요?

#include <list>

class Timer;
typedef Timer* TimerId;

class TimerDriver {
public:
TimerIdTimerId RegisterTimer(const Timer& t);
void UnregisterTimer(TimerId tid);

private:
std::list<Timer> timer_list_;
};

이렇게 하면 식별자 풀을 관리하지 않아도 되고, RegisterTimer() 는 리턴값으로 &t를 리턴하면 되니 구현이 간단해 질 것입니다. 그럼, 거의 완벽한 해결책을 찾은 거네요. 그죠? 워!워!워! 그렇게 쉽게 해결될 리가 있나요. 조금만 더 깊이 생각해 보시죠.

그냥 TimerId를 Timer*로 선언하게 되면 타이머 인스턴스의 내부 표현 방식을 사용자가 직접 다루게 되고, 결국 이것은 encapsulation rule을 위배하게 됩니다. 그렇게 할 경우, TimerDriver가 타이머 인스턴스 내부 표현 방식을 바꾸게 되면 TimerId가 Timer*라는 거를 가정하고 짠 사용자 코드는 다 작동하지 않게 될 것입니다. 그래서 저는 TimerId를 그냥 void*로 선언하려고 합니다. 그럼 사용자는 타미어 인스턴스 내부 표현 방식이 어떻게 되는지 전혀 알 수가 없겠지요.

#include <list>

class Timer;
typedef void* TimerId;

class TimerDriver {
public:
TimerId RegisterTimer(const Timer& t);
void UnregisterTimer(TimerId tid);

private:
std::list<Timer> timer_list_;
};

다음으로는 timer_list_ 멤버 변수에 대해 생각해 보겠습니다. 저번 글에서 밝혔다시피 저는 Timer에서 상속받은 PeriodicTimer와 OneShotTimer를 정의하려고 합니다. Timer에는 공통의 인터페이스만 정의하고 PeriodicTimer 와 OneShotTimer에서 그걸 구현하여 다형성을 보이게 하려는 것이지요. 그렇다면 timer_list_를 list<Timer*>로 선언해야 할 것입니다.

#include <list>

class Timer;
typedef void* TimerId;

class TimerDriver {
public:
TimerId RegisterTimer(const Timer& t);
void UnregisterTimer(TimerId tid);

private:
std::list<Timer*> timer_list_;
};

현재 TimerDriver 인터페이스에는 한 가지 멤버 함수가 빠진 것 같습니다. 보통 사용자는 먼저 타이머들을 등록한 후에 타이머들을 돌리기 시작하겠죠? 그래서 다음과 같이 Run() 멤버 함수를 추가했습니다.

#include <list>

class Timer;
typedef void* TimerId;

class TimerDriver {
public:
TimerIdTimerId RegisterTimer(const Timer& t);
void UnregisterTimer(TimerId tid);
void Run();

private:private:
std::list<Timer*> timer_list_;
};

이제, 이 정도면 TimerDriver의 인터페이스는 거의 완벽하다고 느껴지네요. 다음글에서 TimerDriver의 구현에 대해 다뤄보도록 하겠습니다.

김윤수의 인터넷 오늘은 - 2008년 12월 20일

김윤수 — Sun, 21 Dec 2008 05:18:08 +0900

영문 블로그 세번째 글: C++ Tips 29th: Portable C++ Timer Class #2, 지난 글을 안 보신 분은 먼저 읽어보시는 센스를 발휘해 주세요(블로그 영문)2008-12-20 22:20:11

이 글은 김윤수님의 2008년 12월 20일의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2008년 12월 18일

김윤수 — Fri, 19 Dec 2008 04:32:33 +0900

한 동안 블로그에 글 못 올릴 것 같습니다. 양해 바랍니다.(블로그 휴업)2008-12-18 22:33:52

이 글은 김윤수님의 2008년 12월 18일의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2008년 12월 9일

김윤수 — Tue, 9 Dec 2008 04:32:30 +0900

Measuring Parallel Performance: Optimizing a Concurrent Queue: 나중에 꼭 읽어 봐야 겠습니다.(인터넷오늘은 북마크 SW개발 hpc thread)2008-12-09 00:19:02

이 글은 김윤수님의 2008년 12월 9일의 미투데이 내용입니다.

C++이야기 스물아홉번째: Portable C++ Timer Class #1

김윤수 — Mon, 8 Dec 2008 22:37:17 +0900

If you are an English speaker, then follow this link.
C++ Tips 29th: Portable C++ Timer Class #1

우리네 생활이 온통 시간에 둘러쌓여 있듯이, 응용프로그램부터 펌웨어에 이르는 프로그램도 시간에 둘러쌓여 있지요. 예를 들자면, 달력 프로그램은 시간과 연관되어 있는 약속과 할일들을 처리하고, 검색 로봇은 주기적으로 페이지를 긁어 오고, 멀티미디어 재생기는 제 시간에 맞춰서 데이터 저장소로부터 열심히 데이터를 끌어 오고, TCP/IP 위에서 동작하는 통신 미들웨어는 데이터 교환이나 요청한 연산에 대해 타임아웃을 처리하고, 디바이스 드라이버는 주기적으로 디바이스에 상태 체크 요청을 보냅니다. 이렇게 시간은 워낙 근본적인 개념이라 아주 작은 프로그램을 개발하는 경우를 제외한다면 대부분 타임아웃이나 주기적인 이벤트를 처리할 수 있는 라이브러리가 필요하게 됩니다.

그래서 이번과 앞으로 몇 번에 걸쳐 boost 라이브러리를 활용하여 타임아웃이나 주기적인 이벤트를 처리할 수 있는 타이머 클래스를 구현하는 방법에 대해 얘기하려고 합니다.

타이머와 연관된 기본적인 개념을 먼저 한 번 생각해 보죠.

타이밍 이벤트는 주기적으로 발생하거나 딱 한 번만 발생한다.
타이밍 이벤트가 발생하면 특정 작업을 처리해야 한다.
정확한 시간에 타이밍 이벤트가 발생하도록 해주는 일종의 구동기가 존재한다.

저는 이 정도 개념이 우선 떠오르네요.

그럼 먼저 첫번째 개념에서 어떤 클래스를 정의해야 하는지부터 시작해 볼까요? 다음과 같이 enum 값들로 두 가지 타입을 다 지원하는 클래스 하나를 정의할 수도 있을 겁니다.

class Timer {
public:
typedef enum {
PERIODIC_TIMER,
ONE_SHOT_TIMER
} Type;

private:
Type m_type;
};

서로 다른 두 개념을 클래스 하나로 묶어 놓은 설계가 과연 좋은 설계일까요? 좀 더 주의깊게 생각해 보시죠. 이 설계대로 하면 생성자는 어떻게 작성해야 할까요?

#include <boost/date_time.hpp> // for time_duration

class Timer {
public:
typedef enum {
PERIODIC_TIMER,
ONE_SHOT_TIMER
} Type;

Timer(Type type, const boost::posix_time::time_duration& td);

private:
Type m_type;
};

'type' 인자의 의미는 분명하지만, 'td' 인자는 어떤 것을 뜻할까요? 보통 주기적인 이벤트는 주기(== 'td')라는 게 필요하고, 타임아웃 이벤트는 그 이벤트가 발생할 시간(== 현재 시간 + 'td')을 필요로 할테니... 'td' 인자가 뜻하는 바는 'type'에 따라 달라지겠죠? 그렇다면, Timer::Timer() 을 구현한 코드가 아무래도 다음 코드에서 보시는 것처럼 'type' 값에 의존적인 코드가 될 것 같군요.

Timer::Timer(Type type, const boost::posix_time::time_duration& td)
{
switch (type)
{
case PERIODIC_TIMER:
......
break;

case ONE_SHOT_TIMER:
......
break;

default:
break;
}
}

이렇게 되면 새로운 타입의 타이머를 추가할 때마다 이 생성자를 수정해야할 필요가 있다는 건 쉽게 눈치 채실 수 있으시겠죠? 상당히 심각한 유지보수 문제네요. 이것 말고도 다른 문제점들도 있습니다. 세번째 개념에서 드라이버 클래스를 정의할 필요성이 있다는 걸 알 수 있습니다.

class TimerDriver { ...... };

TimerDriver가 서로 다른 타입의 타이머 인스턴스들을 제대로 처리하려면 타이머의 타입을 알아야할 것입니다. 그러니 TimerDriver의 구동 멤버 함수는 당연히 타이머의 타입 정보를 필요로 하게 됩니다. 생각이 여기에 이르면 새로운 타입의 타이머를 추가할 때마다 TimerDriver의 구동 멤버 함수도 수정해야 한다는 걸 알 수 있게 됩니다.

마지막 문제점으로 주기적인 이벤트는 주기를 저장해야 할테고, 타임아웃 이벤트는 이벤트가 발생해야할 시간을 저장해야 한다는 점이 떠오르네요. 이걸 저장하기 위해 하나의 클래스에 두 개의 멤버 변수를 정의한다면 타이머 인스턴스의 타입에 따라서 낭비되는 공간이 생길 것입니다.

이상의 문제점을 고려해 보건데, 주기적인 이벤트와 타임아웃 이벤트를 위해 따로 클래스를 정의하는 게 더 좋은 설계라는 게 명백해 보입니다. 그렇지만 한편으로는 TimerDriver는 여전히 이 클래스들을 일관되게 처리할 필요가 있을 것입니다. 따라서 저는 공통의 부모 클래스로 Timer를 두고, 파생 클래스로 PeriodicTimer와 OneShotTimer를 두려고 합니다.

class Timer { ...... };

class PeriodicTimer : public Timer { ...... };

class OneShotTimer : public Timer { ...... };

그럼 이제 Timer, PeriodicTimer, OneShotTimer 각각 클래스에는 어떤 것들을 정의해야 할까요? 이 문제는 다음 글에서 알아보도록 하겠습니다. ^^

김윤수의 인터넷 오늘은 - 2008년 12월 7일

김윤수 — Mon, 8 Dec 2008 04:32:09 +0900

C++ Tips 29th: Portable C++ Timer Class #1: 영어 블로그 두번째 글입니다. Wordpress가 너무 꼬져서 textcube.com 으로 옮겨 봤습니다. 일단 tistory랑 비슷해서 편하네요. 이번에는 영문으로 먼저 작성했습니다.(블로그 영문)2008-12-07 22:47:34

이 글은 김윤수님의 2008년 12월 7일의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2008년 12월 3일

김윤수 — Wed, 3 Dec 2008 04:32:31 +0900

샴페인-박준규-흑인영어: ㅋㅋㅋ 배꼽 빠져(me2gag)2008-12-02 15:35:41
이 기사 말이 되는 듯… 뭐 꼭 근거가 있는 건 아니고 그냥 느낌이 그렇다는 얘기(투자생활 그나저나 예상대로 얼마전 반등은 단기 반등이었을 뿐 언론들은 제발 호들갑 떨지 말아라)2008-12-03 00:35:04
제가 요즘 관심을 두는 주식들: POSCO, 메가스터디, 서울반도체, LG전자 등 입니다.(투자생활)2008-12-03 00:47:23

이 글은 김윤수님의 2008년 12월 2일에서 2008년 12월 3일까지의 미투데이 내용입니다.

티스토리 달력 공모전 응모

김윤수 — Wed, 3 Dec 2008 01:36:57 +0900

음... 올해 있었던 추억을 담아 응모해 봅니다.

여름에 아이들과 함께 동네 야외 수영장 갔을 때 찍었던 사진입니다. 오빠와 동생이 함께 노는 모습이 보기 좋아서 선정해 봤습니다. 7월 사진으로 적당할 것 같네요.

위 사진은 대관령 양떼 목장에 갔을 때 찍은 하늘 사진입니다. 날씨가 아주 맑은 날이어서 하늘이 너무 멋있어 보이더군요. 9월 사진으로 적당할 것 같네요.

그리고 하늘의 구름과 땅의 양떼가 어우러진 이 사진도 좋은 것 같습니다. 마찬가지로 9월이 적당할 것 같네요.

김윤수의 인터넷 오늘은 - 2008년 11월 30일

김윤수 — Mon, 1 Dec 2008 04:32:18 +0900

C++ Tips 28th: Applying STL Algorithms to a Map Container: It's not that easy to translate a post in Korean to English. (블로그 영문 첫글) 2008-11-30 20:22:15

이 글은 김윤수님의 2008년 11월 30일의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2008년 11월 28일

김윤수 — Fri, 28 Nov 2008 04:32:27 +0900

스마트폰이 노트북 밀어낸다: 스마트폰 세상이 오고 있군요. 무선 인터넷 세상도 같이 와야 할텐데 말이죠. (인터넷오늘은 북마크 스마트폰) 2008-11-27 23:15:03
맥용 와이브로 USB 모뎀이 있었군요 (인터넷오늘은 북마크 와이브로 맥) 2008-11-27 23:28:43
다음, 부동산정보도 네이버 제쳤다: 다음이 만년 2등에서 벗어날 수 있을까요? 지금은 너무 많이 차이가 나서… 다음이 좀 더 잘해준다면 선의의 경쟁이 될 수 있을텐데요 (인터넷오늘은 북마크 다음 전 네이버와 다음의 주주예요 ^^) 2008-11-27 23:38:11
상장사 3분기 누적수출 224조, 25.5%↑: 환율의 영향이 크긴 컷었나 보군요. 예상되는 바였습니다. 좀 더 지나면 환율 영향은 사라지고 글로벌 경기 침체 영향으로 수출이 줄어들지 않을까 걱정되네요. (인터넷오늘은 북마크 수출 경제) 2008-11-27 23:43:17
[내일의전략]산타랠리 기대해도 좋다: 단기 랠리에 그칠 것 같은데, 언론사들 항상 김치국부터 마신다 (인터넷오늘은 북마크 경제 주식시장) 2008-11-27 23:51:20
삼성서버엔 삼성SSD가 없다: 이 기사는 삼성전자 내부 사정을 모르는 기자가 작성한 듯. 작년에도 삼성전자 반도체 사업부가 자사 휴대폰 사업부보다 애플에 더 싼 값에 플래스 메모리를 공급했다는 걸 아시는지 모르시는지… (인터넷오늘은 뉴스 삼성전자) 2008-11-28 00:00:18
'마이너리티 리포트' 컴퓨터 기술, 현실화된다: 이거 제품으로 나오면 꼭 사고 싶네요. 2~3년내 상품화 목표래요. (인터넷오늘은 북마크 뉴스 HCI) 2008-11-28 00:08:49
한국판 '구글맵스' 흥행 성공할까?: 이런 소식을 이제서야 접하다니… 쩝~ 옛날에 구글이 한국 관련 데이터가 너무 부족하다고 1년전에 글을 썼었는데… 이제서야 데이터를 확보한건지 아니면 규제문제 때문이었는지… 아무튼 환영~ (인터넷오늘은 북마크 뉴스 구글맵스 한국) 2008-11-28 00:17:07
DB도 토종 오픈소스 가능한가?…큐브리드의 대담한 도전: 다른 건 몰라도 License는 정말 잘 정했다. GPL과 BSD의 절묘한 조합이라고 해야겠네. 기술과 법을 다 잘 이해해야만 정할 수 있는 정책이다. (인터넷오늘은 북마크 뉴스 오픈소스) 2008-11-28 00:31:33

이 글은 김윤수님의 2008년 11월 27일에서 2008년 11월 28일까지의 미투데이 내용입니다.

김윤수의 인터넷 오늘은 - 2008년 11월 27일

김윤수 — Thu, 27 Nov 2008 04:33:04 +0900

Naver Developer Center 오픈했었군요. 이런 때 늦은 소식 접수라니… 쩝~ (네이버 개발자 센터 미투뉴스) 2008-11-27 02:00:41
제로보드 XE: 나도 내 홈페이지 함 만들어 볼까… (인터넷생활 제로보드XE) 2008-11-27 02:32:26
우선 맥북에 제로보드랑 맥용 APM 패키지 설치해서 써 본 후에 호스팅으로 옮겨 가야지 (인터넷생활 맥용APM) 2008-11-27 02:34:19

이 글은 김윤수님의 2008년 11월 27일의 미투데이 내용입니다.

다음 모바일 서비스 블로거 간담회에 다녀오다

김윤수 — Wed, 26 Nov 2008 07:00:00 +0900

11월 26일 저녁 7시 다음 양재 사옥 3층에서 개최된 "다음 모바일 서비스 블로거 간담회"에 다녀왔습니다. 저로서는 아주 오랜만의 서울 나들이였습니다. 워낙 회사일도 바쁘고, 집안 가장으로서 해야할 일도 많고 해도 시간 내기가 여간 어렵지 않더군요. 그런 만큼 이번에는 머리도 식힐 겸 요즘 모바일 인터넷이 어떻게 돌아가는지도 알아볼 겸 해서 기대하는 마음으로 참석했습니다.

행사장에 늦게 도착하지 않기 위해 급하게 나섰던지 너무 일찍 도착해서 주변에서 살짝 방황 좀 하다가 6:30분 쯤에 행사장에 들어갔습니다. 지동아빠님(첨엔 몰랐는데 나중에 알았다는...)께서 식사는 6:50분에 제공되고, 행사는 식사후에 시작하게 된다고 하시더군요. 그래서 잠시 기다리는 동안 인터넷에 접속하려고 했으나... 헉! 무선랜이 안되더군요. ㅠ.ㅠ 순간 당황해서 패닉 상태에 빠질 뻔 했습니다. 혼미해지던 정신을 부여잡고 뭘해야하나 고민하던 중 고이고이님께서 아는체를 하셔서 겨우 정신 수습했습니다. 이 자리를 빌어서 고이고이님께 감사 ^^

식사할 때는 같은 테이블에 빨판님, 함장님, 고이고이님, 미소챨스님과 합석했습니다.

행사 첫 오프닝은 oojoo라는 id로도 유명하신 김지현님(회사내 직책은 본부장이신가 보더군요)께서 하셨고, 기업이 블로그를 운영하는 것은 공개할 수 있는 정보와 공개해서는 안되는 정보 사이를 잘 조절해야 해서 어려움이 많지만 서비스를 혼자 만드는 거이 아니라 사용자와 같이 만든다고 생각하기 때문에 외부와 소통하기 위해 블로그를 운영하고 있고, 이번 간담회도 같은 맥락에서 1차로 준비한 서비스에 대한 의견을 듣고 싶어서 개최한 것이라고 배경 설명을 해 주셨습니다.

그리고 이어서 지도 위에서 무궁 무진한 서비스가 펼쳐질 수 있다고 생각하고, 모바일 서비스의 킬러앱을 맵으로 보고 있다고 설명하시면서, 다음이 맵에 어떤 투자를 하고 있는지 실제 시연 장면을 통해 보여주셨습니다. 이 대목에서 기밀사항이라 사진 촬영은 금지! 저야 카메라가 없으니 말하지 않아도 찍을 수 없는 상황이었죠 ^^ 언뜻 보기에 맵 해상도가 상당히 고화질로 보이더군요. 스트릿뷰, 스카이뷰도 지원되고 요즘은 대부분 포털들이 고화질 맵 서비스를 제공하고 있어서 크게 달라 보이진 않았습니다. (여기서 아마 다음의 고민이 시작되겠지요? 어떻게 타사와 차별화 시킬 것인가?)

이런 맵을 별도의 어플리케이션을 통해 모바일 폰에 올리려나 보더군요. 이런 맵 위에서 지명 검색, UCC 검색, 드라마 촬영지 검색, 경로 검색(버스, 지하철, 버스&지하철, 최적 경로, 최단 경로) 등도 가능하다고 합니다. 나중에 지동아빠님(모바일 애플리케이션 담당이시랍니다)께서 직접 테이블에 오셔서 시연도 해주셨습니다. 내년 쯤에서(내년 초라고 했는지 말이라고 했는지 기억이 나질 않네요 ㅠ.ㅠ) 모바일 맵 서비스가 가능하다고 하니 아직은 많이 기다려야 할 듯 합니다.

이어서 풀브라우징 서비스와 모바일 애플리케이션에 대한 설명이 이어졌습니다. 풀브라우징 서비스 기획 담당하신 분은 금동우님이고 모바일 애플리케이션을 담당하신 분은 지동아빠님이시더군요. 전 두 분 다 초면이었습니다.

풀브라우징 서비스는 현재로서는 아르고폰에 맞춰서 개발이 되었다고 하더군요. 아무리 모바일 폰이 UI가 좋다고 하더라도 단말 자체에 익숙해지는 것이 힘들다고 판단하여 "가독성", "편리한 스크롤", "가로/세로 대응", "PC화면 전환" 에 주안점을 두고 서비스를 개발했다고 합니다.

가독성이야 화면이 많이 좁으니 폰트 크기를 적당히 맞춰져야 하므로 당연히 신경써야 하는 속성이었을 것 같구요(제 생각입니다), 편리한 스크롤은 아직 국내에 출시된 스마트폰들이 아이폰만큼 부드러운 터치감과 스크롤을 제공해 주지 못하기 때문에 서비스 제공자 입장에서 그런 것들 보완할 수 있는 방안을 고민했다고 하더군요.
가로/세로 대응도 기존 왑 사용자의 경우 세로로 정보가 나열되는데 이미 익숙해져 있기 때문에 다른 모바일 서비스(모바일 파란을 예로 들었습니다)처럼 가로만 브라우징되도록 하는 것 좋지 않은 것이라 판단되어 가로/세로 모두 대응되도록 개발했다고 합니다.
마지막으로 "PC화면 전환"은 모바일 서비스에 최적화된 형태로 모든 정보를 변환하기는 상당히 시일이 소요될 것으로 예상되므로 더 상세한 정보를 얻고자 하는 사용자의 요구사항을 만족시키기 위해 "PC화면 전환"이라는 버튼을 매 페이지에 두었다고 합니다.

현재 풀브라우징 외 모바일 애플리케이션으로 준비한 것은 TV팟과 지도 애플리케이션이라고 하더군요. TV팟 애플리케이션은 직접 사용도 해 봤는데 상당히 빠르게 응답하는 걸 봐서는 1차 버전임에도 상당히 최적화에 신경을 쓴 흔적이 보였습니다. 다만 시연시 사용했던 iPod Touch의 문제인지 아니면 동영상 자체 품질의 문제인지 화면에 잔상이 많이 남더군요. TV팟은 Hot, Best, Themes, Movies, Games 탭을 제공하고 있고, 아직 검색 기능은 제공하지 않습니다. 퓨처워커님께서 왜 검색기능을 제공하지 않느냐는 질문을 주셨고 이에 대해 검색 기능을 제공하려면 모든 동영상을 TV팟 모바일 애플리케이션에 볼 수 있도록 인코딩을 해 놓아야 하는데, 아직 그렇게는 준비가 안되어 있다고 답변을 하시더군요. ROI때문에라도 모든 동영상은 모바일에 맞게 인코딩할 수는 없기 때문에 사용자들의 강력한 요구가 있을때에나 검색 기능을 추가할 수 있을 것이라며 검색 기능을 더 강력히 요청하라고 부추기시더군요. ^^

저는 개인적으로 맵 정보를 바탕으로 풍부한 지역 정보 서비스가 제공되면 좋겠습니다. 그런 지역 정보 서비스가 미투데이 같은 마이크로 블로그 SNS와 연동이 되면 더욱 좋을 것 같구요. 정보가 맵에 집중되기도 하지만 각자의 마이크로 블로그에 분산되기도 하면서 그 안에서 관계를 맺는 것도 자연스러운 그런 서비스가 제공되면 좋겠습니다. 이런 서비스를 어떻게 구체적인 모습으로 만들지는 별 생각이 떠오르지 않지만요.

이후 각 테이블에 아이팟 터치와 아르고폰을 나눠 주셔서 직접 조작하면서 풀브라우징 서비스와 TV팟 서비스를 사용해 볼 수 있었습니다. 풀브라우징 서비스 화면은 폰카로는 화질이 도저히 나오질 않아서 제 맥북의 내장 카메라로 어떻게 억지로 찍었는데 화질이 그닥 좋지 않습니다. OTL 그래도 글만 있으면 너무 심심할까봐 그림 첨부합니다. ^^

풀브라우징 초기화면은 이글을 보시면 더 정확히 알 수 있습니다.

저는 개인적으로 체험시간에 금동우님께 다음과 같은 질문을 했습니다.

질문: 어떤 서비스가 모바일 풀브라우징 서비스가 되게 할 계획인지요?
답변: 현재 개발된 풀브라우징 서비스는 모두 소위 "노가다" 방식으로 개발한 것들이다. 이런 방법외에 구글과 같은 완전 자동 트랜스 코딩 방식, 오리가미 같은 준 트랜스코딩 방식이 있으나, 기술적인 한계 또는 비용 문제로 인해 보류했다. 그렇지만 소위 "노가다" 방식으로는 오래가지 못할 것이고 향후 보류했던 방식을 다시 시도해볼 수 있을 것이다.
다시질문: (질문의 의도를 파악하지 못하신 것 같아서) 그렇다고 하더라도 나중에 발표를 하실 때, 우리 서비스 중에 이런 이런 서비스들은 모바일 서비스가 제공된다라고 발표를 하실 거 아녜요? 어떤 서비스들을 계획하고 계신가요?
답변: 우선 메일, 검색, 뉴스는 1차로 개발되었고, 향후 증권, 티스토리, 부동산, 맵서비스도 준비중입니다.
질문: 모바일 폰에는 자신의 개인적인 정보도 많이 담기는데 모바일 폰 싱크 서비스는 계획하지 않고 계신가요?
답변: 모바일 폰 싱크 서비스도 준비 중이다.

저는 솔직히 모바일 폰 싱크 서비스가 나오기를 바라는 사람이라서요. 제일 마지막 답변을 듣고 싶어서 저런 장황한 대화를 나눴었지요. ^^

이외에 나중에 토론 시간에 BM에 대한 질문, 모바일 데이터 요금제 대책에 대한 질문, 모바일 사용자들의 사용 패턴 조사 여부에 대한 질문, 모바일 서비스에서 포털의 역할이 무엇이라고 생각하는지에 대한 질문 등 매우 까다로운 질문들이 오고 갔습니다. 이런 질문에 대한 답변은 참석하신 분들이 어딘가에 따로 포스팅하실 것을 기대하면서 저는 이만 줄여야 겠습니다. 벌써 새벽 1시가 넘어가네요.

까다로운 질문으로 공격을 받으시던 김지현님께서 오히려 참석한 블로거들에게 질문을 하나 던지시더군요.

"이렇게 모바일 서비스를 하는 게 어려운데 다음이 뛰어든게 답일까요?"
"저희들은 뛰어든게 답이라고 생각해서 이렇게 열심히 하고 있습니다. 모바일 서비스는 누구 하나의 노력으로 되지 않고 업계가 함께 노력해야 한다고 생각해서 타사와 협력해서 시장의 파이를 키우려고 노력중입니다. 앞으로 다음의 노력을 주목해 주십시오"

라는 말로 마무리를 지으시더군요.

다음의 모바일 서비스 기대하고 있겠습니다. 쾌적하고, 즐겁고, 유용한 무선 인터넷을 만드시는데 노력해 주시기를 당부 드립니다. ^^

(To 다음 모바일 TFT 관계자 분들께: 이 정도면 밥값은 한 건가요? 그리고 다음에는 무선랜 좀 되게 해주세요. ^^)

C++이야기 스물여덟번째: map container에 STL algorithm적용하기

김윤수 — Mon, 24 Nov 2008 07:00:00 +0900

If you are more familiar with English, then follow this link.
C++ Tips 28th: Applying STL Algorithms to a Map Container

여러분은 map container에 STL algorithm을 적용해 보신 적 있으신가요? map은 key=value pair를 저장해 두는 container라서 다른 container에 비해 STL algorithm을 적용하기가 쉽지 않더군요. map은 key 보다는 value에 관심이 있는 container라서 STL algorithm을 수행할 때도 key-value pair에 대해서 특정 작업을 수행하기 보다는 value에 대해서 어떤 작업을 수행하기를 원하는 경우가 많은데, STL algorithm 및 표준 함수 객체들이 map에 맞춰져 작성되어 있질 않아서 이걸 하기가 쉽지 않더군요. 그래서 별도의 Adaptor class를 정의하는 경우가 많습니다. 한 번 예를 들어 보겠습니다. 다음과 같은 클래스가 정의되어 있다고 가정해 보시죠.

class Elem {
public:
 Elem() : m_name(), m_val() {}

 Elem(const string& name, int val) : m_name(name), m_val(val) {}

 const string& GetName() const
 {
 return m_name;
 }

 int GetValue() const
 {
 return m_val;
 }

 void SetValue(int val)
 {
 m_val = val;
 }

 void Print() const
 {
 cout << GetName() << "'s value ==> " << GetValue() << endl;
 }

private:
 string m_name;
 int m_val;
};

이 Elem 를 담는 map을 다음과 같이 정의해서 몇 개를 집어 넣어 보도록 하겠습니다.

// 앞으로 설명에서 나오는 m container는 이걸 뜻합니다
map<string, Elem> m;

m["1"] = Elem("1", 1);
m["2"] = Elem("2", 2);
m["3"] = Elem("3", 3);
m["4"] = Elem("4", 4);
m["5"] = Elem("5", 5);

이 map에 담긴 모든 Elem 들의 값을 얻어내고 싶은 경우를 생각해 보겠습니다. 그렇다면 다음과 같이 for 루프를 작성할 수 있습니다.

// 먼저 값을 담을 vector를 정의합니다
vector<int> vi(m.size());
// 그리고 for 루프를 돌립니다
for (map<string, Elem>::iterator it = m.begin(); it != m.end(); ++it)
{
vi.push_back(it->second.GetValue());
}

소위 STL 좀 쓴다하는 여러분이 위와 같은 코드를 그냥 둘리 만무합니다. 어떻게 하면 저 for 루프를 STL 알고리즘으로 바꿀 수 없을까를 고민하시겠지요. 그리고 transform을 쓰면 되겠구나라고 맘을 먹습니다.

// 먼저 algorithm header 파일을 포함해야죠
#include <algorithm>
#include <functional>
......

vector<int> vi(m.size());
// m 에 들어가 있는 것은 포인터가 아니라 값이 들어가 있으므로 mem_fun이 아닌
// mem_fun_ref를 사용하여 멤버 함수 객체를 만듭니다
transform(m.begin(), m.end(), vi.begin(), mem_fun_ref(&Elem::GetValue));

이 코드가 문제 없이 컴파일 돼서 실행될까요? 안타깝게도 그렇지 않습니다. transform이 기대하는 건 Elem 객체가 아닌 pair<string, Elem> 객체이기 때문에 컴파일 에러가 발생하지요. 여기서 잠깐 transform 알고리즘 속을 들여다 보면 왜 컴파일 에러가 발생하는지 좀 저 정확히 알 수 있습니다.

// 설명을 편하게 하기 위해 핵심 부분만 발췌했습니다.
template<typename _InputIterator, typename _OutputIterator,
 typename _UnaryOperation>
_OutputIterator
transform(_InputIterator __first, _InputIterator __last,
 _OutputIterator __result, _UnaryOperation __unary_op)
{
for ( ; __first != __last; ++__first, ++__result)
 *__result = __unary_op(*__first);
return __result;
}

파랗게 표시한 부분을 보시면 first iterator를 dereference하고 있습니다. first iterator를 dereference하면 당연히 Elem 객체가 아닌 pair<string, Elem> 객체가 되는 것이지요.

그렇다면 뭔가 Elem의 GetValue()를 호출해 줄 Adaptor가 필요하겠군요. 다음과 같이 Adaptor를 정의하면 될까요?

struct ElemGetValueAdaptor {
int operator()(const pair<string, Elem>& p) {
 return p.second.GetValue();
}
};

이런 클래스를 정의하고 나서 transform을 다음과 같이 호출하면 되겠습니다.

transform(m.begin(), m.end(), vi.begin(), ElemGetValueAdaptor());

뭐 여기까지는 할만합니다. 여기에 덧붙여 이번에는 m container에 있는 Elem 객체의 값을 출력해야 해서 Elem::Print()를 호출해야 하게 됐습니다. 그래서 Adaptor를 하나 더 정의합니다.

struct ElemPrintAdaptor {
void operator()(const pair<string, Elem>& p) {
 p.second.Print();
}
};

그리고 나서 for_each를 다음과 같이 호출하면 되겠지요.

for_each(m.begin(), m.end(), vi.begin(), ElemPrintAdaptor());

이렇게 매번 멤버 함수를 호출하려고 할 때마다 Adaptor를 정의하면 얼마 있지 않아 코드에 온갖 Adaptor들이 난무하게 될 것입니다. 그리고, Adaptor들의 모양새라는 것도 거의 반복되는 코드이구요. 반복되는 코드를 보다보면 당연히 어떻게 하면 반복되는 코드를 없앨까를 생각하게 되죠. 그래서 이걸 템플릿으로 할 수 없을까를 생각하시게 될 것입니다.

template <typename R>
struct ElemAdaptor {
 // GetValue()와 Print()가 모두 상수 멤버 함수라서 끝에 const를 붙임
 typedef R (Elem::*MemFunType)() const;

 ElemAdaptor(MemFunType mf) : m_mf(mf) {}

 R operator()(const pair<string, Elem>& p) {
 return (p.second.*m_mf)();
 }

private:
 MemFunType m_mf;
};

그리고, transform과 for_each는 다음과 같이 호출하면 되겠지요.

transform(m.begin(), m.end(), vi2.begin(), ElemAdaptor<int>(&Elem::GetValue));
for_each(m.begin(), m.end(), ElemAdaptor<void>(&Elem::Print));

이렇게 하면 GetValue()와 Print()는 커버할 수 있겠지만 SetValue(int)는 처리할 수 없습니다. Argument가 있기 때문입니다. 게다가 상수 멤버 함수도 아니구요. 이런 다양한 멤버함수를 처리할 수 있는 일반적인 멤버 함수 Adaptor를 만드는 건 보통 어려운 일이 아닙니다.
만약 m container가 Elem 객체의 container가 아니라 Elem* 의 container 거나 Elem&의 container이면 상황이 더 복잡해 질 것입니다. const나 volatile이 붙을 수도 있는 거구요. 이 모든 것들을 처리할 수 있는 일반적인 Adaptor를 만드는 건 무척이나 어려운 일이지요.

이럴 때 써먹을 수 있는 게 boost::bind 와 placeholder입니다. boost::bind는 앞에서 제가 언급한 다양한 차이들을 모두 극복하고 하나의 함수로 모든 것을 수용할 수 있습니다. 위에서 제가 직접 만들었던 Adaptor를 쓰지 않고 bind를 쓰는 방식으로 바꾼다면 다음과 같이 작성하시면 됩니다.

// boost::bind
#include <boost/bind.hpp>

using namespace std;
using namespace boost;
......
transform(
 m.begin(), m.end(), vi2.begin(),
 bind(&Elem::GetValue, bind(&map<string, Elem>::value_type::second, _1))
);
for_each(
 m.begin(), m.end(),
 bind(&Elem::Print, bind(&map<string, Elem>::value_type::second, _1))
);

inner bind() 즉 bind(&map<string, Elem>::value_type::second, _1) 이렇게 된 부분을 먼저 설명드리면, _1은 placeholder라고 하여 _1이라고 표시된 부분에 인자를 받을 수 있는 함수자(functor)를 만들어주게 됩니다. transform과 for_each는 각각 pair<string, Elem>를 입력인자로 하여 해당 알고리즘의 마지막 인자로 주어진 함수자를 호출할 것이므로 _1 placeholder를 써서 인자를 받을 수 있도록 한 것입니다. 그리고 inner bind의 첫번째 인자로 멤버 변수에 대한 포인터를 주게 되면, 두번째 인자로 주어진 객체(이 경우 _1)에 대해 멤버로 참조할 수 있도록 만들어 줍니다. &map<string, Elem>::value_type::second 라고 한 부분은 당연히 map 에서 Elem 객체를 참조할 수 있도록 하기 위한 것입니다. 이 설명을 종합하자면 inner bind는 pair<string, Elem> 객체에서 Elem 객체를 선택하는 부분이라고 생각하시면 되겠습니다. 즉, ElemAdaptor::operator(p) 의 구현에서 p.second 에 해당하는 부분이라고 생각하시면 되겠습니다.

이걸 바탕으로 outer bind를 좀 더 쉽게 표현해 보자면 bind(Elem_mem_func_ptr, Elem_obj), 이런 의미가 되겠습니다. bind는 첫번째 인자가 멤버 포인터(멤버 변수에 대한 포인터이건 멤버 함수에 대한 포인터이건 상관 없이)이면 두번째 인자를 객체(또는 객체 참조자 또는 객체 포인터)로 해석하고 해당 객체에 대해 멤버 변수나 멤버 함수를 접근 또는 호출해주는 함수자를 만들어 줍니다. 그래서 결국은 (Elem_obj.*Elem_mem_func_ptr)() 또는 (Elem_obj->*Elem_mem_func_ptr)() 의 효과가 있게 됩니다.

bind는 꼭 인자가 없는 멤버 함수에만 쓸 수 있는 건 아닙니다. 실은 인자를 9개까지 지원해 줍니다. 예를 들어, m container를 각 Elem 객체에 대해 Elem::SetValue(10) 를 호출하고 싶다면 다음과 같이 하시면 됩니다.

for_each(
m.begin(), m.end(),
bind(&Elem::SetValue, bind(&map<string, Elem>::value_type::second, _1), 10)
);

bind의 세번째 인자로 SetValue()의 인자값을 bind 하면 되는 것이지요.

정리하자면 map container에 STL algorithm을 적용하고 싶을 때는 boost::bind와 placeholder를 다음과 같은 패턴으로 사용하시면 되겠습니다.

#include <boost/bind.hpp>

using namespace boost;

bind(&ClassName::mem_func_name, bind(&map<keytype,
 ClassName>::value_type::second, _1), arg1, arg2, ..., arg9)

그럼 여러분의 C++ 프로그래밍에 조금이라도 도움이 되길 바라면서 이만 줄여야겠네요.

김윤수의 인터넷 오늘은 - 2008년 11월 21일

김윤수 — Sat, 22 Nov 2008 04:33:01 +0900

F# Primer: F# 소개 기사네요. 이제는 함수형 언어에도 관심을 많이 가져 봐야 겠어요 (SW개발 프로그래밍언어 fsharp F#) 2008-11-21 22:57:30

이 글은 김윤수님의 2008년 11월 21일의 미투데이 내용입니다.