다다

이 프로그램을 기술한 언어를 "원시 언어" 라 합니다.

번역되어 출력되는 프로그램을 "목적 프로그램" 이라 하고, 

이 프로그램을 기술한 언어를 "목적 언어" 라 합니다.

출력하여 주는 언어처리기입니다. 기계어로 번역이 쉽게 이루어질 수 있으면서 

시행 시간을 중시하는 경우에 사용합니다.

인터프리터는 원시 언어로 작성된 명령문들을 한 번에 한 줄씩 번역하고 실행하는 프로그램입니다.

프로그램이 짧고 복잡하지 않고, 대화형 프로그램에서 많이 사용됩니다.

컴파일러는 번역, 인터프리터는 통역이라고 이해하면 쉽습니다.

컴파일러와 인터프리터의 차이점을 위 표에 간단하게 정리해보았습니다.

 컴파일러는 컴파일 과정이 복잡하고 그 시간이 많이 걸리게 되는데, 한 번 컴파일 하면 그대로 사용이 가능합니다.

전체 실행 시간 면에서 매우 효율적이며, 매번 번역할 필요가 없다는 것이 장점입니다.

하지만 한 줄의 입력 시 때로는 프로그램이 몇 백 개의 기계어로 번역되기 때문에 큰 기억용량을 요구하게 됩니다.

특히 입출력 명령은 입출력 형식을 위한 코드 외에 기계 상태 파악코드로 인해 큰 기억 장치가 요구됩니다.

인터프리터는 프로그램이 될 때까지 원시 언어의 형태를 유지하기 때문에 기억 장소가 추가로 필요하지 않습니다.

하지만 원시프로그램을 직접 실행하기 때문에 이 실행에 필요한 소프트웨어가 항상 기계 안에 상주하면서

원시 프로그램의 명령들을 받아서 처리하게 됩니다. 반복하여 실행하는 경우에는 그 때마다 원시 프로그램을

해석하여 처리하기 때문에 많은 시간이 걸리기도 합니다.

컴파일러는 실행 시간의 효율을 중하는 프로그래밍 언어에서, 

인터프리터는 사용자의 융통성을 중시하는 프로그래밍 언어에서 주로 사용됩니다.

이번에는 explicit 키워드에 대해 얘기해 보려고 합니다.

최근에 C++ 를 배우신 분들은 모르시겠지만 explicit 키워드는 C++의 첫번째 표준안인 98년 9월 1일 버전에 처음으로 도입된 키워드입니다. Bjarne Stroustrup 이 처음에 C++ 를 창시할 때는 없었다는 거죠. 그럼 왜 98년 C++ 표준안을 출판할 때는 explicit 라는 키워드를 넣었을까요 ? 이런 의문을 제기하지 않고 왜 그런지를 모른다면 C++의 참맛을 안다고 할 수 없겠죠.

결 론부터 말씀드린다면 explicit 키워드는 C 나 C++ 의 공통 특징 중의 하나인 암시적 형변환의 특성때문에 프로그래머가 예상치 못하는 형변환이 일어남으로 인해 정말 발견하기 어려운 버그가 생기는 걸 방지하기 위해서 도입된 키워드입니다.

결론은 그렇다 치는데, 도대체 어떤 버그이길래 그렇게 발견하기 어려운 버그일까요 ? 역시 백마디 말보다 하나의 예가 이해를 돕는데는 제격이므로 예를 들어 한 단계씩 차분히 설명해 보도록 하겠습니다.

일 단, 여러분이 Stack 이라는 클래스를 설계하려고 한다고 해 보죠. 제일 먼저 있어야 할 것은 Stack 객체를 생성하는 생성자가 있어야 할 것입니다. 우선 생각할 수 있는 생성자로는 n 개의 요소까지 가질 수 있는 Stack 을 생성하는 걸 생각해 볼 수 있을 것입니다. 다른 생성자로는 다른 Stack 을 복사해서 생성하는 것, 다른 배열을 복사해서 생성하는 것, 다른 vector 를 복사해서 생성하는 것 등을 생각할 수 있을 것입니다. 이런 생성자를 갖는 Stack 은 다음과 같이 작성할 수 있겠네요.

// 저번에 썼던 코드입니다.
template <typename T>
struct Print {
  void operator() (T v) {
    cout << v << " ";
  }
};
 
class Stack {
private:
  vector<int> _data;
  int _pos;
 
public:
  const static int MIN_ELEM = 10;
 
  // 최대 n 개 요소를 가질 수 있는 Stack 생성자
  // 기본값을 지정해 봤습니다.
  Stack(int n = MIN_ELEM): _data(n), _pos(0) {
    cout << "Stack(int) called" << endl;
  }
 
  // 다른 Stack 을 복사해서 생성하는 복사 생성자
  Stack(const Stack& other): _data(other._data), _pos(other._pos) {
    cout << "Stack(const Stack&) called" << endl;
  }
 
  // 다른 배열을 복사해서 생성하는 생성자
  Stack(int arr[], int n): _data(arr, arr+n), _pos(n) {
    cout << "Stack(int[], int) called" << endl;
  }
 
  // 다른 vector 를 복사해서 생성하는 생성자
  Stack(vector<int> v): _data(v), _pos(v.size()) {
    cout << "Stack(vector<int>) called" << endl;
  }
 
  // 그냥 어떻게 작동하는지 확인하기 위한 디버깅용 멤버 함수
  void printAll() {
    for_each (_data.begin(), _data.end(), Print<int>());
    cout << endl;
  }
};

다음 코드를 수행하면 어떤 결과가 벌어질까요 ? 여러분의 예상과 맞아 떨어지는지 한 번 보시기 바랍니다.

01: int
02: main(void)
03: {
04:   Stack s1;
05:   s1.printAll();
06:   Stack s2(20);
07:   s2.printAll();
08:   Stack s3(s2);
09:
10:   vector<int> v(10, 3);
11:   for_each(v.begin(), v.end(), Print<int>());
12:   cout << endl;
13:
14:   Stack s4(v);
15:   Stack s5 = v;
16:   s1 = v;                 // 이게 어떤 효과를 일으킬까요 ?
17:   s2 = 10;                // 버그 아닌가요 ? 좀 이상하지 않나요 ?
18:
19:   s1.printAll();          // 뭐가 찍힐까요 ?
20:   s2.printAll();          // 뭐가 찍힐까요 ?
21: }

위 코드가 컴파일될까요 ? 특히 17 line은 컴파일이 안될 것 같지 않으세요 ? stack 에 정수값을 할당한다는 게 전혀 말이 안되니 당연히 컴파일 안되어야 정상이겠죠. 자 한 번 컴파일해 볼까요 ? 어! 이게 어떻게 된 거죠 ? 아무런 에러 없이 컴파일이 되네요. 17 line 도 에러 없이 컴파일이 됩니다. 이게 어떻게 된 조화일까요 ? 컴파일러가 왜 이걸 정상적인 코드로 인식하고 컴파일을 했는지를 알려면 우리의 입장이 아니라 컴파일러의 입장에서 생각해 봐야 할 겁니다. 이른바 역지사지 해 보는 것이죠.

17 line 을 만나면 컴파일러는 어떻게 할까요 ? 컴파일러가 하는 일은 자신이 알고 있는 모든 지식을 동원해서 코드를 컴파일 해내는 것입니다. 먼저 s2 에 정수값을 할당할 수 있는 할당 연산자가 있는지 볼 것입니다. 어! 그런데 Stack 클래스 정의를 봤더니 아무리 눈씻고 찾아 봐도 없네요. 프로그래머가 정의한 할당 연산자가 없다면, 컴파일러가 생성한 복사 할당 연산자가 있을 것입니다. 자기가 생성한 복사 할당 연산자를 쓰려고 했더니, 이번에는 10 이라는 정수값이 복사 할당 연산자의 인자와 호환이 되질 않네요. 그렇다고 우리의 C++ 컴파일러는 그냥 컴파일을 포기하고 항복할 녀석이 아니죠. 이번에는 혹시 정수를 복사 할당 연산자의 인자(const Stack& 일 겁니다)로 변환할 수 있는지를 볼 겁니다. 여기에서 C++ 컴파일러는 인자가 하나인 생성자를 암시적 형변환하는데 사용한다는 것을 기억해 보세요. 죽 뒤져 보았더니 Stack(int) 가 눈에 띄네요. 그래서 결국 Stack(10) 을 호출해서 10개의 요소를 갖는 Stack 을 생성하고 그걸 복사 할당 연산자를 이용해서 s2 에 할당하게 됩니다. 이제 그 짧은 코드 안에서 어떤 일이 일어나는지 이해가 되시나요 ?

제가 쓰고 있는 컴파일러(Microsoft Visual C++ 2005)에서 컴파일 후 실행해 봤더니 다음과 같은 결과가 나옵니다.

01: Stack(int) called                         // 04 line 출력
02: 0 0 0 0 0 0 0 0 0 0                       // 05 line 출력
03: Stack(int) called                         // 06 line 출력
04: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   // 07 line 출력
05: Stack(const Stack&) called                // 08 line 출력
06: 3 3 3 3 3 3 3 3 3 3                       // 10 line 출력
07: Stack(vector<int>) called                 // 14 line 출력
08: Stack(vector<int>) called                 // 15 line 출력
09: Stack(vector<int>) called                 // 16 line 출력
10: Stack(int) called                         // 17 line 출력
11: 3 3 3 3 3 3 3 3 3 3                       // 19 line 출력
12: 0 0 0 0 0 0 0 0 0 0                       // 20 line 출력

09 ~ 12번째 라인 결과가 좀 의아하지 않나요 ? 왜 이런 결과가 나올까요 ? 눈치 빠른 분들 벌써 회심의 미소를 짓고 계시는 군요. 예, 그렇습니다. 아까 컴파일러 입장에서 살펴 본대로 C++ 의 암시적 형변환 규칙에 따르면 클래스의 생성자 중에 인자가 하나인 생성자들은 프로그래머의 의도와는 전혀 상관없이 컴파일러에 의해 암시적 형변환에 동원되도록 되어 있어서 s1 = v, s2 = 10 이라는 코드를 만나면 각각 Stack(vector<int>), Stack(int) 를 호출하여 임시 객체를 생성하고, 그 임시 객체를 가지고 복사 할당 연산자를 호출하게 됩니다(위 코드 예에서는 컴파일러에 의해 자동 생성된 할당 연산자가 호출되겠죠. 클래스 정의에서 할당 연산자를 여러분 나름대로 정의한 후, cout 으로 뭔가를 출력하게 되면 할당 연산자가 호출되는 것을 확인하실 수 있을 겁니다). 그러고 나면 s1 은 v vector의 내용으로 Stack 을 채우게 될 것이고, s2는 10개의 int 요소로 채우게 될 것입니다. 그래서 결과적으로 09 ~ 12번째같은 결과가 나오는 것이지요. s1 = v 에 대해 Stack(vector<int>) 를 호출하는 건 그래도 어느 정도 말이 된다고 하지만 s2 = 10 에 대해 Stack(int) 를 호출하는 건 좀 오버아닌가요 ? 도대체 Stack 객체에 10을 할당한다는 게 말이 되느냔 말입니다.

C++ 컴파일러는 참 잘난체 하는 데는 이골이 났나 봅니다. 프로그래머가 특별히 정의하지 않더라도 기본 복사 생성자, 복사 할당자를 생성해 버리고, 그것도 모자라 인자가 하나인 생성자를 암시적 형변환하는데 지 맘대로 써 버린다니… 그런데 나름 C++ 컴파일러도 말 못할 고민이 있다고 하네요. C++ 본래 태생이 그래서 그렇답니다. 맘에 안든다고 버릴 수도 없고, 그냥 우리가 적응해서 살아야 되지 않겠습니까 ?

아무리 적응하려고 한다지만 s2 = 10 을 만났을 때 Stack(int) 를 호출하는 건 프로그래머 입장에서는 참 예상하기 힘든 일입니다. 그래서 이런 예상치 못한 수행이 일어나면 프로그래머는 그런 버그를 정말 찾기 힘들게 됩니다. 실제로 이런 일들이 프로젝트 수행 도중 종종 일어나고, 이 버그는 찾기도 정말 힘듭니다. 그러니 아예 이런 일은 피해가는 게 상책이지요. 피해가는 방법이야 s2 = 10 과 같은 코드를 작성하지 않도록 Coding Guideline 에 넣어 두고, Code Review 도 하고 그런 방법도 있겠지만 좀 더 좋은 방법은 아예 s2 = 10 과 같은 코드를 만나면 컴파일시에 에러가 발생해 버린다면 더 좋을 것입니다(항상 기억하세요! 에러는 빨리 발견할 수록 수정하는데 드는 비용이 작다).

그래서, explicit 키워드가 C++의 첫번째 표준안에 새로 도입됐던 것입니다. explicit 키워드는 인자가 하나인 생성자가 암시적 형변환에 쓰이지 않도록 해줍니다. 암시적 형변환에 쓰이면 컴파일 에러가 발생하게 됩니다. 위에 정의한 Stack 정의에서 다음 부분을 수정하신 후에 main()함수를 다시 컴파일해 보시기 바랍니다.

  // 최대 n 개 요소를 가질 수 있는 Stack 생성자
  // 기본값을 지정해 봤습니다.
  explicit Stack(int n = MIN_ELEM): _data(n), _pos(0) {
    cout << "Stack(int) called" << endl;
  }

제가 쓰는 컴파일러에서는 다음과 같은 에러가 발생하네요.

error C2679: binary '=' : no operator found which takes a right-hand operand of type 'int' (or there is no acceptable conversion)

정확히 의도한 바와 같이 컴파일 에러가 발생하네요.

이 상에서 밝힌 바와 같이 explicit 키워드는 C++ 의 특징 중에 하나인 암시적 형변환 때문에 발생할 수 있는 문제의 소지를 미리 예방하는데 유용한 키워드입니다. 그러니, 클래스의 생성자를 설계할 때, 인자가 하나만 있는 생성자에 대해서는 암시적 형변환이 발생할 때 어떤일이 벌어질지를 생각해 보고, 암시적 형변환이 말이 안되는 의미를 갖게 될 경우 explicit 라는 키워드를 꼭 붙이시기 바랍니다. 아니면 거꾸로 생성자에 대해 일단은 무조건 explicit 키워드를 붙였다가 컴파일할 때 암시적 형변환이 허용되지 않아서 너무 불편하다 싶으면 그때가서 빼는 것도 방법입니다. explicit 키워드를 쓴 경우에는 다음과 같이 코드를 작성하시면 암시적 형변환과 같은 의미를 갖는 코드를 작성하실 수 있습니다.

s1 = Stack(v);
s2 = Stack(10);

마지막으로 다음을 기억하신다면 C++의 암시적 형변환 때문에 버그 찾느라 헤메는 일은 없을 것입니다.

dynamic-link library(DLL)은 응용프로그램이 실행중에 로드하고 호출할 수 있는 공유된 코드와 데이터로 정의할 수 있습니다. 전형적인 DLL은 응용프로그램을 위해 루틴들을 노출(=Export)시키며, 그 내부(즉, DLL)에서 사용할(internal use) 루틴도 역시 포함되어 있습니다. 이러한 기술은 여러 응용프로그램에서 공통 기능으로 공유할 수 있게 라이브러리 형태로 재사용 가능하게 하여 필요시 로드를 할 수 있도록 해줍니다. DLL 사용의 장점은 코드가 차지하는 공간(code footprint)을 줄이고, 단일 복사본을 공유함으로서 메모리 사용량을 낮추며, 개발과 테스트가 용이하게 하고 모듈화를 가능하게 합니다.

DLL을 만드는 일은 개발자에게 많은 도전을 가져다 줍니다. DLL은 시스템을 통한 강제적인 버전관리가 이뤄지지 않습니다. 즉, 여러개의 DLL이 한 시스템에 있을때, 이러한 버전관리 체크의 부족으로 인한 overwrite는 의존성과 API 충돌을 야기합니다. 개발 환경, 로더 구현 그리고 의존성의 복잡성은 로드 순서와 응용프로그램 행위에 취약성을 만듭니다. 그래도 많은 응용프로그램들은 복잡한 의존성을 가지는 DLL에 의지하고 있습니다. 이 문서는 DLL 개발자들을 위해 가이드라인을 제공하여 견고하고 이식성 있으며 확장성 있는 DLL로 만드는데 도움을 줄 것입니다.

■ 3개의 주요한 DLL 컴포넌트 개발 모델은 다음과 같습니다.

1. Library Loader
   DLL은 가끔 복잡한 내부의존성(interdependency)을 자니는데, 이는 그들이 로드되어야 하는 순서를 정의합니다. Library Loader는 효과적으로 이러한 의존성을 분석하고, 정확한 로드 순서를 계산한뒤 그 순서대로 로드를 합니다.
2. DLLMain entry-point function
   이 함수는 Loader에 의해 호출되며, 그 시점은 DLL의 Load 혹은 Unload일때 입니다. Loader는 한 시점에 단 하나의 DLLMain만 호출하도록 연속으로 호출합니다. 더 많은 정보
3. Loader Lock
   Loader가 순서대로 로드할때 사용되는 프로세스 단위의 동기화 객체입니다. 프로세스 단위의 Library Loader Data를 반드시 읽거나 써야 하는 함수는 반드시 이 Lock을 획득해야 합니다. 물론 이러한 operation을 수행하기 전에 이뤄져야 합니다. Loader Lock은 recursive이며, 이는 같은 쓰레드에서 다시 Lock의 획득이 가능함을 의미합니다.

그림 1. DLL 로드시 어떤일이 이뤄지는가?

DLLMain에서의 부적합한 동기화 시도는 응용프로그램에게 deadlock 혹은 초기화 되지 않은 DLL의 data와 code의 접근을 야기하게 됩니다. DLLMain에서의 특정 함수 호출은 이러한 문제를 잃으킵니다.

이상적인 DLLMain은 "그냥 비우는것" 입니다. 그러나, 많은 응용 프로그램의 복잡도를 고려할때 이는 너무한 제약이 됩니다. DLLMain을 다루는 좋은 방법은 많은 초기화 과정을 가능한 뒤로 미뤄라라는 것입니다. 이러한 미뤄진 초기화는 응용프로그램을 더욱더 견고히 해주는데, 그 이유는 Loader Lock가 획득된 동안의 초기화가 이뤄지지 않았기 때문입니다. 역시 이러한 방법은 Windows API의 사용에도 훨씬 많은 안정성을 제공합니다.

몇몇 초기화 작업은 뒤로 미룰순 없을 것입니다. 예를 들어, 설정 파일에 의존성이 있는 DLL이 있는데, 해당 파일이 좋지 않거나 쓰레기 내용이 포함되었을때 그 DLL의 Load가 실패되야 하는 경우가 있을 것입니다. 이런 종류의 초기화 방식은, 다른 작업의 자원 낭비를 하느니 DLL이 그 행위를 시도해보고 빨리 실패하는 것이 좋다고 개념이라 보여집니다.

■ 다음과 같은 작업을 절대로 DLLMain에서 수행해서는 안됩니다.

• LoadLibrary 혹은 LibraryEx의 직접적 혹은 간접적 호출. 이는 deadlock 혹은 crash를 유발한다.
• 다른 쓰레드와의 동기화 시도. 이는 deadlock을 유발한다.
• Loader Lock을 획득하기 위해 기다리는 코드가 획득한 다른 사설 동기화 객제를 획득하려고 하는 시도. 이는 deadlock을 유발한다.
• CoInitializeEx 사용에 의한 COM 쓰레드 초기화. 특정 상황이 되면 이 함수는 LoadLibrary를 호출한다.
• 레지스트리 함수군의 호출. 이 함수는 Advapi32.dll에 구현되어 있는데, 만약 AdvApi32.dll이 아직 당신 DLL에서 초기화되지 않았다면, 그 DLL은 메모리를 초기화해제 하며, crash를 유발한다.
• CreateProces 호출. 이는 다른 DLL을 Load할 수 있다.
• ExitThread 호출. DLL Detach 과정에서 Exit가 진행중인 Thread는 Loader Lock을 다시 획득하려고 하는 시도가 발생하여 deadlock 혹은 crash가 발생할 수 있다.
• CreateThread 호출. 다른 Thread와 동기화 작업을 하지 않는다면, 생성중인 Thread가 할 수 있는데, 이는 위험할 수 있다.
• Named Pipe 혹은 다른 Named Object의 생성(Windows 2000만 해당). Windows 200에서는 Named Object는 Terminal Service DLL에 의해 제공되는데, 만일, 이 DLL이 초기화되지 않았다면, DLL을 로드하게 되어 crash가 유발될 수 있다.
• 메모리 관리 CRT 함수 호출. 만약 CRT DLL이 초기화 되지 않았다면, crash가 유발된다.
• User32.dll 혹은 Gdi32.dll 함수 호출. 몇몇 함수들은 아직 초기화되지 않은 DLL을 로드한다.
• 관리 코드의 사용

■ DLLMain 내에서 안전한 작업은 다음과 같습니다.

• compile time의 static data의 초기화
• 동기화 객체의 생성과 초기화
• 메모리 할당과 dynamic data의 초기화 (위 금지 함수 이외)
• Thread local storage(TLS) 초기화
• File의 열기/읽기/쓰기
• kernel32.dll 함수의 호출 (위 금지 함수 제외)
• 전역 포인터 변수를 NULL로 할당

Lock 순서의 역(Lock order inversion)에 의한 deadlock

Lock과 같은 다중 동기화 객체 사용을 구현할 때, Lock 순서를 따르는 것은 굉장히 중요합니다. 어느 시점에서 한개 이상의 Lock을 획득하는 것이 필요할때 반드시 Lock hierachy 혹은 Lock 순서라 불리는 명시적인 순서를 정의해야 합니다. 예를 들어, Lock A가 Lock B이전에 획득되었고, Lock C 이전에 Lock B가 획득되었다면 Lock 순서는 A,B,C가 되고, 이 순서는 코드에서 지켜줘야 됩니다. 만약 Lock 순서가 역으로 되는경우가 발생했다면, 예를 들어, Lock A를 획득 하기 전에 Lock B가 획득되었을 경우, 이는 Lock 순서의 역에 의한 deadlock이 발생하게 됩니다. 이렇게 발생한 deadlock은 디버깅하기 힘든 면이 있습니다. 이것을 방지하기 위해 모든 쓰레드에서는 같은 순서대로 Lock을 획득해야만 합니다.

Loader는 이미 획득한 Loader Lock으로 DLLMain을 호출한다는 사실은 굉장히 중요합니다. 그래서 Loader Lock은 Locking hierachy의 가장 높은 우선순위가 되어야 합니다. 그와 마찬가지로 적합한 동기화를 위해 요구된 Lock을 획득하해야 하는 것도 알아야 합니다. 물론 hierachy에 정의된 모든 단일 Lock을 획득해야 할 필요는 없습니다. 예를 들어, A와 C를 적합한 동기화를 위해 획득하였다면, C를 획득하기 이전에 A를 획득해야 하며, B를 획득할 필요는 없습니다. 더 나아가 설명하자면, 프로그램 코드에서는 Loader Lock을 명시적으로 획득 할 수 없습니다. 만약 사적인 Lock을 획득한 상황에서 Loader Lock을 간접적으로 획득하려는 ::GetModuleFileName(...)과 같은 API를 호출해야 한다면, 사설 Lock을 획득하기 이전에 ::GetModuleFileName(...)을 획득해야만 합니다. 이는 Load 순서를 따르게 하기 위함입니다.

그림 2. Lock 순서의 역에 의한 deadlock

그림 2. 는 이러한 Lock 순서의 역을 보여주고 있습니다. DLLMain을 포함하는 Main 쓰레드를 가지는 DLL을 생각해 보십시요. Library Loader는 Lock L을 획득했으며, DLLMain을 호출하려고 합니다. Main 쓰레드에서는 동기화 객체인 A, B 그리고 공유 데이터를 접근하기 위해 필요한 G를 생성하고 G를 획득하기 위해 시도하려고 합니다. 그와 별도로, Worker 쓰레드에서는 이미 G를 획득한 상황이며 ::GetModuleHandle(...)를 호출하여 Loader Lock인 L을 획득하려고 시도할 것입니다. 그러면, Worker 쓰레드는 L에 의해 Block 되며, Main 쓰레드는 G에 의해 Block 되며, 이로 인해 deadlock이 발생하게 됩니다.

이러한 상황을 방지하기 위해서는, 모든 쓰레드에서는 항상 순서에 맞게 동기화 객체를 획득하도록 시도해야 합니다.

동기화를 위한 최고의 습관

---

초기화의 한 부분으로 DLL이 Worker 쓰레드를 생성해야 하는 경우를 생각해 보십시요. DLL이 Cleanup되면 data의 무결성(consistent)을 확신하기 위해 모든 Worker 쓰레드의 동기화가 필요하며, 그 다음 Worker 쓰레드는 종료하게 됩니다. 오늘날, 멀티쓰레드 환경의 DLL을 종료하고 동기화하는데에는 완벽하고 정확한 방법은 없습니다. 다음은 DLL 종료를 하는 동안 이루어질 쓰레드 동기화를 위해 현재까지 나와있는 최고의 습관을 설명하고 있습니다.

■ 프로세스 종료시 DLLMain에서의 쓰레드 동기화

• 프로세스 종료시 DLLMain이 호출되었다면 모든 프로세스의 쓰레드들은 Clean up이 이뤄지며 주소 공간(Address Space)는 더이상 유지되지 않습니다. 동기화는 이런 경우에는 필요하지 않습니다. 다시 말해 DLL_PROCESS_DETACH는 비워둬도 됩니다.
• Windows Vista에서는 핵심 data들(환경 변수, 현재 디렉토리, 프로세스 힙, ...)의 유지가 보장됩니다. 그러나 다른 동적 할당된 사설 data는 망가져서 더이상 안전하지 않습니다.
• 저장이 필요한 영구 유지될 상태들은 저장 매체에 플러쉬되어야 합니다.

■ DLL UnLoad시의 DLL_THREAD_DETACH를 위한 DLLMain의 쓰레드 동기화

• DLL이 UnLoad될때 주소 공간(Address Space)는 사라지는 것은 아닙니다. 따라서 DLL은 Clean될 예정인 상태입니다. 이것은 쓰레드 동기화, Open된 핸들, 영구 유지해야 하는 상태 그리고 할당된 자원들을 포함합니다.
• 쓰레드 동기화는 종잡을 수 없는데, DLLMain에서 쓰레드의 종료를 기다리는 것은 deadlock을 유발할 수 있기 때문입니다. 예를 들어, DLL A가 Loader Lock을 획득했습니다. 그리고 Thread T를 종료시키기 위해 Signal을 보냈고 종료를 기다리도록 합니다. 쓰레드 T는 종료가 되며, Loader는 DLL A의 DLL_THREAD_DETACH 호출을 위해 Loader Lock 획득을 시도할 것입니다. 이것이 deadlock을 유발시키게 됩니다. 이러한 리스크를 최소화 하는 방법은 다음과 같습니다.
• DLL A는 DLLMain에서 DLL_THREAD_DETACH 메시지를 받고, 쓰레드 T에게 종료해라는 Signal을 보냅니다.
• Thread T는 현재의 작업을 마치고 스스로 상태를 유지하며 DLL A에게 Signal을 보냅니다. 단, 이러한 유지된 상태 체크를 위해서 DLLMain의 deadlock 회피를 위한 제약을 지켜야 합니다.
• DLL A가 쓰레드 T를 종료 시켰으며, 그것이 아직 유지된 상태임을 알수 있습니다.

만약 DLL이 그것의 모든 쓰레드를 생성하고 나서 UnLoad되었고 실행이 시작되기 전이었다면, 그 쓰레드들은 crash가 발생할 수 있습니다. 만약 DLL이 초기화의 단계로 DLLMain에서 Thread를 생성하였다면, 몇몇 쓰레드들이 아직 초기화가 완료되지 못했고 그들의 DLL_THREAD_ATTACH 메시지가 여전히 DLL에게 전달되기를 기다리고 있을 것입니다. 이런 상황에서 DLL이 UnLoad된다면 쓰레드들의 Terminate가 시작될 것입니다. 그러나 몇몇 쓰레드들은 Loader Lock에 의해 block되어 있을 겁니다. 그들의 DLL_THREAD_ATTACH 메시지들은 DLL이 unmap된 이후 진행될 것이며, 이는 crash를 유발할 것입니다.

///////////// 두번째

오랜만에 블로그에 글을 쓰고 있습니다. 일종의 생존신고랄까요? 
VS2005 로 처음 작업할때도 이런 비슷한 문제로 필요없는 삽질을 꽤 했었습니다.  여기 ㅜ.ㅜ
요즘 VS2008 로 해야할 작업이 있어서 쪼물딱 거리는 와중에 이상한 현상이 있어서 삽질하고, 구글링한 결과를 정리해 볼까 합니다.
어떤 X 같은 일이 생겼나면.. 

개발머신   : VS2008, SP1 
테스트머신: 윈도우 XP SP3 

이렇게 PC 가 두대가 있습니다. 
당연히 VS2005 에서 작업하던 대로 Debug 빌드시에는 
Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT
아래 있는 파일들을 실행파일과 함께 테스트 머신에 복사하고, 실행을 했습니다. (private assembly 형태의 배포죠)
그런데 실행이 안되는겁니다.

뭐 요딴 메세지만 나오는 군요. 
아래 그림에서처럼 DLL 이 뭔가 없는것도 아니고요. 아무 문제 없습니다. (VLdr.exe 는 VLdr.dll 을 사용합니다)

Manifest 파일과 배포해야 하는 DLL 들도 잘 복사되어있고요.

대체 뭐가 문제란 말입니까.. ㅠ.ㅠ

한참을 원인을 찾던 중.. (뭐 딱히 구글링할 키워드도 떠오르지 않더군요. -_-)
뭐 급한대로 VLdr.exe.config 파일을 만들어서 dll 들을 redirect 시켜서 대충 해결이 되긴 하더군요. 
하지만 dll 이 앞으로 한두개도 아니고.. 3rd party library 라도 사용하게 되면 대략 난감해 지겠죠. 
config 파일로 해결이 된다는것은 결국 바인딩 되는 dll 의 버전 문제 아니겠는가 라는 결론이 나오죠.

VS 링커 옵션에 보면 minifest 를 자동생성하도록 되어있습니다.(디폴트로)
역시 평소에 VS 각 옵션 설정을 꼼꼼히 보아두었던 것이 도움이 되는군요 ^^.
바인딩되는 dll 들은 링크타임에 manifest 형태로 만들어지는 것이고요. 생성된 manifest 는 exe 나 dll 에 내장되는것이겠죠. (아님 말구요)

결국 debug 디렉토리(중간 오브젝트 생성경로)에 생성된 ****.exe.embed.manifest 를 살펴보니 (****.exe.intermediate.manifest 는 뭐 중간에 잠깐 만들어지는 넘 같으니 패스) 아래와 같은 내용이 있네요.

그런데 C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT 에 있는 minifest 파일을 열어보면 (private assembly 로 배포하던 파일이죠)

이런 ...ㅅㅂ... 욕나옵니다. -_-;; 
결국 SP 1 이 설치되었는데도 VS 는 예전 버전(시스템 런타임 버전)으로 바인딩을 하고 있는겁니다. 
이러니 당연히 실행이 안될 수 밖에요 (이해가 안되시는 분들은 WinSxS 나 Strong named assembly 라는 키워드로 검색을.. ).

결국 이런 저런 삽질과 구글링을 통해 알아낸 결과
 - VS 2008 SP1 설치 미디어에 있는 VC_x86Runtime.exe 을 디버기에서 실행하거나
 - 아래 전처리기를 stdafx.h 같은 곳에 (가능하면 가장 위에) 정의해 주는 겁니다.
#define _BIND_TO_CURRENT_MFC_VERSION 1
#define _BIND_TO_CURRENT_CRT_VERSION 1
프로젝트 속성 -> C/C++ -> 명령줄에 추가하는 것이 더 좋은것 같습니다. 
/D "_BIND_TO_CURRENT_MFC_VERSION=1"
/D "_BIND_TO_CURRENT_CRT_VERSION=1"
MFC 프로젝트에서 stdafx.h 에 추가했더니 여전히 잘못된 manifest 를 만들어내는군요. -_-;;

이 전처리기를 이용하면 정상적으로 ***.exe.embed.manifest  에 버전이 SP 1 용 MFC, CRT 의 버전으로 만들어집니다.
이게 VS 2005 와 VS2008 에서 이렇게 요상하게 다르게 동작하는 원인은 고객들의 요구에 의한거라고 하는군요. -_-

출처:VC8 의 dll binding 문제

volatile 키워드는 간단히 '코드 최적화를 막아주는 키워드'라고 설명할 수 있습니다. 즉 컴파일러의 최적화와 관련된 키워드이고 CPU 내/외부 캐시와 같은 하드웨어 최적화와도 관계가 있습니다. 지금처럼 임베디드 기반 프로그래밍이 보편화 되지 않았던 시절에는 volatile 키워드의 활용 빈도가 매우 낮았으나, 최근 임베디드 시스템이나 멀티 스레드를 고려한 프로그램이 늘어 가면서 volatile 키워드의 사용이 많아 지고 있습니다.

volatile 키워드는 주로 memory-maped I/O에서 사용됩니다. 임베디드 시스템에서는 MCU의 각종 레지스터가 메모리에 매핑되어 있는 경우가 많고 프로그램은 매핑된 메모리 주소에 값을 반복적으로 쓰게 되는데 이때 volatile 키워드가 사용됩니다. 다음의 코드로 volatile 키워드가 어떻게 동작하는지 살펴봅시다.

unsigned int *uart = 0x40700000;
*uart = 0x00080001;
*uart = 0x00080002;
*uart = 0x00080003;
*uart = 0x00080004;
*uart = 0x00080005;

위 코드를 보면 다섯 번째 메모리 쓰기가 모두 0x4070000번지에 행해집니다. 일반적인 상황에서 위 코드를 수행하고 나면 0x40700000 번지에는 가장 마지막 값인 0x00080005만 남게 될 것입니다. 따라서 똑똑한 컴파일러는 위 코드를 아래 코드처럼 최적화합니다.

unsigned int *uart = 0x40700000;
*uart = 0x00080005;

어차피 변수에는 가장 마지막 값만 남으므로 이렇게 고치는 것입니다. 일반적인 프로르매에서라면 아무런 문제 없이 동작하고 속도도 빨라집니다. 하지만 이 코드가 MMIO(Memory-Maped I/O) 상황에서 사용된다면 이것은 분명히 잘모된 최적화입니다. 각각의 메모리 쓰기 작업이 하드웨어에 특정한 작업을 명령하기 때문에 저렇게 최적화를 해 버리면 하드웨어는 오작동을 하게 됩니다. 그러므로 컴파일러에 최적화를 하지 말라는 '지시'를 내려야 합니다. 이러한 지시는 내리는 키워드가 바로 volatile입니다.

volatile unsigned int *uart = 0x40700000;
*uart = 0x00080001;
*uart = 0x00080002;
*uart = 0x00080003;
*uart = 0x00080004;
*uart = 0x00080005;

위와 같이 uart변수를 volatile로 선언하면 컴파일러는 uart변수에 최적화를 하지 않고모든 읽기 쓰기 작업을 메모리에서 직접하게 됩니다. 위 코드의 쓰기 작업 뿐만 아니라 읽기 작업도 마찬가지 입니다.

unsigned int *uart = 0x40700000;
char ch;
int i;
for(i = 0;i < 5;i++)ch = *uart;

위와 같은 코드 역시 최적화를 하면 *uart의 값을 한번만 읽어서 캐시에 저장한 다음 이것을 반복해서 사용합니다. 하지만 아래 코드처럼 uart 변수가 volatile로 선언되면 루프안에서 uart변수를 요구할 때마다 매번 메모리에서 값을 가져오기 때문에 그때 그때 변경되는 값을 읽을 수 있습니다.

volatile unsigned int *uart = 0x40700000;
char ch;
int i;
for(i = 0;i < 5;i++)ch = *uart;

---------------

가끔 일하다보면 extern "C"를 왜 써야 되는지도 모르고
사용하는 신입 코더들을 볼 수 있다. 때론 귀찮게 물어보기도 하고...
나중에 또 물어보면 이 페이지의 주소만 날려주리라. ㅋ

컴파일러는 link 작업시 오브젝트간 함수 이용 및 위치를 파악할 수 있도록,
컴파일시 사용된 함수에 관련된 정보를 오브젝트 파일에 기록하며, 이를 linkage라고 한다.

C++ 컴파일러는 컴파일 과정에서 Name mangling 이란 작업을 한다.
이는 정의되어 있는 함수명을 정해진 규칙에 의해 바꿔버리는 것이다.
(링크 에러날 때 본 적 있는가? 함수명 앞뒤에 붙은 이상한 기호와 숫자들을?)
(그리고 C++ 컴파일러가 왜 바꾸냐고? 그거 설명하려면 두꺼운 책 가져와야 된다... ㅈㅈ
굳이 목적 중에 하나를 설명하자면 override된 함수들의 구별을 위해... 이 정도)

참고로, C는 함수명 앞에 _ (underbar) 하나를 붙인다.

중요한 사실은 "코딩시 함수명과 컴파일 완료된 바이너리 코드에서의 함수명은 다르다" 라는 것이다.
이름을 바꾸는 규칙은 컴파일러에 따라 다르기 때문에 C++ 컴파일러가 다르면 호환이 되지 않는다.
즉, linkage type이 달라져 함수를 찾을 수 없게 되는 것이다.

이는 C++ 컴파일러 간에도 발생하는 문제이며 C와 C++ 컴파일러간에도 발생한다.
(당연하지 않은가, 컴파일러가 다르다니까 ㅋ)

공용의 라이브러리를 제작하였고 이 라이브러리를 사용하는 코더의 계층이 다양하다고 가정해보자.
C 환경에서도 사용을 할 것이고, 다른 C++ 환경에서도 사용할 것이다.
라이브러리 개발&배포자 입장으로써 링크 에러로 아우성치는 유저들 당황스럽다.

이를 피하기 위해 C++ 문법에서는 네임 맹글링을 막기 위해 아래 문장이 제공된다.
즉, C의 네임 형식으로 함수를 컴파일하는 것이다.

extern "C"

따라서 범용적인 라이브러리 헤더라면 아래와 같이 작성되는 것이 좋을 것이다.

// 상략
#ifdef __cplusplus
extern "C" {
#endif

// 중략
#ifdef __cplusplus
}
#endif
// 하략

자 이제 함수를 C 형식으로 컴파일 했다.
그러면 어떻게 되겠는가? name mangling 회피로 인한 link 문제는 해결이 되었다.

하지만 C 형식이므로 class의 멤버 변수가 될 수도, override가 될 수도 없다.
즉, C++ 고유 특성을 모두 잃어버리게 된다.

1. DLL의 주요 장점

2. DLL과 프로세스 주소 공간

DLL 파일의 이미지는 실행 파일이나 다른 DLL이 DLL 내 포함되어 있는 함수를 호출하기 전에

반드시 프로세스의 주소 공간에 매핑되어 있어야 한다.

이를 위해 다음 두 가지 방법 중 하나를 선택할 수 있다.

• 암시적 로드타임 링킹
• 명시적 런타임 링킹

위 방법들에 대해선 아래 챕터에서 각각 자세히 설명하도록 하겠다.

DLL 파일 이미지가 프로세스의 주소 공간에 매핑되고 나면,

DLL이 가지고 있는 모든 함수들은 프로세스 내의 모든 쓰레드에 의해 호출될 수 있게 된다.

사실 이렇게 로드가 완료되고 나면, DLL 고유의 특성은 거의 없어진다고 볼 수 있다.

프로세스 내의 쓰레드 관점에서는 DLL이 가지고 있는 코드와 데이터들은

단순히 프로세스의 주소 공간에 로드된 추가적인 코드와 데이터들로 여겨질 뿐이다.

쓰레드가 DLL에 포함되어 있는 함수를 호출하게 되면, 

호출된 DLL 함수는 호출한 쓰레드의 스택으로부터 전달된 인자 값을 얻어내고,

호출한 쓰레드의 스택을 이용하여 지역변수를 할당하게 된다.

뿐만 아니라 DLL 함수 내부에서 생성하는 모든 오브젝트들도 

DLL 함수를 호출하는 쓰레드나 프로세스가 소유하게 되며, DLL 자체가 소유하는 오브젝트는 존재하지 않는다.

예를 들어, DLL 내의 특정 함수가 VirtualAlloc 함수를 호출하게 되면,

해당 함수를 호출한 쓰레드가 속해 있는 프로세스의 주소 공간 내에 영역이 예약된다.

만일 DLL이 프로세스의 주소 공간으로부터 내려간다 하더라도

앞서 프로세스의 주소 공간에 예약했던 영역은 그대로 남게 되는데,

이는 시스템이 해당 영역이 DLL로부터 예약되었다는 사실을 특별히 관리하지 않기 때문이다.

하지만, 단일의 주소 공간은 하나의 실행 모듈과 다수의 DLL 모듈로 구성되어 있음을 반드시 알아두어야 한다.

이 중 일부 모듈은 C/C++ 런타임 라이브러리를 정적으로 링크하고 있을 수도 있으며,

또 다른 모듈은 C/C++ 런타임 라이브러리를 동적으로 링크하고 있을 수도 있다.

따라서, 단일의 주소 공간 내에 C/C++ 런타임 라이브러리가 여러 번 로드될 수 있다는 사실을 잊어버리면 곤란한다.

아래 예제를 살펴보자.

1. -- 실행 파일의 함수 --
2. void EXEFunc()
3. {
4.     void* pv = DLLFunc();
5.  
6.     // pv가 가리키는 저장소를 사용한다.
7.  
8.     // pv가 EXE의 C/C++ 런타임 힙 내에 있을 것이라고 가정한다.
9.     free(pv);
10. }
11.  
12. -- DLL의 함수 --
13. void* DLLFunc()
14. {
15.     // DLL의 C/C++ 런타임 힙으로부터 메모리를 할당받는다.
16.     return (malloc(100));
17. }

이 코드가 정상적으로 동작할 것인가?

DLL 함수 내에서 할당받은 메모리 블럭을 EXE 함수 내에서 정상적으로 해제할 수 있는가?

위 예제는 제대로 동작할수도 있고, 그렇지 않을 수도 있다.

만일 EXE와 DLL이 모두 DLL로 구성된 C/C++ 런타임 라이브러리를 사용하고 있다면, 위 예제는 정상 동작한다.

하지만, 둘 중 하나라도 C/C++ 런타임 라이브러리를 정적으로 링크하고 있다면, free 호출 과정에서 문제가 발생할 것이다.

이러한 문제는 애초에 습관을 제대로 들이면 된다.

DLL 내 메모리를 할당하는 함수가 있다면, 해제하는 함수도 DLL에 만들고 그걸 사용하는 것이다.

1. -- 실행 파일의 함수 --
2. void EXEFunc()
3. {
4.     // DLL 함수에서 할당한 메모리 블럭의 주소를 얻어온다.
5.     void* pv = DLLAllocFunc();
6.  
7.     // pv가 가리키는 메모리 블럭을 사용한다.
8.  
9.     // DLL 함수를 이용해 pv를 메모리로 반환한다.
10.     DLLFreeFunc(pv);
11. }
12.  
13. -- DLL의 할당 함수 --
14. void* DLLAllocFunc()
15. {
16.     // DLL의 C/C++ 런타임 힙으로부터 메모리를 할당받는다.
17.     return (malloc(100));
18. }
19.  
20. -- DLL의 해제 함수 --
21. void DLLFreeFunc(void* p)
22. {
23.     // DLL의 C/C++ 런타임 힙에서 메모리를 해제한다.
24.     free(p);
25. }

그리고, 실행 파일 내에 전역으로 선언된 정적 변수는 동일한 실행 파일이

여러 번 실행될 경우라도 Copy-on-write 메커니즘에 의해 공유되지 않는다.

DLL 파일 내에 전역으로 선언된 정적 변수 역시 이와 동일한 메커니즘이 적용된다.

프로세스가 DLL 이미지 파일을 자신의 주소 공간 내에 매핑하는 경우

실행 파일의 경우와 동일하게 전역으로 선언된 정적변수의 새로운 인스턴스가 생성된다.

이를 공유하게 하는 방법에 대해선 PE/COFF의 Section 문서의 챕터 4. 공유 섹션을 보기 바란다.

3. DLL과 실행 파일 작성법

이제, DLL을 생성하는 방법과 실행 파일이 어떻게 DLL 파일의 함수나 변수를 사용해야 하는지에 대해 알아보자.

1. DLL 모듈 생성

DLL은 변수, 함수, C++ 클래스를 다른 모듈에 export 할 수 있다.

하지만, 코드의 계층적 추상화를 유지하고 DLL 코드를 좀 더 쉽게 유지/관리하기 위해 

변수는 가급적 익스포트 하지 않는 것이 좋다.

또한, C++ 클래스는 export 한 C++ 클래스를 사용하는 모듈을 

동일한 회사의 컴파일러를 사용하는 컴파일한 경우에만 사용할 수 있으므로 주의하도록 하자.

DLL을 작성할 때 export 하고자 하는 변수나 함수를 포함하고 있는 헤더 파일을 먼저 작성하는 것이 좋다.

이러한 헤더 파일에는 export 할 함수나 변수가 사용하는 심벌이나 데이터 구조체도 반드시 정의되어 있어야 한다.

이 헤더는 DLL과 함께 배포되어야 하며, 이 DLL을 사용하는 모듈은 이 헤더를 반드시 인클루드 해야 한다.

또한, 유지보수의 편의성을 위해 DLL 하나당 헤더 파일 1개씩 페어로 작성하는 것이 좋다.

이제 간단한 DLL 헤더의 예제를 살펴보도록 하자.

(아래 예제는 vs2010에서 DLLTest라는 DLL 프로젝트를 생성하면 기본적으로 생성시켜주는 헤더 파일이다)

1. 
   
2. #ifdef DLLTEST_EXPORTS
3. #define DLLTEST_API __declspec(dllexport)
4. #else
5. #define DLLTEST_API __declspec(dllimport)
6. #endif
    
7. // 이 변수는 DLLTest.dll에서 내보낸 것입니다.
8. extern DLLTEST_API int nDLLTest;
9.  
10. // 이 함수는 DLLTest.dll에서 내보낸 것입니다.
11. DLLTEST_API int fnDLLTest(void);

DLLTest 프로젝트의 전처리기에는 DLLTEST_API 가 선언되어 있다.

즉, 함수나 변수, 클래스 앞에 __declspec(dllexport) 선언 지정자가 붙는 것이다.

그리고 아래 예제는 역시 DLLTest 프로젝트가 기본 생성해준 cpp 파일이다.

1. // DLLTest.cpp : DLL 응용 프로그램을 위해 내보낸 함수를 정의합니다.
2. //
3. #include "stdafx.h"
4. #include "DLLTest.h"
5.  
6. // 내보낸 변수의 예제입니다.
7. DLLTEST_API int nDLLTest=0;
8.  
9. // 내보낸 함수의 예제입니다.
10. DLLTEST_API int fnDLLTest(void)
11. {
12.     return 42;
13. }

위 cpp 예제에서 nDLLTest 변수와 fnDLLTest 함수 앞에 DLLTEST_API 매크로가 붙어 있지만,

cpp에서는 DLLTEST_API를 붙이지 않아도 무방하다.

자, 이제 위와 같이 기본 생성된 DLL 프로젝트를 빌드하고, DLL을 생성해 보자.

Output 폴더에 가보면, 다음 두 개의 파일이 생성되어 있다.

• DLLTest.lib
• DLLTest.dll

DLL 파일을 컴파일하면, 컴파일이 끝난 후 링커는 DLL의 소스코드가 

적어도 하나 이상의 함수/변수를 export 하고 있는지를 확인하고, 그 경우 .lib 파일을 생성한다.

.lib 파일은 어떠한 함수나 변수도 포함하고 있지 않기 때문에 그 크기가 매우 작으며,

단순히 DLL 파일이 export 하고 있는 함수나 변수의 심벌 이름만을 유지하고 있다.

이 파일은 DLL 파일이 export 하는 심볼을 참조하는 실행 모듈을 링크하는 과정에서 반드시 필요하다.

(이 내용은 DLL을 암시적 로드타임 링크할 때만 유효하다)

.lib 파일을 생성하는 것 외에도 링커는 DLL 파일 내에 해당 파일이 

export 하고 있는 심볼에 대한 정보를 테이블 형태로 포함시켜 준다.

export section이라고 불리는 이 테이블은 export 하고 있는 

변수, 함수, 클래스 심볼에 대한 목록을 (알파벳순으로) 가지고 있다.

링커는 이 외에도 상대 가상 주소(RVA:Relative Virtual Address)를 DLL 파일 내에 포함시키는데,

이 값은 각각의 심볼들이 DLL 모듈 내의 어느 위치에 있는지를 가리키는 값이다.

그럼 이제 DLLTest에서 export 하고자 한 변수와 함수가 제대로 export 되어 있는지를 dumpbin으로 확인해 보자.

꾸엑~ 

함수명 fnDLLTest은 ?fnDLLTest@@YAHZX로 

변수명 nDLLTest은 ?nDLLTest@@3HA로 naming 되어 있다.

이것은 C++ 컴파일러가 C++ 특성(override나 등등의)을 위해 컴파일시 함수나 변수명에 name mangling을 하기 때문이다.

물론 DLL도 C++로 작성하고, 사용 모듈 역시 C++로 작성된다면 실행에 아무런 방해가 되지 않는다.

하지만, DLL은 C++로 작성하고, 사용 모듈이 C로 작성될 수도 있는 상황이라면,

C로 작성한 사용 모듈에서 DLL 함수를 호출하면 링크 과정에서 존재하지 않는 심볼 참조 에러가 발생하게 된다.

이를 해결하기 위해선, extern "C" 를 사용하는 방법이 있다.

즉, 위 헤더를 다음과 같이 변경하는 것이다.

1. #ifdef DLLTEST_EXPORTS
2. #define DLLTEST_API extern "C" __declspec(dllexport)
3. #else
4. #define DLLTEST_API extern "C" __declspec(dllimport)
5. #endif
6.  
7. // 이 변수는 DLLTest.dll에서 내보낸 것입니다.
8. DLLTEST_API int nDLLTest;
9.  
10. // 이 함수는 DLLTest.dll에서 내보낸 것입니다.
11. DLLTEST_API int fnDLLTest(void);

하지만, extern "C" 는 C++ 클래스 사용시엔 문제가 발생하므로, 클래스는 조심해서 한정자를 사용해야 한다.

자세한 내용은 http://sweeper.egloos.com/1792976 참고

자 이제, 다시 한번 DLL 프로젝트를 빌드하고, dumpbin으로 확인해 보자.

오~ 깨끗하게 나온다.

헌데, 이 상태에서 fnDLLTest 함수의 calling convention을 __stdcall로 바꾸고 싶어졌다.

문제는 M$ C 컴파일러가 __stdcall 함수에 대해선 C++를 사용하지 않다 하더라도,

함수의 이름을 멋대로 바꾸는 작업을 수행한다는 것이다.

함수의 이름 앞에 _ (underbar)를 붙이고, 함수의 이름 뒤엔 매개변수 크기의 총합을 @와 함께 표시한다.

위 예제의 fnDLLTest 함수를 __stdcall로 호출하면, dumpbin 결과가 아래와 같이 나온다.

역시 fnDLLTest 함수명이 바뀌었기에, 

DLL을 사용하는 모듈이 타사의 컴파일러를 사용하는 경우 링크 에러를 발생시키게 된다.

다른 회사의 컴파일러에서 사용될 DLL 파일을 M$ 컴파일러를 사용해 컴파일하려 하면,

컴파일러에게 이름 변환을 수행하지 않도록 확실한 명령을 주어야만 한다.

두 가지 방법이 있으나, 두 번째 방법은 별로이므로, 한가지만 소개하겠다.

바로 .def 파일을 프로젝트에 추가하고 EXPORTS 섹션을 구성하는 것이다.

.def 파일은 DLL의 ouput name과 동일하게 맞추어야 한다.

1. LIBRARY DLLTest
2.  
3. EXPORTS
4.         fnDLLTest
5.         nDLLTest

M$ 링커는 .def 파일을 분석하는 과정에서 fnDLLTest와 _fnDLLTest@0 이라는 두 개의 함수가 export 되었음을 인지하게 된다.

그러나 이 두 함수의 이름이 서로 일치하기 때문에 (이름 변환 과정을 배제할 경우)

.def 파일에 정의되어 있는 fnDLLTest 라는 함수만 export 하고, _fnDLLTest@0 는 export 하지 않는다.

사실 .def 방식이 가장 확실하다.

.def 파일을 사용하면, 

• extern "C"를 붙이든 그렇지 않든,
• 함수의 calling convention으로 __stdcall을 사용하든

naming에 있어 아무런 문제가 되지 않는다.

만약, 자신이 만든 DLL이 널리 배포될 용도로 제작되어야 한다면,

조금 귀찮더라도 .def 파일을 프로젝트에 추가하고, EXPORTS 섹션을 구성함을 가장 추천한다.

물론, M$ 컴파일러로 DLL을 만들고, 사용 모듈 역시 M$ 컴파일러로 만들고, 둘의 환경 모두 C++이라면

아무 것도 하지 않아도 문제가 되진 않는다.

2. 실행 모듈 생성

우선, 아래 내용은 DLL을 Implicit Loadtime Link 할 경우에 초점이 맞추어져 있다.

실행 파일의 소스 코드를 개발할 때에는 반드시 DLL과 함께 제공되는 헤더 파일을 인클루드해 주어야 한다.

실행 파일의 소스 코드에서는 DLL 헤더 파일을 인클루드할 때, DLLTEST_EXPORTS 를 정의해선 안 된다.

정의하지 않은 채 코드를 컴파일하게 되면,

DLLTest.h 파일 내에서 DLLTEST_EXPORTS를 __declspec(dllimport)로 정의하게 된다.

1. // DLL 헤더 인클루드
2. #include "DLLTest.h"
3.  
4. // 테스트를 위한 암시적 로드타임 링킹
5. #pragma comment(lib, "DLLTest.lib")
6.  
7. int _tmain(int argc, _TCHAR* argv[])
8. {
9.         // DLL의 변수에 값 설정
10.         nDLLTest = 1;
11.  
12.         // DLL의 함수 호출
13.         int num = fnDLLTest();
14.  
15.         return 0;
16. }

컴파일러가 변수, 함수, C++ 클래스에 대해 __declspec(dllimport) 한정자를 발견하게 되면, 

이러한 심볼들이 다른 DLL 모듈에서 임포트된 것임을 알게 된다.

다음 단계로 링커는 실행 파일의 소스 코드에서 사용되고 있는 심볼들이 어떤 DLL로부터 export 된 것인지를 확인해야 한다.

이를 위해 링커에게 .lib 파일을 전달해 주어야 한다.

앞서 말한 것과 같이 .lib 파일은 단순히 DLL 모듈이 export 하고 있는 심볼들에 대한 목록만을 가지고 있다.

링커는 import 된 심볼을 찾는 과정에서 import section이라는 특수한 섹션을 실행 파일 내에 추가한다.

이 import section은 실행 파일이 필요로 하는 DLL 모듈과 해당 DLL 모듈에서 참조되는 심볼에 대한 목록이 포함되어 있다.

이제 실행 파일을 생성하고, dumpbin으로 내용을 확인해 보자.

DLLTester.exe의 import 섹션에서 DLLTest.dll의 fnDLLTest 함수와 nDLLTest 변수의 심볼을 확인할 수 있다.

이제 실행 파일을 실행해 보자.

실행 파일이 실행되면...

1. 운영체제의 로더는 프로세스를 위한 가상 주소 공간을 생성한다.
2. 이후, 로더는 실행 모듈을 프로세스의 주소 공간에 매핑한다.
3. 로더는 실행 파일의 import section을 확인하여 필요한 DLL 파일들을 찾아서 프로세스의 주소 공간에 추가 매핑한다.

Import section 내에 포함된 DLL 이름은 전체 경로명을 포함하고 있지 않기 때문에,

로더는 사용자의 디스크 드라이브로부터 DLL을 검색해야 한다.

아래에 로더의 검색 순서를 나타내었다.

1. 실행 파일 이미지가 있는 디렉토리
2. GetSystemDirectory 함수의 반환 값인 윈도우 시스템 디렉토리 (Windows\System32)
3. 16비트 시스템 디렉토리 (Windows\System)
4. GetWindowsDirectory 함수의 반환 값인 윈도우 디렉토리 (Windows\)
5. 프로세스의 현재 디렉토리
6. PATH 환경 변수에 포함된 디렉토리

DLL 모듈이 프로세스의 주소 공간에 매핑되면, 로더는 각 DLL 파일의 import section을 조사한다.

(DLL 역시 다른 DLL을 링크할 수 있기 때문에...)

만일 import section이 존재한다면, 로더는 계속해서 프로세스의 주소 공간에 

추가적으로 필요한 DLL 파일들을 매핑시켜 나단다.

로더는 DLL 모듈을 지속적으로 추적하여, 설사 여라 차례 참조되는 모듈이라 하더라도,

단 한번만 로드되고 매핑될 수 있도록 한다.

모든 DLL 모듈들이 프로세스의 주소 공간에 로드되고 매핑되면,

로더는 import 된 심볼의 모든 참조 정보를 수정해 나간다.

이를 위해 각 모듈의 import section을 다시 한번 살펴보게 된다.

로더는 각각의 심볼에 대해 관련 DLL의 export section을 검토하고 심볼이 실제로 존재하는지 확인한다.

로더는 심볼의 RVA 정보를 가져와서 DLL 모듈이 로드되어 있는 가상 주소 공간에 그 값을 더한다.

이후, 실행 모듈의 import section 내에 계산된 가상 주소 값을 기록한다.

이제 코드에서 import 된 심볼을 참조하게 되면 호출 모듈의 import section으로부터

import 된 심볼의 위치 정보를 가져와서 import 된 변수, 함수, C++ 클래스의 멤버 함수에 성공적으로 접근할 수 있게 된다.

애플리케이션이 새로 실행될 때마다 위와 같은 과정을 거쳐야 하므로, 초기 구동에 많은 비용을 소비하게 된다.

애플리케이션의 로딩 속도를 향상시키기 위해 실행 파일과 DLL 모듈에 대해

시작 위치 변경(rebase)과 바인딩(binding) 작업을 수행하는 것이 좋다.

Rebase와 binding에 대해서는 추후 별도로 글을 하나 더 쓰는 것이 좋을 듯 하다.

4. Implicit Loadtime Link

암시적 로드타임 링크는 static libaray를 링크하는 방법과 완전히 동일한 방법으로 수행할 수 있다.

또한, static library를 링크하는 것처럼 DLL의 export된 모든 변수와 함수, C++ 클래스가 

프로세스의 주소 공간에 매핑된다.

암시적 로드타임 링크시 어떻게 프로세스 주소 공간에 매핑되고,

프로세스에서 DLL 내 심볼에 접근하는지에 대한 과정은 위 3-2. 실행 모듈 작성 챕터에 자세히 설명되어 있다.

암시적 로드타임 링크는 역시 편안함에 기인한다.

프로세스의 주 쓰레드가 돌기 시작한 이후

별도로 DLL을 로드/해제할 필요가 없고, 심볼 역시 별도의 시작 주소를 얻어오는 과정 없이 바로 사용할 수 있기 때문이다.

Static library와 링크하는 방법이 똑같지만, 이왕 정리하는 김에 

암시적 로드타임 링크를 하는 두 가지 방법에 대해 다시 한번 소개하겠다.

1. 프로젝트 속성의 링커-입력에 .lib 추가

프로젝트 속성 - 링커 - 입력에 DLL의 .lib 파일을 추가하는 것이다.

2. comment 지시어 사용

위 3-2 예제에 나왔듯이 comment 지시어를 사용하여, 암시적 로드타임 링크를 시킬 수 있다.

1. // 암시적 로드타임 링킹
2. #pragma comment(lib, "DLLTest.lib")

개인적으로는 2번 방법을 선호하는 편이다.

위에서도 썼듯이, 프로젝트 속성에서 제어하는 방법은

공동 작업자가 꼼꼼히 속성을 살피지 않으면 지나치기 일수라,

코드에서 명백하게 링크하는 것이 경험상 훨씬 더 직관적인 것 같다.

5. Explicit Runtime Link

시퀸스(Sequence) 컨테이너----------------------------------------------------------------------------------------------------------------------

시퀀스 컨테이너는 삽입된 요소의 원래 순서를 유지합니다. 이로 인해 여러분은 컨테이너의 어느 곳에 요소를 삽입할 것인지 지정할 수 있습니다.

deque (양방향 큐) 컨테이너는, 컨테이너의 시작과 끝에 빠르게 삽입 및 삭제를 할 수 있게 합니다. 또한 어떤 요소건 신속하게 임의 액세스를 할 수 있습니다.

list 컨테이너는, 컨테이너의 어느 위치건 빠르게 삽입 및 삭제를 할 수 있게 하지만, 컨테이너의 요소에 임의 액세스를 할 수 없습니다.

vector 컨테이너는, 배열처럼 동작하지만, 필요하면 자동으로 증가합니다.

시퀀스 컨테이너에 대한 더 자세한 내용은 다음 표를 참고하십시오.

연관(또는 결합형)(associative) 연관 컨테이너------------------------------------------------------------------------------------------------------

결합형 컨테이너를 구분짓는 특징은, 오름차순 정렬과 같이, 미리 정의된 순서대로 요소가 삽입되는 것입니다.

결합형 컨테이너는 다음 두 개의 하위 집합으로 그룹화 할 수 있습니다: map 과 set. map은 때때로 dictionary라고 불리는데, 키/값 쌍으로 구성됩니다. 키는 시퀀스를 정렬하는 데 사용되고, 값은 어떤 식으로든 해당 키와 연관되어 있습니다. 예를 들면, map이 텍스트의 모든 고유 단어를 나타내는 키와, 해당 단어가 텍스트에 나타나는 횟수를 표현하는 값을 포함할 수 있습니다. set은 단순히 고유 요소의 오름차순 컨테이너입니다.

map 및 set 둘 다, 컨테이너에 삽입될 키 또는 요소의 인스턴스를 하나만 허용합니다. 요소의 다중 인스턴스가 필요한 경우 multimap 또는 multiset를 사용하십시오.

map과 set 둘 다 양방향 반복기를 지원합니다. 반복기에 대한 더 자세한 내용은 반복기를 참고하십시오.

STL 표준의 공식적인 부분은 아니지만, hash_map 및 hash_set은 검색 시간을 향상시키는 데 널리 사용됩니다. 이 컨테이너는 요소를 해시 테이블로 저장하며, 각 테이블은 요소들의 양방향 연결 목록을 포함합니다. 검색 시간을 가장 빠르게 하려면, 여러분의 요소에 대한 해시 알고리즘이 균등하게 분산된 해시 값을 반환해야 합니다.

결합형 컨테이너에 대한 더 자세한 내용은, 다음 표를 참고하십시오.

Texture Atlases (텍스쳐 아틀라스)

How to use them (사용방법)

<TextureAtlas imagePath="atlas.png">
 <SubTexture name="moon" x="0" y="0" width="30" height="30"/>;
 <SubTexture name="jupiter" x="30" y="0" width="65" height="78"/>;
 ...
</TextureAtlas>;

하지만 수동으로 텍스쳐 아틀라스를 만들 필요는 없습니다. 아래의 툴중에 하나를 사용할 수 있습니다.

오늘은 간단한 C++ 프로그래밍 기법에 대해 하나 써볼까 합니다.

간단한 기교를 부려볼 겸 클래스의 멤버함수를 쓰레드 함수로 작성하는 방법을 배워 보도록 하겠습니다.

(간단히 쓰레드 사용법도 배우고 일석이조! 야호! )

아직까진 그런 적은 없지만, 쓰레드를 돌릴 때 간간히 멤버함수를 쓰레드 함수로 제작하고플 때가 있더군요.

혹, 그런 분들을 위해 알려 드리겠습니다.

 Start() 멤버 함수에서 TestFunction()을 쓰레드로 돌리고자 한다고 해보죠.

물론 안됩니다. 쓰레드로 돌아갈  함수는 정적으로 선언되어야 하며 정적 함수여야 하죠. 따라서,

역시 물론 안됩니다. 직접 닥쳐보시면 알겠지만, 우리가 돌리고자 했던 TestFunction 함수에서는 B라는 비정적 멤버를 참조하고 있습니다.

결국은 다른 방법을 찾아야 합니다.

자, 위 예를 통해 해결했습니다. 포인터. 즉 동적 호출을 통해서 정적 멤버 함수를 호출하였습니다.

TestFunction의 인자 값도 동적으로 주고 싶다면,