★ 프로그래밍을 마냥 좋아하는 아이 - 심스의 프로그래밍 세상 ★

이것은 초급자를 위한 팁임을 미리 말씀드립니다. 

1. Motivation

 우리는 개발한 상위 라이브러리에서 사용하고 싶은 이벤트 혹은 메시지를

 등록하고 그것을 사용자 정의 콜백 함수로 호출하는 구조를 사용자에게

 제공해 주고 싶은 경우가 있습니다.

 MFC와 같은 프레임워크처럼, ON_MESSAGE( UserMessage, OnUserFunction )로

 사용자 정의 메시지 및 이벤트 처리하게 해주는 메커니즘을 말이죠.

 

2. Solution 

우리가 개발한 라이브러리에서 다음과 같이 사용자 이벤트와 콜백 함수를

등록할 수 있는 함수가 있습니다.

RegisterEventHandler( ON_PMSG_CHAT, this, ClassType::OnPmsgChat );

이 구현을 위해 가장 고민해 보아야 할 문제는 여러 클래스 타입들의 메소드를

어떻게 콜백 함수로 등록할 수 있는가입니다. 다시 말해, 이것은 콜백 함수로

등록될 클래스의 타입과 클래스 메소드의 함수 포인터형을 알 수 없다는 것입니다.

MFC의 경우에는 이벤트 처리기와 메시지 맵은 CObject 이하의 수많은 클래스

타입들에 대한 오버로딩 메소드를 미리 정의하고 구현해 놓았지요.

3. Conclusion

아래 소스와 같은 구현으로 어떠한 클래스의 타입 메소드가 인수로 대입되더라도

콜백 함수로 등록하고 처리할 수 있습니다.

콜백 함수의 등록은 아래의 매크로 함수로 할 수 있습니다.

RegisterEventHandler( ON_PMSG_CHAT, this, ClassType::OnPmsgChat );

아래의 소스에서 매크로로 구현된 CMyClass::GetInstance()->AddEventHandler()는

우리가 개발한 라이브러리의 클래스 내에서 (싱글톤 패턴이라는 가정하에서는) Static

Object의 포인터를 저장하는 역할을 하는 메소드입니다.

// HandlerManager.h

#ifndef  HANDLER_MANAGER_
#define HANDLER_MANAGER_

#include <iostream>
#include <windows.h>

#define RegisterEventHandler(dwMessage, pInst, lpFunc);                                     \
           static CHandlerObject &lpfn##dwMessage = SetEventProc( pInst, &lpFunc );   \
           CMyClass::GetInstance()->AddEventHandler( &lpfn##dwMessage );

#define CALLBACKPROC(dwMessage, lpBuffer, dwSize);                                       \
           lpfn##dwMessage.CallBackProc( dwMessage, lpBuffer, dwSize );

 
class CHandlerObject
{
public:
    virtual LPVOID CallBackProc(DWORD dwMessage, LPVOID lpBuffer, DWORD dwSize) = 0;
};

template <class ObjectType, typename FuncPtrType>
class CHandlerManager : public CHandlerObject
{
private:
    ObjectType *m_pObject;
    FuncPtrType m_pFuncPtrType;

    int nCntHandler;

public:
    CHandlerManager(ObjectType* pObject, FuncPtrType pFuncPtrType) : m_pObject( pObject ),
                                                                                                 m_pFuncPtrType               
                                                                                                ( pFuncPtrType ) {}
    ~CHandlerManager() {} 

    LPVOID CallBackProc(DWORD dwMessage, LPVOID lpBuffer, DWORD dwSize)
    {
               (m_pObject->*m_pFuncPtrType)( dwMessage, lpBuffer, dwSize );

               return NULL;
    }

};

 
template <class ObjectType, typename FuncPtrType>
CHandlerManager<ObjectType, FuncPtrType>
SetEventProc(ObjectType *pObject, FuncPtrType pFuncPtr)
{
               return CHandlerManager<ObjectType, FuncPtrType>(pObject, pFuncPtr);
}

#endif

 

Written By Simhyeon, Choe

제가 보고 있는 c 언어 책의 포인터와 문자열 부분에서 ...

char *p = "abcde";

"abcde" 는 메모리 어딘가에 문자열 리터럴로 보관되어 있다.

그런데, 메모리에 할당하기는 하지만 값을 변경할 수 없는 메모리 영역에 보관된다고 하는데 ...

어떤 영역인가요 ?

제가 메모리 영역에 대해서 잘 몰라서 질문을 드립니다.

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

.rdata라는 섹션에 저장됩니다. PE File View 혹은 PE File Explorer라는 툴(실행 파일 분석툴)을

사용하여 해당 파일을 열어 보시면 .rdata라는 섹션에 저장되어 있습니다. 실행 파일은 여러 개의

섹션(영역)과 그 섹션에 대한 정보를 가지는 구조로 이루어져 있습니다. 또한 각각의 섹션은 초기화,

읽기, 쓰기, 데이터, 텍스트 등의 고유한 속성에 대한 정보를 가지고 있습니다.  실행 파일이 실행될

때, 파일의 이미지가 메모리에 동일하게 맵핑됩니다. .rdata 섹션의 속성은 READ ONLY, DATA로

설정되어 있기 때문에 해당 영역에 쓰려고 할 때, 커널은 속성을 체크하고 위배되면 엑세스 위반을

일으키게 됩니다. 물론, .rdata 섹션의 속성을 쓰기로 변경하면 쓰기도 가능합니다. 이렇게 읽기

전용 데이터 섹션을 설정한 이유는 동일한 상수를 여러 곳에서 참조하기 때문이지요. 이것은 아주

당연한 이유입니다. 한곳에서 수정이 가해지면 해당 리터럴 상수를 참조하고 있는 다른 곳에서도

영향을 주기 때문입니다. Win32 운영체제는 실행 파일을 .rdata, .data, .idata, .text, .rsrc 등의

여러가지 섹션으로 코드와 데이터를 나누어 관리하고 있습니다. 이렇게 섹션을 나누어 관리하는

이유는 로더가 각 영역을 커널에서 정한 레이아웃에서 엑세스하는 데이터 및 코드를 쉽게 맵핑하고

사용하기 위함입니다. 그리고 컴파일러는 리터럴 상수를 경우에 따라 프로세스를 생성시 매번

할당하는 것이 아니라, data 섹션이 아닌 text 섹션에 직접 쓰기도 합니다. 이것은 할당 및 엑세스

속도를 빠르게 하기 위함입니다. 여기서 정확한 표현은 Segment보다는 Section으로 보는 것이

옳습니다. 그리고 위에서 님이 말씀하신 것처럼 동일한 위치를 가리키는 이유는 단순히 컴파일러

입장에서 최적화를 위한 것입니다. 동일한 상수를 .rdata 영역에 여러번 할당하는 것이 낭비고 어차피
 
변경 불가능하고 참조만 되어지는 대상이기 때문에 두 개의 포인터가 하나의 리터럴 상수를 가리켜도

전혀 문제될 것이 없습니다. 두번째로 질문하신 내용에 대한 답변을 드리겠습니다.

디버기 프로세스가 되지 않고 파일 접근이 아닌 이상, 해당 프로세스에서 실제 그 영역 속성의 변경은

불가능하지만, 페이지 속성 변경 및 CopyOnWrite 메커니즘으로 .rdata에 쓸 수가 있습니다.

DWORD dwReadData = 0;

char *pString = "Hello";

VirtualProtect( pString, 4096, PAGE_READWRITE, &dwReadData );

*pString = 'P';

Written By Simhyeon, Choe

이것도 예전에 데브피아에서 어떤 유저가 기고하였던 질문에 대한 저의 답변입니다.

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

구조체에서..
 
char a;
int b;
float c;

이것은 아는 대로 12바이트가 할당 됩니다.

char a;
int b;
double c;

이것은 16바이트가 할당이 되구요..

헌데, 

char a;
double b;
float c;

는 24바이트가 할당이 되네요.

구조체는 시스템의 메모리의 한 워드 단위로 할당이 되는거 아닌가요?

그러면 4바이트 단위니깐 16바이트가 맞는것 같은데..

답변 부탁드리겠습니다.

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

Structure Alignment는 시스템 cpu에 따라 의존적입니다.

이러한 구조체 정렬을 하는 근본적인 이유는 데이터 타입을

버스의 크기만큼 처리하는 것이 가장 효율적이기 때문이죠.

그러니까 예를 들면, 32Bit CPU에서는 데이터 버스도 32Bit의

크기를 가지는데, 한번에 처리할 수 있는 크기 단위로 처리하는

것이 성능면에서 당연히 효율적일 겁니다. 보다 작으면 데이터를

처리하기 위해서는 쉬프트 연산으로 인한 오버헤드가 크다는 겁니다.

차라리 몇 바이트를 낭비하는 대신, 성능상의 이점을 충분히 얻겠다는 의도입니다.

VC 컴파일러는 기본적으로 8Byte 정렬을 하는데요..

컴파일러 옵션으로 정렬 단위를 바꿔 줄 수 있습니다.

Structure Alignment는 그 구조체 멤버에서 가장 큰 데이터

타입을 기준으로 정렬하게 됩니다.

그럼 님께서 예를 들었던 구조체들을 다시 한번 살펴 보도록 하겠습니다.
 

char a;
int b;
float c;
 

1) 위의 구조체에서 가장 큰 멤버의 크기는 4Byte입니다.
 

■■■■
■■■■
■■■■

그렇기 때문에 4 바이트를 기준으로 정렬하게 되며,

첫번째 멤버 char a는 3byte의 Empty Block이 생기게 되겠죠.
 

///////////////////////////////////////////////////////////////

 
char a;
int b;
double c;
 

2) 위의 구조체에서 가장 큰 멤버의 크기는 8Byte입니다.

 
■■■■■■■■
■■■■■■■■
 

char a와 int b는 둘다 8Byte 블럭안에 포함될 수 있습니다.
 
단, 두번째 멤버 int b는 4Byte기 때문에, 앞의 공간을 사용한
 
char a에 의해서 3Byte 공간만 남아 정렬될 수 없기 때문에

int b 자신의 데이터 크기만큼 띄워 나머지 공간에 padding되게 됩니다.
 

///////////////////////////////////////////////////////////////

char a;
double b;
float c;

3) 위의 구조체에서 가장 큰 멤버의 크기는 마찬가지로 8Byte입니다.

■■■■■■■■
■■■■■■■■
■■■■■■■■

첫번째 멤버 char a가 위치한 후에 8Byte에서 나머지 7Byte 공간에

double b가 들어갈 수 없기 때문에, 자신의 블럭 크기로 padding되게 됩니다.

마찬가지입니다. float c도 위의 8Byte(double b의 공간)이 모두 채워졌기

때문에 다시 8Byte만큼 정렬한 공간에서 나머지 4Byte크기로 padding되게 됩니다.

※ 메모리 위치가 수시로 변할 수 있는 근본적인 이유는 Allocation Segment Alignment 때문입니다.

    그러니까 힙 영역을 할당할 때, os에서 heap allocation을 처리하는 알고리즘에서 새로이 할당되는

    메모리 영역을 순차적으로 검색하다가 충분히 할당할 수 있는 공간이라고 판단되면, 이전에 할당된

    메모리 공간을 보다 앞으로 위치시킬 수 있는 그러한 이유가 있기 때문이죠.

Written By Sim-Hyeon, Choe
 

int array[10];

int *ptr = array;

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

2번째 라인을 int *ptr = &array;로 바꾸어 컴파일하면 에러가 발생합니다.

array는 포인터 상수로, &array와 같은 주소값을 가짐에도 불구하고 말입니다.

이유가 무엇일까요?

다음 예제를 살펴 봅시다.
-------------------------------------------------------------

class AAA
 

AAA::TestA()
{
    // 문자열 2차원 배열 선언
    char(* strResult)[15] = new char[500][15];
}

class BBB

#include "AAA.h"

AAA testa;  -> testa class 변수 선언

BBB::TestB()

{

    while( ... )
    {
        printf( "%s", testa.strResult[i] );  // 에러
    }

}

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

위의 예제에서 처럼 클래스 AAA에 선언된 배열 strResult를 어떻게 가져올 수 있을까요?

class AAA에서 다음과 같은 접근 제어 함수를 만들 수 있습니다.
 

"AAA.h" 

class AAA
{

public:

    char (*GetStrResult())[15];    // 2차원 배열 포인터를 리턴

}

"AAA.cpp"

// 클래스 AAA의 멤버인 2차원 배열 포인터를 아래와 같이 리턴할 수 있습니다.
char (*AAA::GetStrResult())[15]
{

    char (*strResult)[15] = new char[500][15]; 

    return strResult;

}

"BBB.cpp"

BBB::TestB()
{

    char (*ptr)[15] = NULL;

    while( ... )
    {

        ptr = testa.GetStrResult();

        printf( "%s", ptr + x );    // x는 출력할 문자열의 인덱스

    }

}

Written By Sim-Hyeon, Choe

보통 int형이나 float형등에 대한 레퍼런스는 쉽게 쓸 수 있습니다.

다음 예제를 살펴 봅시다.

wchar_t *abc = L"가나다라마바사";

wchar_t *abc2 = new wchar_t[256];

wchar_t abc3[256];

통상적으로 위와 같은 형태로 많이 사용합니다.

이때, 이 변수들에 대한 레퍼런스(문자열에 대한 레퍼런스)는 어떻게 할 수 있을까요?

물론, wchar_t &def = abc; 과 같은 형태는 불가능합니다.

아래와 같이 코딩하였다고 가정하겠습니다.

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

#include <iostream.h>

int main()
{
    char *i = new char[20];

    i = "asfdsadfsdaf";

    cout << i << endl;

    delete i;

    return 0;
}

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

결과 출력 후, 확인하면 delete에서 Access Violation Error가 발생합니다.

이유는 무엇일까요?

다음 예제가 있다고 가정하겠습니다.

void main()
{
    char str = { "대한님국" };    

    fncA( str );
}

// 참조에 의한 전달

void fncA(char *str)
{

     ....

}

값에 의한 전달은 어떻게 할 수 있을까요?

천천히 살펴 봅시다.

char *str = "대한민국";

Name Mangling에 대한 고찰 Written by Sim-Hyeon, Choe

32비트 컴파일러는 __declspec(dllexport) 지시자를 사용하여 DLL에서 데이터, 함수, 클래스

또는 클래스 멤버 함수를 내보낼 수 있습니다. __declspec(dllexport)는 Object 파일에 익스포트

지시문을 알아서 추가하기 때문에 별도의 모듈 정의파일(.def)를 사용할 필요가 없습니다.

그래서 __declspec(dllexport)를 정의함으로써 컴파일러에게 해당 데이터는 익스포트 될 것임을

알려주게 됩니다. 반대로 익스포트한 모듈의 함수를 사용하기 위해서는 __declspec(dllemport)로

정의하여 알려줘야 합니다.

한가지 예를 들어 보도록 하겠습니다.


MyLibrary.cpp,
MyLibrary.h

2개의 파일이 있다고 가정하겠습니다.

MyLibrary.cpp는 이 모듈의 기능을 정의한 파일입니다.

MyLibrary.h는 이 모듈의 기능에서 필요한 선언부를 담고 있는 헤더 파일입니다.


MyLibrary.h 소스의 선두
----------------------------------------
#ifndef  MYSYSAPI
#define MYSYSAPI __declspec(dllimport)
#endif

MYSYSAPI int __stdcall FuncA(int nA, int nB);
MYSYSAPI int __stdcall FuncB(int nA, int nB);
MYSYSAPI int __stdcall FuncC(int nA, int nB);
----------------------------------------

MyLibrary.cpp 소스의 선두
----------------------------------------
#define   MYSYSAPI __declspec(dllexport)
#include "MyLibrary.h"

int __stdcall FuncA(int nA, int nB)
{
       ... ...
}

int __stdcall FuncB(int nA, int nB)
{
       ... ...
}

int __stdcall FuncC(int nA, int nB)
{
       ... ...
}
----------------------------------------

위의 두 소스를 비교보면 알겠지만, MyLibrary.h는 MyLibrary.cpp와 반대로

__declspec(dllimport)를 사용한다. 소스를 컴파일한 내용으로 해석하면 MyLib

rary.cpp에서는 MYSYSAPI라는 매크로가 전처리하게 되는데, 이어 인클루드한

MyLibrary.h 헤더 파일의 내용을 전처리하는 과정을 따르게 됩니다.

MyLibrary.h 헤더 파일에서 보면, MYSYSAPI라는 매크로가 정의되어 있는지

확인하고 이미 정의되어 있기 때문에 #define MYSYSAPI __declspec(dllimport)

은 건너뛰게 됩니다. 결국 MyLibrary.cpp에서 선언 및 정의된 세 함수가 __declspec

(dllexport)로 사용되어지게 되는데요.

이 라이브러리를 Implicit Linking할 때에도 MyLibrary.h 헤더 파일을 포함해야 합니다.

하지만 여기서의 전처리 흐름은 MYSYS API 매크로가 정의된 적이 없기 때문에

__declspec(dllimport)가 되는 것입니다.

그렇다면 이렇게까지 복잡하게 전처리하고 익스포트 및 임포트하는 이유가 무엇일까요?

일단, 이렇게 정의함으로써 라이브러리를 링킹할 때에는 소스 파일에서 사용시 헤더 파일

에 컴파일러에게 일일이 __declspec(dllimport)으로 알릴 필요가 없게 되어 라이브러리

의 사용자가 더이상 관심을 가지지 않아도 될 것입니다. Win32 API를 사용하듯 필요한

함수만 호출해서 사용하면 되겠지요.

이미 위에서도 설명드렸습니다만, __declspec(dllexport)를 정의하면 별도의 .def 파일

을 생성하여 외부 정의 함수에 대한 정의도 따로 할 필요가 없게 됩니다.

그렇다면 __declspec(dllexport)로 정의한 함수의 심벌명은 어떻게 결정될까요?

Binary Dump로 익스포트 함수의 심벌 정보를 확인하면 다음과 같습니다.

_FuncA01@4
_FuncB02@4
_FuncC03@4



인간이란 망각의 동물이다.

자신의 부단한 노력으로 얻은 소중한 기억이 결국 시간이 지나갈 수록 잊혀

져버린다는 사실에 마음이 아프다.