2009년 03월 01일
namespace를 사용 시 전방선언 할 때 error C2872에 대해서

namespace로 쌓여 있는 클래스에서 쌓여있지 않은 클래스를 전방선언해서 사용할 때 error C2872가 발생하였습니다.
아래는 output 창에 나타난 빌드내용입니다.


------ Build started: Project: CompilerErrorC2872, Configuration: Debug Win32 ------

Compiling...
NamespaceOuterClass.cpp
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceOuterClass.cpp(8) : error C2872: 'CCommonClass' : ambiguous symbol
        could be 'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\CommonClass.h(7) : CCommonClass'
        or       'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.h(15) : Namespace::CCommonClass'
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceOuterClass.cpp(9) : error C2664: 'Namespace::CNamespaceInnerClass::CNamespaceInnerClass(Namespace::CCommonClass *)' : cannot convert parameter 1 from 'CCommonClass *' to 'Namespace::CCommonClass *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Generating Code...
Compiling...
NamespaceInnerClass.cpp
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.cpp(8) : error C2872: 'CCommonClass' : ambiguous symbol
        could be 'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\CommonClass.h(7) : CCommonClass'
        or       'd:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.h(15) : Namespace::CCommonClass'
d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.cpp(9) : error C2511: 'Namespace::CNamespaceInnerClass::CNamespaceInnerClass(CCommonClass *)' : overloaded member function not found in 'Namespace::CNamespaceInnerClass'
        d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\NamespaceInnerClass.h(18) : see declaration of 'Namespace::CNamespaceInnerClass'
Generating Code...

Build log was saved at "file://d:\Programming\cpp\study\CompilerErrorC2872\CompilerErrorC2872\Debug\BuildLog.htm"
CompilerErrorC2872 - 4 error(s), 0 warning(s)


---------------------- Done ----------------------

    Build: 0 succeeded, 1 failed, 0 skipped



빌드 내용을 살펴 보면 CCommomClass의 선언이 모호해서 compiler가 어떤 CCommonClass를 선택하여 빌드를 해야 할 지 모른다는 내용입니다. NamespaceOuterClass와 NamespaceInnerClass에서 에러 발생하고 있지만 NamespaceOuterClass의 소스 내용을 분석해 보니 이 클래스에는 문제의 소지가 전혀 없어 보입니다. 그래서 CNamespaceInnerClass를 살펴보니 문제의 소지가 다분해 보이는 코드를 발견하였습니다.

그럼, 어디가 문제였을까요? 일단 클래스 다이어그램과 문제의 코드를 보여드릴테니까 한 번 고민해보세요 ~~


// CNamespaceInnerClass.h

namespace Namespace
{

class CCommonClass;

class CNamespaceInnerClass
{
public:
 CNamespaceInnerClass(CCommonClass* arg_pCommonClass);
 ~CNamespaceInnerClass(void);

protected:
 CCommonClass* m_pCommonClass;

};

}


답을 찾으셨나요?? 정답은 class CCommonClass의 선언 위치였습니다. 위 클래스 다이어그램을 살펴보시면 CCommonClass는 Namespace라는 namespace에 속해 있는 클래스가 아닙니다. 그런데 이 클래스를 namesapce Namespace 내부에 선언을 해뒀기 때문에 error C2872가 발생한 것이었습니다.

아래는 이 문제를 해결 한 코드입니다.


// CNamespaceInnerClass.h

class CCommonClass;    // namespace Namespace 밖으로 선언을 옮겼습니다.

namespace Namespace
{

 

class CNamespaceInnerClass
{
public:
 CNamespaceInnerClass(CCommonClass* arg_pCommonClass);
 ~CNamespaceInnerClass(void);

protected:
 CCommonClass* m_pCommonClass;

};

}



* 예제 프로젝트

    CompilerErrorC2872.zip

by greenfrog | 2009/03/01 15:34 | C++ / WIN32 / MFC | 트랙백(12514) | 덧글(1)
2009년 03월 01일
STL 맵을 이용하여 벡터의 중복 된 데이터 제거하기

데이터를 다루다 보면 벡터에 중복 된 데이터를 제거해야 할 경우가 발생합니다. 중복 된 데이터를 제거하는 방법이야 여러가지가 있겠지만 STL 맵을 이용하여 중복 된 데이터를 제거하는 방법에 대해서 알아보겠습니다.

먼저, 상황을 아래와 같이 만들어 보았습니다. 아래 배열 x1과 x2의 각 인덱스의 값은 서로 쌍으로 이용됩니다. 즉, x1[0]과 x2[0]의 값이 서로 쌍으로 이용됩니다. 이 경우 (x1[0], x2[0])의 값과 (x1[1], x2[1])의 값은 서로 중복 되므로 (x1[0], x2[0])의 값만 남기고 (x1[1], x2[1])의 값은 버리려고 합니다. 이때, STL  맵을 이용하여 중복 된 데이터를 제거한 후 남긴 데이터를 벡터에 담아 보도록 하겠습니다.


double x1[] = {-1.00, -1.00, -1.00, -1.00, -0.33, -0.33, 0.33, 0.33, 1.00, 1.00, 1.00, 1.00};
double x2[] = {-0.89, -0.89, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.89, 0.89};


STL 맵 중 멀티 맵이 아닌 일반 맵은 중복 Key를 허용하지 않습니다. 즉, 같은 Key의 데이터를 삽입하려고 하면 삽입이 되지 않지요. 이 원리를 이용하면 위 배열의 중복 된 값을 쉽게 제거할 수 있습니다. (x1[0], x2[0])의 데이터를 문자열로 변환 후 이 값을 키로 만듭니다. 예를 들어 "-1.00#-0.89" 처럼 말이죠. 이때, 반드시 중간에 '#'과 같은 구분자를 주도록 합니다. 이렇게 구분자를 넣어주는 이유는 0.0이란 값과 10이란 값을 위의 방법으로 문자열로 변환 하는 경우 "0.010"이란 값이 나옵니다. 그런데 0.01이란 값과 0이란 값 또한 위 방법으로 문자열로 변환하면 "0.010"이 됩니다. 이럴 경우를 대비하여 각 값 간 사이에 구분자를 꼭 붙여주도록 합니다. 이렇게 Key를 만들었으면 값으로 현재 배열의 index를 줍니다. 그럼 중복 되는 값의 배열 index는 제외한 체 map에 삽입이 되게 됩니다. 그 후 맵을 순회 하면서 map의 저장 된 value 즉, 배열의 index를 각 배열에 적용하여 중복 된 데이터의 첫번째 값만 빼내어 vector에 담습니다.

위 설명을 그림으로 표현하면 아래와 같습니다.


위 설명을 소스로 구현해 보았습니다.


// RepeatDataFilter.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <map>
#include <vector>
#include <string>

using namespace std;

template<typename T>
void RepeatDataFilter(const vector<T>& arg_refVtrInX1, const vector<T>& arg_refVtrInX2, vector<T>& arg_refVtrOutX1, vector<T>& arg_refVtrOutX2)
{
 map<string, int> mFilter;
 TCHAR szBuf[100];

 int nSize = (int) arg_refVtrInX1.size();
 for(int i=0; i<nSize; i++)
 {
  memset(szBuf, 0, sizeof(TCHAR));

  _stprintf(szBuf, _T("%f#%f"), arg_refVtrInX1[i], arg_refVtrInX2[i]);
  pair<string, int> item(szBuf, i);
 
  mFilter.insert(item);
 }

 map<string, int>::iterator it;
 for(it = mFilter.begin(); it != mFilter.end(); it++)
 {
  arg_refVtrOutX1.push_back(arg_refVtrInX1[it->second]);
  arg_refVtrOutX2.push_back(arg_refVtrInX2[it->second]);
 }
}

int _tmain(int argc, _TCHAR* argv[])
{
 double x1[] = {-1.00, -1.00, -1.00, -1.00, -0.33, -0.33, 0.33, 0.33, 1.00, 1.00, 1.00, 1.00};
 double x2[] = {-0.89, -0.89, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.89, 0.89};

 vector<double> vtrInitX1, vtrInitX2;
 vector<double> vtrX1, vtrX2;

 int nArr = (int) (sizeof(x1) / sizeof(double));

 for(int i=0; i<nArr; i++)
 {
  vtrInitX1.push_back(x1[i]);
  vtrInitX2.push_back(x2[i]);
 }

 RepeatDataFilter<double>(vtrInitX1, vtrInitX2, vtrX1, vtrX2);

 TRACE(_T("\n\n=========================================================\n\n"));
 size_t nSize = vtrX1.size();
 for(size_t i=0; i<nSize; i++)
 {
  TRACE(_T("\n%5.2f\t%5.2f"), vtrX1[i], vtrX2[i]);
 }
 TRACE(_T("\n\n=========================================================\n\n"));

 return 0;
}



*결과



=========================================================


-0.33  0.00
-1.00 -0.89
-1.00  0.00
 0.33  0.00
 1.00  0.00
 1.00  0.89

=========================================================


* 예제 프로젝트

    RepeatDataFilter.zip
by greenfrog | 2009/03/01 14:33 | C++ / WIN32 / MFC | 트랙백 | 덧글(0)
2009년 02월 22일
MFC ActiveX Control in IE Doesn't Detect Keystrokes

예전에 ActiveX Control을 이용해서 차트 컨트롤을 개발한 적이 있었습니다. ActiveX control에 올라간 Edit control에 키보드 입력을 통해 좌표를 입력하면 차트가 입력한 좌표에 따라 변화 하는 기능을 추가할때였는데 도통 키보드 메시지가 받아지지 않았습니다. 당근, 문제를 해결하기는 했으나 그 문제에 대해 문서화를 시켜 놓지 않았더니 같은 문제가 최근에 발생했을때 다시 삽질을 해댔지 뭡니까!! 문서화의 중요성 다시 한 번 마음에 새기게 됩니다. ㅡㅡ;;

제가 만든 ActiveX Control의 클래스 다이어그램을 소개하면 아래의 그림과 같습니다. CMyAcitveXView에는 Edit control이 있고 이에 차트 좌표를 입력하고 Enter 또는 Tab 키를 입력하면 좌표값이 차트 Control로 입력되어 차트가 변화하도록 되어있습니다. 하지만 키보드 메세지를 CMyAcitveXView의 CEdit Control은 받지 못합니다.


아래는 이 문제에 대한 Microsoft 고객지원 사이트의 기술문서 링크입니다.

MFC ActiveX Control in IE Doesn't Detect Keystrokes

그럼, 위 기술문서를 통해 이 문제를 해결하는 방법에 대해서 하나씩 알아보도록 하겠습니다.

SYMPTOMS

Accelerator keys, such as ARROW keys, are first received by the message pump of the ActiveX control's container. Even if the control has the focus, it does not receive messages for keystrokes that have special meaning to control containers, such as ARROW and TAB keys. MFC ActiveX controls have a chance to intercept these messages by overriding their PreTranslateMessage function.

However, PreTranslateMessage is not always called for an MFC ActiveX control.



증상

화살표키와 같은 엑셀레이터 키들은 ActiveX control's container의 메시지 펌프로 처음 전달 됩니다. 비록 control이 포커스를 받고 있다고 하더라도 키보드 메시지는 control로 전달되어지지 않습니다. MFC ActiveX control들은 이러한 키보드 메시지를PreTranslateMessage 함수를 오버라이딩 하므로써 키보드 메시지를 가로챌 수 있습니다.

그러나, PreTranslateMessage는 MFC ActiveX control에서는 항상 호출 되지 않습니다.



CAUSE

PreTranslateMessage in an MFC ActiveX control is called by the TranslateAccelerator method of the IOleInPlaceActiveObject interface of the control. Internet Explorer only calls this method for the control that is currently UI-Active. Only one control can be UI-Active at a time.

Internet Explorer does not automatically UI-Activate any controls when a page is first loaded. Internet Explorer waits until the user tabs to an ActiveX control on the page to UI-Activate it. Also, MFC ActiveX controls UI-Activate themselves when they are clicked with the mouse. In an MFC ActiveX control, this is done in COleControl::OnLButtonUp.

If you have a child control inside your COleControl, mouse-click messages on the child control are not sent to the COleControl and MFC does not UI- Activate the ActiveX control, even though the child control has just been given the keyboard focus. Internet Explorer intercepts the keystrokes and does not give the control a chance to filter them in PreTranslateMessage.



원인

MFC ActiveX control의 PreTranslateMessage 함수는 control의 IOleInPlaceActiveObject interface의 TranslateAccelerator method에 의해서 호출 됩니다. Internet Explorer는 오직 현재 활성화 된 control을 위해 이 method를 호출합니다. 한 번에 오직 하나의 control만이 활성화 될 수 있습니다.

Internet Explorer는 웹 페이지가 처음으로 로드되었을 때 어떠한 control들도 자동으로 활성화 시키지 않습니다. Internet Explorer는 사용자가 user tabs(이게 사용자가 탭키를 누르는것을 이야기하는건지 아니면 다른 의미가 있는건지 모르겠네요 ㅡㅡ??) 웹 페이지의 ActiveX control을 활성화 시킬때 까지 대기합니다. 또한, MFC ActiveX controls 마우스 클릭을 통해서도 활성화가 됩니다.
MFC ActiveX control은 COleControl::OnLButtonUp 메시지가 완료되었을때 활성화 됩니다.

만약 당신의 COleControl이 내부에 child control (제가 소개한 클래스 다이어그램에서 CMyActiveXView에 해당합니다.)을 가지고 있고 마우스 이벤트가 child control에서 발생한다면 이 메시지는 COleControl에게 보내지지 않으며 MFC는 child control이 키보드 포커스를 가지고 있다고 하더라도 ActiveX control을 활성화 시키지 않습니다. Internet Explorer가 키보드 메시지를 가로채서 control이 PreTranslateMessage함수가 메시지를 가져올 기회를 주지 않기 때문입니다.



RESOLUTION

Here is a typical PreTranslateMessage. This code forwards ARROW, HOME, and END keys back to the control so that they can be received using a MESSAGE_MAP entry: 

   // trap keys and forward on to the control
   BOOL CMyActiveXCtrl::PreTranslateMessage(MSG* pMsg)
   {
      switch (pMsg->message)
      {
         case WM_KEYDOWN:
         case WM_KEYUP:
            switch (pMsg->wParam)
            {
               case VK_UP:
               case VK_DOWN:
               case VK_LEFT:
               case VK_RIGHT:
               case VK_HOME:
               case VK_END:
                  SendMessage (pMsg->message, pMsg->wParam, pMsg->lParam);
                  // Windowless controls won't be able to call SendMessage.
                  // Instead, just respond to the message here.
                  return TRUE;
            }
            break;
      }
      return COleControl::PreTranslateMessage(pMsg);
   }



해결

아래 코드는 일반적인 PreTranslateMessage함수 입니다. 이 코드는 화살표, HOME, 및 END 키들을 control의 MESSAGE_MAP 항목을 사용하여 받아 사용할 수 있도록 전달합니다.

저 같은 경우는 Enter키와 Tab키에서 CEdit control의 값을 얻어와야 하므로 위 MS 기술문서의 코드를 아래와 같이 고쳐서 사용하였습니다.

   // trap keys and forward on to the control
   BOOL CMyActiveXCtrl::PreTranslateMessage(MSG* pMsg)
   {
      switch (pMsg->message)
      {
         case WM_KEYDOWN:
         case WM_KEYUP:
            switch (pMsg->wParam)
            {
               case VK_TAB:
               case VK_RETURN:
                  pView->GetPoint();
                  return TRUE;
            }
            break;
      }
      return COleControl::PreTranslateMessage(pMsg);
   }



If you have a child control within your ActiveX control, you need to UI-Activate the whole control whenever that child control is activated. For example, if you have an edit control inside your ActiveX control, add a handler as follows to your ActiveX control class:

int CMyActiveXCtrl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT message)
{
    if (!m_bUIActive)
        OnActivateInPlace (TRUE, NULL); // == UI-Activate the control
    return COleControl::OnMouseActivate(pDesktopWnd, nHitTest, message);
}



만약 당신의 ActiveX control이 child control을 가지고 있다면, 모든 control이 활성화 될 때는 언제나 child control도 활성화 될 필요가 있습니다. 예를 들어 만약 당신의 ActiveX control 내부에 edit control이 있다면, 아래 핸들러를 당신의 ActiveX control 클래스에 추가합니다.



Because Internet Explorer may not immediately UI-Activate a control, even if that is the only control on the page, it may be desirable to automatically request a UI-Activation when the control is created. This can be done during the COleControl::OnCreate (WM_CREATE) handler. Windowless controls do not get WM_CREATE or any windows messages; therefore, this code won't work in a windowless control. Also note that this does not guarantee that a control will remain UI-Activated. If there are other controls on a page that request UI-Activation in a similar manner, only one will eventually be UI-Activated and receive keystroke messages as described. And if the user TABs away from an ActiveX Control, Internet Explorer will automatically UI-deactivate the control.
int CMyActiveXCtrl::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
    if (COleControl::OnCreate(lpCreateStruct) == -1)
        return -1;
    OnActivateInPlace (TRUE, NULL); // == UI-Activate the control
    return 0;
}



Internet Explorer는 웹 페이지에 오직 control 뿐이라고 해도 즉시 control을 활성화 시키지 않기 때문에 control이 생성되자 마자 활성화 시키는 것이 바람직하다고 할 수 있겠습니다. 이 방법은 COleControl::OnCreate (WM_CREATE) handler를 통해서 구현 될 수 있습니다. 윈도우가 없는 control들은 WM_CREATE 또는 어떠한 윈도우 메시지도 받을 수 없기 때문에 윈도우가 없는 control의 경우 아래의 코드는 무의미합니다. 또한 이 코드가 control이 활성화를 유지하도록 보장하지는 않습니다. 만약 다른 control들이 웹 페이지 상에서 같은 방법으로 활성화 되었다면, 오직 하나만 마지막으로 활성화 될 것이고, 키보드 메시지를 받을 수 있을 것입니다. And if the user TABs away from an ActiveX Control, (해석이 안되네요 ㅡㅡ;;) Internet Explorer 자동으로 control을 활성화 시킬 것입니다.


위 방법대로 소스코드를 수정하고 테스트해 본 결과 아주 잘 동작을 합니다. 굳!!
by greenfrog | 2009/02/22 14:43 | C++ / WIN32 / MFC | 트랙백 | 덧글(3)
2009년 02월 13일
전방 선언에 대해서

전방 선언에 대해서 알아보았습니다. 웹에 게시 된 글들을 여러개 살펴 보았는데 아래의 이유에 의해서 사용된다는 결론을 내리게 되었습니다.


불필요한 헤더 파일이 복잡하게 포함되는 것을 방지하며, Compile 속도를 향상 시켜줍니다.


그럼, 위의 결론을 아래와 같은 클래스 구조를 가정하여 설명하도록 하겠습니다.

위 클래스 구조를 보면 CUser클래스가 CManager 클래스를 사용하고 있고 CManager 클래스는 CModuleOne과 CModuleTwo 클래스를 사용하고 있습니다. 이 경우 CUser클래스는 CManager클래스를 사용하는 동시에 이 클래스를 통해서 CModuleOne과 CModuleTwo의 기능을 사용할 것입니다. 결국 CUser 클래스는 CManager 클래스만 알면 되는 것이지요. 만약, CManager 클래스가 CModuleOne과 CModuleTwo 클래스를 멤버변수로 관리하고 있다고 가정할때 전방선언을 하지 않고 헤더파일을 직접 포함하고 있다면 어떻게 될까요? CUser는 굳이 포함할 필요가 없는 CModuleOne 클래스와 CModuleTwo 클래스의 헤더파일들을 포함하게 되어버립니다. 즉, 아래 코드와 같이 되어버리는 것이지요.

아래는 CManager클래스의 헤더파일 내용입니다.


#pragma once

#include "ModuleOne.h"
#include "ModuleTwo.h"

class CManager
{
public:
 CManager(void);
 ~CManager(void);
};

아래는 CManager클래스의 헤더파일을 포함하고 있는 CUser클래스의 cpp 내용입니다.

#include ".\user.h"
#include "Manager.h"

CUser::CUser(void)
{
}

CUser::~CUser(void)
{
}


이는 곧 컴파일 속도를 저해하는 원인이 됩니다. 이유에 대해서 예를 들면, CModuleTwo 클래스를 수정했을 경우 이를 직접적으로 사용하고 있는 CManager 클래스만 함께 컴파일 되면 되는데 이를 직접적으로 사용하고 있지 않음에도 불구하고 CManager클래스의 헤더에 CModuleTwo클래스의 헤더가 포함되어 있기 때문에 CUser 클래스까지 함께 컴파일이 되어버리기 때문입니다.

아래는 위 코드를 컴파일 한 후, CModuleTwo 클래스를 수정하여 다시 컴파일 한 결과 입니다. ModuleTwo.cpp와 Manager.cpp와 함께 User.cpp도 컴파일 되는 것을 확인 하실수 있습니다.


------ Build started: Project: ForwardDeclaration, Configuration: Debug Win32 ------

Compiling...
User.cpp
Generating Code...
Skipping... (no relevant changes detected)
ModuleTwo.cpp
Manager.cpp

Linking...


그럼 위의 문제의 코드를 전방선언으로 고쳐주면 어떻게 될까요? 아래의 코드를 보면 전방선언을 통해 CModuleOne클래스와 CModuleTwo클래스의 헤더를 CManager 클래스의 cpp파일에 숨겼기 때문에 CUser클래스에서는 불필요하게 CModuleOne클래스와 CModuleTwo클래스의 헤더파일이 포함 되는 것을 방지하고 있는 것을 알 수 있습니다.


아래는 CManager클래스의 헤더파일 내용입니다.

#pragma once

class CModuleOne;
class CModuleTwo;


class CManager
{
public:
 CManager(void);
 ~CManager(void);
};

아래는 CManager클래스의 헤더파일을 포함하고 있는 CUser클래스의 cpp 내용입니다.

#include ".\user.h"
#include "Manager.h"


CUser::CUser(void)
{
}

CUser::~CUser(void)
{
}


이는 컴파일 속도의 향상으로 이어집니다. 전방선언을 하지 않고 헤더파일을 직접 포함하고 CModuleTwo 클래스를 수정한 후 컴파일 할 때와 동일하게 전방선언을 하고 CModuleTwo 클래스를 수정한 후 컴파일을 해 보았습니다. 결과는 아래와 같습니다. 헤더파일을 직접 포함한 경우는 User.cpp도 함께 컴파일 되었었지만 이번에는 컴파일에서 제외 되었습니다.


------ Build started: Project: ForwardDeclaration, Configuration: Debug Win32 ------

Compiling...
ModuleTwo.cpp
Generating Code...
Skipping... (no relevant changes detected)
Manager.cpp
Linking...


위 예제는 간단한 클래스로만 이루어졌기 때문에 헤더파일이 복잡하게 얽히는 문제와 컴파일 속도의 향상에 대한 논점이 크게 부각이 되지 않겠지만 이를 실제 프로젝트에 연결지어 생각해 보면 전방선언의 효율성에 대해서 알 수 있습니다.

* 참고 사이트

    김재호의 디지털보단 아날로그 - 전방선언과 컴파일 의존성

by greenfrog | 2009/02/13 23:16 | C++ / WIN32 / MFC | 트랙백 | 핑백(2) | 덧글(0)
2009년 02월 13일
Buffer overflow에 의해 프로그램이 죽는 현상

다음은 Buffer overflow를 일으킬 수 있는 코드의 일부 입니다. 물론 개발자의 실수로 만든 코드입니다. 일단 한 번 보실까요 ~


#define BUF  4
#define _BUF 6


     int nArray[BUF];
     ZeroMemory(nArray, sizeof(int) * _BUF);



위 코드를 잠깐만 보시더라도 금방 문제점을 찾아 내실 수 있으실 것 입니다. nArray 배열은 int형 4개의 메모리 공간을 할당받았지만 메모리를 초기화 시켜줄때 그만 6개의 공간을 초기화 해버리고 말았습니다. 즉, Buffer overflow가 일어난 것입니다. Buffer overflow의 위험성에 대해서는 두번 세번 강조해도 전혀 지나치지 않을 정도로 심각한 문제를 야기 합니다. 예를 든다면, 위 코드에서 침범한 int형 2개의 공간에 프로그램을 운영하는데 있어서 중요한 데이터가 저장되어 있었다면 프로그램이 실행 도중 죽는 다던가 아니면 아예 실행이 안된다던가 그것도 아니면 프로그램을 종료시킬 때 어떠한 문제가 발생해서 그 동안 프로그램을 이용하면서 기록해 두었던 데이터들이 전부 날아가 버릴지도 모릅니다. 방금 든 예는 제가 이틀 전에 겪었던 현상이었습니다. 저런 실수에 대해서는 생각도 못하고 디버깅하다 결국 과장님께서 찾아주셨는데 어찌나 부끄럽던지 모릅니다.

위 내용을 간단히 그림으로 표현하면 아래와 같습니다.



by greenfrog | 2009/02/13 21:44 | C++ / WIN32 / MFC | 트랙백 | 덧글(0)


<< 이전 페이지 | 다음 페이지 >>