h2. Library TR
p. 추가되는 Library facility들에 대한 자세한 글을 쓰다보니, 너무 오래걸려서, 일단 먼저 각각에 대한 간단한 설명을 정리하려고 한다. 이 글은 JTC1.22.19768 ISO/IEC TR 19768 – C++ Library Extensions[1] 문서와 CUJ 2004년 9월호에 Herb Sutter가 기고한 Trip Report: March 2004[2]에 나와있는 정보를 기초로 하여 작성된 것이다.
h3. Smart pointers (shared_ptr, weak_ptr)
p. 일반적으로 Smart pointer는 동적으로 할당된 object에 대한 pointer를 안전하게 다루게 해줄 수 있도록 해준다. shared_ptr은 이미 표준에 포함되어있는, auto_ptr의 치명적인 결함(특히, container에 넣을 수 없는 점)을 보완하는, reference counting 방식의 smart pointer이다. weak_ptr은, shared_ptr에서 raw한 pointer를 빼내는 대신 dangling pointer 문제를 안전하게 처리해주는 pointer의 역할을 대신해준다.
h3. Tuple types (tuple)
p. pair가 2개의 type을 저장하는 generic container라면, tuple은 n개로 확장한 형태이다.
h3. Generalized function pointers (function)
p. function pointer의 역할을 하는 세가지 C++ 요소, 즉 function pointer, member function pointer, functor들에 대한 facade로 똑같이 취급할 수 있도록 해준다.
h3. Nearly complete C99 library compatibility
p. 기본적으로 모든 C99와 C++03의 차이를 반영하는 것을 목적으로 하고 있다.
h3. Hash-based container (unordered_set, unordered_map, unordered_multiset unordered_multimap)
p. 많은 C++ 사용자들이 필요로 해왔을 Hash table을 기초로 하는 container가 추가된다.
h3. Type traits (alignment_of, has_nothrow_copy, has_virtual_destructor, is_base_of, is_const, is_convertible, ..)
p. type에 대한 정보, type 간의 관계에 대한 정보들을 얻어낼 수 있는 traits들을 제공함으로써, concept check나 meta programming에 도움을 줄 수 있다.
h3. Regular expressions (basic_regex)
p. 말그대로 regular expression. ‘basic_’이란 prefix에서 짐작할 수 있듯이, string 만을 위한 것은 아니라는 것을 알 수 있다.
h3. Random-number generation(random_device, poisson_distribution)
p. C library 함수들에 비해 어떤 장점이 있는지는 좀 더 살펴봐야할 듯 하다.
h3. Mathematical special functions
p. 여러가지 수학 함수들. 본인은 잘 모르기 때문에, 관심 있는 사람은 직접 draft[1]를 참고하시길.
h3. 아직 draft에는 없지만 Trip Report[2]에서 언급하고 있는 facility들.
h4. [“N1548, A Proposal to Add a Fixed Size Array Wrapper to the Standard Library Technical Support”:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html]
p. 기존의 array를 container 형태로 구현한 것. initializer 문법을 지원하면서도, 다른 container와 유사한 interface를 가지므로, 사용성을 크게 해치지 않으면서 자연스럽게 C++ Standard Library에(특히, algorithm) 어울릴 수 있다.
h4. [“N1550, New Iterator Concepts”:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1477.html]
p. 기존의 iterator가 access와 positioning을 동시에 취급하는 개념이라서 좀 더 넓은 범위의 iterator 개념을 표현할 수 없었던 문제가 있었다. 이를 해결하기 위해 두 개념을 분리하는 iterator 구조에 대한 제안.
h4. [“N1530, Iterator Facade and Adaptor”:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1530.html]
p. 서로 다른 종류의 iterator들을 wrap하는 iterator facade와 다른 방식으로 동작하는 iterator로 변용해주는 adaptor를 정의한다. 위의 ‘New Iterator Concept’에 의존한다.
h3. Conclusion
p. 언제 쓰여질 지 모를 다음 part에서는 Evolution WG에서 언급되는 C++ language 자체에 대한 변경 사항들을 정리해보겠다. 그 다음부터는 Library TR Draft를 중심으로 흥미가 가는 내용에 대해서 자세히 써보려고 생각 중..
fn1. [“http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1540.pdf”:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1540.pdf]
fn2. [“http://www.cuj.com/”:http://www.cuj.com/]

웹서버를 운영하면서 보안상 몇가지 statistics가 필요해서, Log file analyzer를 좀 찾아보았다.

• Awstats (http://awstats.sourceforge.net/)
• Webalizer (http://www.mrunix.net/webalizer/)
• Analog (http://www.analog.cx/)

screenshot으로 판단해볼 때, 개인적으로 사용하기에는 Awstats가 제일 나아보여서 그걸로 설치했다. 설치과정은 거의 수동에 가깝지만, 별 어려움 없이 무난했음. 몇몇 통계 수치를 (e.g. 국가별 통계) 산출하는 데에 Perl module이 필요한 듯 보인다.

이 외에 혹시 유명한 Log file analyzer가 있다면 알려주시길. (for the completeness!)

executable에 symbol A가 있고 shared library에서 symbol A를 사용하고, executable이 shared library를 dynamic loading (with dlopen()) 할 경우, executable의 symbol을 shared library에게 노출(export)해주려면 GNU ld의 –export-dynamic이라는 option을 사용하여야 한다. -rdynamic이 같은 역할을 하는 옵션이지만, manual에 나오지 않는 걸로 봐서 deprecated된 것으로 보인다.

BSD 계열의 native linker쪽에서 -rdynamic을 사용하던가?

다음 URL을 참고할 것.

http://www.cygwin.com/ml/cygwin/2001-03/msg01895.html
http://www.mail-archive.com/perl5-build@perl.org/msg00108.html

bq. SOA is a means to an end, it’s not an end in and of itself. It’s a great way, but not the only way, to enable the flow of information across disparate systems. It’s also a great way, but not the only way, to enable more flexibility in the way we build systems. A key success metric for companies today is time-to-market. However, time-to-market usually refers to the time it takes to develop something the first time. In the future, I think the time-to-adapt will become even more important than time-to-market. Flexibility – you are gonna need it.
p. from [“http://devhawk.net/PermaLink.aspx?guid=31accdb2-2491-47f2-8d8d-37c343ee9cc8”:http://devhawk.net/PermaLink.aspx?guid=31accdb2-2491-47f2-8d8d-37c343ee9cc8]

h2. Library TR
p. JTC1.22.19768 ISO/IEC TR 19768 – C++ Library Extensions[1] 문서에 나와있는 정보를 기초로 하여 작성된 것이다.
h3. Smart pointers (shared_ptr, weak_ptr)
p. ‘Smart pointer’란 동적으로 할당된 object에 대한 pointer를 나타내는 object이다. C++ 프로그래머들이 흔히 가장 쉽게 떠올릴 수 있는 smart pointer의 기능이 바로 scope를 벗어나면 할당된 object를 해제해주는 것이고, 이는 바로, 이미 C++ standard에 포함되어있는 auto_ptr의 역할이다. 하지만, 이 auto_ptr는 semantic상 실용적으로 쓰이기에 치명적인 제약사항들이 있다.
p. 일반적으로 auto_ptr에 pointer를 대입하고 scope가 끝나서 해제되는 것까지는 별로 문제가 없다. 하지만, auto_ptr이 다른 곳으로 이동할 때 문제가 된다. auto_ptr이 복사가 될 때, auto_ptr은 복사가 되는 곳 (destination)으로 pointer를 옮기고 원본(source)에서는 pointer의 흔적을 지워버린다. 다시 말하면, auto_ptr의 복사가 일어날 때, 실제로는 pointer의 이동이 일어나는 것이다. (이를 ownership의 이동이라고 표현한다) 이러한 copy 방식을 destructive copy라고 한다. auto_ptr의 destructive copy 방식은 source를 가진 쪽이 더이상 pointer를 사용할 필요가 없을 때, 즉 소유권(ownership)을 이전하고 싶을 때, 매우 유용하다. 예를 들면, dynamic하게 할당된 object를 caller쪽으로 return하고 싶은 경우가 있을 수 있다.
bq.. class SomeProtocol
{
public:
typedef std::auto_ptr ResponsePtr;
ResponsePtr getResponse();
};
void foo()
{
SomeProtocol::ResponsePtr respPtr = getResponse();
…
// scope가 끝나면 respPtr내에 들어있는 Response 객체는 자동으로 해제된다.
}
p. 다른 한가지 예는, 다른 함수로 pointer를 전달하고 자신은 더이상 사용하고 싶지 않은 경우이다.
bq.. void foo(SomeProtocol::ResponsePtr ptr)
{
….
// scope가 끝나면 respPtr내에 들어있는 Response 객체는 자동으로 해제된다.
}
void bar()
{
SomeProtocol::ResponsePtr respPtr = someProtocol.getResponse();
….
foo(respPtr);
….
// foo에 respPtr을 복사하고 나면, respPtr은 더이상 Response 객체를 가지지 않는다.
}
p. 반면, 이러한 destructive copy policy 때문에 auto_ptr을 C++ standard library의 container에서 사용할 수 없게 된다. container들은 destructive copy semantic을 지원하지 않기 때문이다. (Assignable concept는 copy ctor 또는 assignment의 post condition으로, source와 target이 equivalent할 것을 명시하고 있다.) container에 auto_ptr을 넣는 데까지는 문제가 없다고 쳐보자. 하지만, container에서 값을 참조하기만 해도, container 내의 auto_ptr은 빈 auto_ptr이 되어버리는 것을 쉽게 상상할 수 있다. 물론 이렇게 하기 전에도 내부 동작에 의해 망가져버릴 가능성은 얼마든지 있다.
p. 따라서, scope을 벗어났을 때, 자동으로 해제되면서도, (auto_ptr처럼), container에서도 사용할 수 있는 무언가가 당연히 표준에 있어야할 것 같다. 이것이 바로 TR1에 추가될 shared_ptr이다. (현재의 표준에는 없다는 얘기)
p. shared_ptr은 말그대로 shared ownership의 방식으로 동작하는 smart pointer이다. 즉, copy가 될 때, ownership을 공유한다는 것이다. 이러한 방식을 구현하는 가장 간단한 방식이 바로 reference counting이고, TR1 draft를 에서 counter(use_count())를 explicit하게 표현하는 것을 보면, reference counting을 하는 smart pointer라고 봐도 거의 무방할 듯 하다. 그리고, shared_ptr은 CopyConstructible, Assignable, LessThanComparable 이므로, 모든 표준 container에 들어갈 수 있다.
p. shared_ptr로 공유되는 pointer를 꺼내서 사용하고 싶은 경우도 당연히 존재하기 때문에, weak_ptr을 제공한다. weak_ptr은 말그대로 weak reference를 의미하는 것이고 따라서 무효화(nullify)될 수 있는 pointer라고 보면 된다. 단순히 pointer value를 꺼내서 사용할 경우에는 (shared_ptr이 모두 사라졌을 때) dangling pointer 문제가 발생할 수 있으나, weak_ptr은 무효화여부를 체크할 수 있기 때문에, dangling pointer 문제는 발생하지 않도록 보장해주는 역할을 한다고 볼 수 있다.
p. shared_ptr와 weak_ptr은 MT safety에 대해서 별로 신경을 쓰지 않는 것 같은데, 만약에 이것이 사실이라면 과연 shared_ptr은 MT app에서는 무용지물이 되는 것이 아닐까 약간 걱정이 된다. 그렇다고 해서, shared_ptr의 구현상에서 무조건 MT safety를 보장해주는 것은 또 performance overhead를 발생시킬 수도 있는 일이고 말이다.
p. 이러한 문제를 그나마 깔끔하게 해결하고 있는 쪽이, policy-based design으로 ownership 정책, MT 지원 여부 등을 policy로 분리한 Loki[2]의 design이 아닐까 한다.
p. 관심이 있는 사람들은 다음 링크를 참조할 것.
* [“http://www.cuj.com/documents/s=7980/cujcexp2008sutter/”:http://www.cuj.com/documents/s=7980/cujcexp2008sutter/]
h3. Tuple types (tuple)
p. CS를 전공한 사람이라면 discrete mathematics에서 tuple을 배웠을 것이다. tuple은 여러개의 object를 묶어서 표현할 수 있는 일종의 container이다.
p. 현재의 표준에는 pair가 있어서 한 쌍의 object를 generic하게 표현할 수 있다. 하지만, n개의 묶음을 표현하기 위해서는 pair의 pair와 같은 꽁수를 쓰거나, 그 때마다 struct를 정의하거나 해온 것이 사실이다.
p. pair의 pair와 같은 방법을 사용할 경우에는 코드가 매우 깔끔하지 못하게 된다는 것을 쉽게 알 수 있다.
bq.. typedef std::pair > MyTableEntry;
typedef std::vector MyTable;
MyTable myTable;
myTable.push_back(make_pair(1, make_pair(“foo”, true)));
MyTableEntry foundEntry = myTable.find(…);
std::cout << "(" << foundEntry.first << ", " << foundEntry.second.first << "," << foundEntry.second.second << ")" << std::endl; p. 3개짜리 tuple이었기에 망정이지 5개 정도 된다면 그야말로 악몽이다. 복잡한 코드는 버그의 원인이 된다. p. struct를 정의하는 방법은 코드의 복잡성은 전혀 없다. struct는 단순한 object의 모음을 표현하는 데에 있어서, 어떤 개발자에게는 불필요한 기능들을 포함하고 있을 수도 있다. 그 외에도 struct는 tuple이 제공하는 여러 기능 (operator<(), make_tuple(), operator<<(ostream, ...))을 가지고 있지 않으므로 불편할 수 있다. 개인적으로는 struct type을 정의하는 순간부터 새로운 object (그것도 어설픈) 가 탄생하는 것 같아서 여러 struct들이 난무하는 상황은 꺼려지기도 한다. (C에서와는 완전히 다른 얘기다.) p. 다음 tuple의 template parameter를 보면, 더욱 확실한 감이 올 것이다. 단지 pair의 확장판이라고 봐도 거의 무방하다. bq. template class tuple;
p. template parameter list를 보면 …가 있어서 어떤 사람들은 의아해하겠지만, 이것은 새로 추가된 C++ 문법 같은 것이 아니다. 단순히, 구현에 따라 M개까지의 tuple을 지원하도록 하는 것을 의미한다. 당황스럽게도, 이것의 가장 단순한 구현 (boost의 구현)은 3개짜리 tuple, 4개짜리 tuple, …, M개짜리 tuple을 각각 정의하는 것이다. 이러한 제약이 없는 tuple을 만들 수 없으냐고 한다면, 만들 수 있다. 역시 Loki[2]를 보면 Type들의 list를 표현하는 장치를 구현하고 있는데, 이를 이용하여, 제약없는 tuple을 만들 수 있다. 하지만, 실제로 100개짜리 tuple을 쓰는 개발자는 거의 없다고 봐도 무방하므로, tr1::tuple의 접근도 acceptable하리라고 본다.
p. 관심이 있는 사람들은 다음 링크를 참조할 것.
* [“http://www.cuj.com/documents/s=8250/cujcexp2106sutter/”:http://www.cuj.com/documents/s=8250/cujcexp2106sutter/]
h3. Generalized function pointers (function)
p. 관심이 있는 사람들은 다음 링크를 참조할 것.
* [“http://www.cuj.com/documents/s=8464/cujcexp0308sutter/”:http://www.cuj.com/documents/s=8464/cujcexp0308sutter/]
h3. Nearly complete C99 library compatibility
fn1. [“http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1540.pdf”:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1540.pdf]
fn2. Modern C++ Design의 저자인 Andrei Alexandrecu가 만든 C++ library이다. [“http://sourceforge.net/projects/loki-lib/”:http://sourceforge.net/projects/loki-lib/]

요즘 개인적으로 개발하고 있는 프로그램들.

MovableTypeWriter
http://www.lastmind.net/tWiki/bin/view/Main/MovableTypeWriter

MovableType(이하 MT)은 자체적인 웹상의 posting interface를 가지고 있으나, html을 직접 다루어야 한다. Microsoft Internet Explorer를 사용하는 환경에서는 mshtml을 사용할 수 있고, visual editing 능력을 활용할 수 있다. MovableTypeWriter는 mshtml을 활용하여 MT에 posting을 좀 더 쉽고 유연한 인터페이스로 만들어주기 위한 application이다. 기능이 많이 필요한 것이 아니라, 완전히 사용성의 문제를 해결하기 위한 프로그램이라서 시간과 고민, 그리고 번뜩이는 아이디어가 많이 필요한 프로그램이다.

아직은, 초보적인 mshtml을 활용한 visual/code editing을 지원하고 있고, mshtml의 기능들도 아직 다 활용하지 못하고 있다. 조금씩 시간나는대로 추가해나갈 예정.

Visual Studio 2003/C#을 이용하여 개발하고 있고, 사용하기 위해서는 CLR이 필요하다.

아직 기본적인 기능 구현이 마무리 되지 않았기 때문에, code도 binary도 open 하지 않은 상태. (9월 말 정도면 되지 않을까?) Screenshot은 Wiki page에서 볼 수 있다.

IRCJukeOn
http://www.lastmind.net/tWiki/bin/view/Main/IRCJukeOn

현재 JukeOn에서 플레이 중인 곡목을 얻어오기 위한 mIRC(잘 알려진 Windows 기반의 IRC client) plugin이다. 기능은 구현된 상태이지만, 간단한 몇가지 문제들을 귀찮아서 해결하지 않고 있다.

WebRSSAggregator
http://www.lastmind.net/tWiki/bin/view/Main/WebRSSAggregator

웹기반의 RSS reader이다. Outlook plugin 형태의 RSS reader인 intravnews를 사용하고 있었으나, 집과 회사간의 정보 sync 문제(esp. 읽었는 지 여부, flag)가 발생해서 개발하게 되었다. 사실, 지금은 VPN으로 Outlook을 읽는데 별 어려움이 없기 때문에, 이 이유는 좀 약해졌지만, 개인적으로 필요로 하는 몇가지 기능들을 추가적으로 만들어볼 생각이다. 예를 들면, 나는 MSDN blog의 RSS를 구독하고 있는데, 워낙 많은 사람들의 blog들을 모아놓은 RSS feed라서 상당히 내용이 많다. 이 때, content/history 기반으로 적절히 분류하거나 ranking을 부여함으로써, 내가 보고 싶지 않은 내용들을 보는 시간을 절약할 수 있을 것이다.

ruby를 사용한 CGI application의 형태로 개발 중이다. RDoc은 여기에서 볼 수 있다.

지금은 기본적인 기능만 구현되어있는 상태이고, 결과물은 여기에서 볼 수 있다. 다음 iteration에서는 IFMS-based feed retrieval, Web interface 다듬기, 사용자 기반 읽기 여부 flag 정도를 구현해 볼 생각.

“‘Planning’ as the term is commonly understood is actually incompatible with an entrepreneurial society and economy….innovation , almost by definition, has to be decentralized, ad hoc, autonomous, specific and microeconomic.”

excerpt from http://www.agilemanagement.net/Articles/Weblog/DruckeronAdaptivevs.Plan-.html

Drucker가 1985년에 그의 책인 ‘Innovation and Entrepreneurship’에서 얘기한 것. 여기서 말하는 entrepreneurial sociery and economy는 현재의 사회와 경제, 즉, 지식 근로자 사회/경제를 얘기하는 거라고 봐도 무방할 듯 하다. 지식 사회에서는 decentralized, ad hoc, autonomous, specific, microeconomic한 innovation을 해야한다는 것이다. XP나 FDD 등과 같은 Agile(Light-weight) Software Development가 바로 이러한 철학을 가지고 있지 않은가!

TechEd 2004 등록일이 9월 10일까지니, 관심 있는 사람들은 등록할 것.
http://www.teched2004.co.kr/index.html

12일의 아키텍쳐 트랙이랑, 13일의 개발 플랫폼, 게임 개발자 플랫폼 트랙 정도가 눈에 띄이는군.