[STL] 어댑터 컨테이너 : queue 사용 예제

by Blogger 하얀쿠아
2012. 6. 3. 17:51 소프트웨어 Note/C++ MFC

queue 는 어댑터 컨테이너이다.

STL에서 기본적인 구현은 내부 컨테이로 dequeue를 사용하도록 되어있다.

다음은 예제 소스


#include <queue>

#include <iostream>

using namespace std;


std::queue<std::string> buffer; //string queue

//3개의 원소 삽입

buffer.push("These ");

buffer.push("are ");

buffer.push("more than ");


//2개워 원소를 출력한다.

cout << buffer.front();

buffer.pop();


cout << buffer.front();

buffer.pop();


//두개의 새 원소를 삽입

buffer.push("four ");

buffer.push("worlds!");


//한개의 원소를 읽어온다.

buffer.pop();


//두개의 원소를 읽어들이고 출력한다.

cout << buffer.front();

buffer.pop();

cout << buffer.front() << endl;

buffer.pop();


//size print 

cout << "number of elements in the queue: " << buffer.size()<<endl;


try {

buffer.pop();

} catch(const exception& e) {

cout << "exception" << endl;

}

이 댓글을 비밀 댓글로

[STL] Vector 사용 예제

by Blogger 하얀쿠아
2012. 6. 3. 16:58 소프트웨어 Note/C++ MFC

//STL vector 예제를 위한 헤더

#include <iostream>

#include <vector>

#include <string>

#include <algorithm> 

#include <iterator>



vector<string> sentence;


sentence.reserve(5);


sentence.push_back("hello,");

sentence.push_back("how");

sentence.push_back("are");

sentence.push_back("you");

sentence.push_back("?");



//공백으로 구분하여 원소출력

copy (sentence.begin(), sentence.end(), ostream_iterator<string>(cout, " "));

cout << endl;


//세부정보

cout << "max size():" << sentence.max_size() << endl;

cout << "size(): " << sentence.size() << endl;

cout << "capacity():" << sentence.capacity() << endl;


//두번째 값과 네번째 값을 교체

swap(sentence[1], sentence[3]);


//"?" 원소 앞에 "always"를 할당한다.

sentence.insert( find(sentence.begin(), sentence.end(), "?"), "always");


//마지막에 "!" 를 할당한다.

sentence.back() = "!";

//공백으로 구분하여 원소 출력

copy(sentence.begin(), sentence.end(), ostream_iterator<string>(cout, " "));

cout << endl;


//세부정보 다시 보여줌

cout << "max size():" << sentence.max_size() << endl;

cout << "size(): " << sentence.size() << endl;

cout << "capacity():" << sentence.capacity() << endl;

이 댓글을 비밀 댓글로

[MFC] 공부중

by Blogger 하얀쿠아
2012. 6. 2. 16:30 소프트웨어 Note/C++ MFC

- 윈도우 프로그래밍의 기본

1. 윈도우 프로그래밍 모델

2. CWnd 클래스

3. MFC 코드의 기본 구조

4. MFC 코드의 흐름

5. 키보드 입력

6. 마우스 입력

7. GDI 기본

8. 비트맵과 이미지 처리

9. GDI 고급


- 컨트롤 및 기본 프레임워크

10. 메뉴/바로 가기 키/도구 모음/상태 표시줄

11. 컨트롤 윈도우의 기본

12. 버튼 컨트롤

13. 목록 상자와 콤보 상자

14. 프로그레스 컨트롤/슬라이더 컨트롤/스핀 컨트롤

15. 리스트 컨트롤/트리 컨트롤

16. 기타 컨트롤(페이저 컨트롤, 에니메이션 컨트롤, 달력컨트롤, IP 주소 컨트롤, 네트워크 주소 컨트롤, 탭 컨트롤)

17. 대화상자


- 고급 사용자 인터페이스

18. 깜빡임 방지 (Double Buffering)

19. 다중 뷰

20. MFC의 구조와 이론

21. 특별한 메시지

22. 서브클래싱과 확장 컨트롤

23. GDI+


- MFC Featrue Pack

24. 기본구조

25. Pane 윈도우

26. 비주얼 스타일

27. 확장 컨트롤(Property Grid, 확장 탭, 쉘 트리, 쉘 리스트)


- 윈도우 시스템 프로그래밍

28. 시스템 프로그래밍 기본

29. 멀티스레드

30. 커널 객체와 동기화

31. 프로세스 간의 통신

32. DLL



- 기타주제

33. 레지스트리

34. 쉘 인터페이스 다루기.

35. 디버깅

36. 데이터베이스

37. MFC를 이용한 TCP/IP 소켓 프로그래밍

이 댓글을 비밀 댓글로

Function Calling Conventions

by Blogger 하얀쿠아
2011. 12. 17. 05:22 소프트웨어 Note/C++ MFC


함수 호출 규약(Function Calling Convention)에 대하여 정리해 보자.

일단 Microsoft의 Calling Convention의 종류는 다음과 같다


Calling Convention Argument Passing Stack Maintenance Name Decoration (C only) Notes
__cdecl Right to left. Calling function pops arguments from the stack. Underscore prefixed to function names. Ex: _Foo. This is the default calling convention for C/C++
__stdcall Right to left. Called function pops its own arguments from the stack. Underscore prefixed to function name, @ appended followed by the number of decimal bytes in the argument list. Ex: _Foo@10. This is the almost system calling convention.
__fastcall First two DWORD arguments are passed in ECX and EDX, the rest are passed right to left. Called function pops its own arguments from the stack. A @ is prefixed to the name, @ appended followed by the number of decimal bytes in the argument list. Ex: @Foo@10. Only applies to Intel CPUs. This is the default calling convention for Borland Delphi compilers.
thiscall this pointer put in ECX, arguments passed right to left. Calling function pops arguments from the stack. None. Used automatically by C++ code.
Used by Com
naked Right to left. Calling function pops arguments from the stack. None. Used by VxDs.
Used by Custom Prolog and Epilog

1. __cdecl
  • 인자 파싱 : Right -> Left
  • 스택 관리 : Caller, 가변 인자 허용
  • Name Mangling : 함수 이름 앞에 _추가
    ex) _Foo
  • C와 C++ 함수의 기본 호출 규약
  • 기본 호출 규약이므로 /Gz(stdcall) 또는 /Gr(fastcall) 옵션이 켜졌을 때, 필요한 변수나 함수 이름 앞에 __cdecl을 놓으면 된다.
    /Gd 옵션은 강제로 _cdecl 규약으로 호출한다.

 

2. __stdcall

  • 인자 파싱 : Right -> Left
  • 스택 관리 : Calle
  • Name Mangling : 함수 이름 앞에 _추가, 함수 이름 뒤에 @추가 되고 @뒤에 다시 매개변수의 전체바이트에 해당하는 10진수가 추가된다.
    ex) _Foo@12
  • 거의 모든 시스템 함수에서 사용되는 호출 규칙이다.( WinAPI )
  • /Gz 옵션은 C++멤버 함수와 __cdecl 또는 __fastcall이 표시된 함수를 제외한 모든 함수에 __stdcall 호출 규칙을 지정한다. 모든 __stdcall함수는 프로토타입을 가져야 한다. 가변 인수를 취하는 함수는 __cdecl로 표시해야 한다.

 

3. __fastcall

  • 인자 파싱 : 처음 2개의 DWORD 또는 더 작은 인자들은 ecx와 edx에 전달, 나머지 인자들은 Right-> Left
  • 스택 관리 : Callee.
  • Name Mangling : 함수 이름 앞과 끝에 @가 추가되고 @뒤에 매개변수의 전체바이트에 해당하는 10진수가 추가된다.
    ex) @Foo@12
  • /Gr 옵션은 선언된 함수가 충돌하지 않고 이름이 main이 아니라면, 모듈 내 각 함수를 fastcall로 컴파일 한다.

 

4. thiscall

  • 인자 파싱 : Right -> Left, this 매개 변수가 ecx레지스터에 전달.
  • 스택 관리 : Caller.
  • Name Mangling : 없음.
  • 가변인자를 허용하지 않는 C++멤버함수의 기본 호출 규약으로 스택 끝에 this포인터를 넣으며 컴파일시 컴파일러에 의해 가변인자 함수는 __cdecl로 변경된다. thiscall은 키워드가 아니므로 thiscall 호출 규약은 명시적으로 사용할 수 없다. 모든 매개 변수들은 스택상에 놓여진다.

 

5.naked

  • 인자 파싱 : Right -> Left
  • 스택 관리 : Caller
  • Name Mangling : 없음
  • stack frame이 생략.
  • 컴파일러가 기본적으로 만들어주는 Prolog와 Epilog를 변경할 때 사용된다. naekd를 사용하게 되면 아래와 같은 Prolog와 Epilog를 컴파일러가 생성하지 않는다. 사용자가 stack frame을 할당하여 사용해야 된다. 이는 CPU와의 이식성이 없기때문에 일반 응용프로그램에서는 거의 사용되지 않는다. 주로 디바이스 드라이버를 만들 때 사용한다.

이 댓글을 비밀 댓글로

구조체 패딩 비트에 대해서. struct padding bit

by Blogger 하얀쿠아
2011. 8. 20. 21:13 소프트웨어 Note/C++ MFC

아래와 같은 구조체를 선언했다고 하자.


char 1바이트이고 int 4바이트인 시스템에서 위의 구조체를 선언하고 sizeof()로 구조체의 사이즈를 찍어보면 얼마가 나올까? 생각대로라면 5바이트가 나와야 한다. 1 + 4 = 5 이니까..

 

그런데 대부분의 컴파일러에서 실제로는 8바이트가 나온다. 이유는 패딩 비트가 추가되어서 그렇다. 몇몇 컴파일러는 구조체의 필드를 메모리에 위치 시킬 때 중간에 빈 공간 없이 쭉 이어서 할당하는 경우도 있지만, 대부분의 컴파일러는 성능향상을 위해 CPU가 접근하기 쉬운 위치에 필드를 배치한다. 그러다 보니 중간에 빈 공간이 들어가게 되는 것이다. 이 빈 공간이 바로 패딩 비트이다.

 

이에 대해서 좀 더 자세히 알아보자.

 

32비트 CPU는 메모리에서 값을 읽어 올 때 한번에 4바이트(32비트), 64비트 CPU는 한번에 8바이트(64비트)를 읽어온다.

 

32비트 CPU를 가진 시스템에서 CPU가 메모리상에 정의된 위 구조체의 a 멤버로 접근하려면 어떻게 해야 할까? 간단하다. 구조체 test의 시작번지에서 32비트를 읽어와서 그 중 맨 앞 8비트만 사용하면 된다.

 

그럼 이제 그 다음 멤버인 b에 접근하려면 어떻게 해야 할까? 이건 좀 복잡해진다. 구조체 test의 시작번지에서 32비트를 읽어와도 멤버 b의 비트에 모두 접근 할 수 없다. 그래서 두 번 메모리를 읽어서( 64비트), 첫 번째 읽은 값에서 뒤의 24비트와 두 번째 읽은 값에서 앞의 8비트를 합쳐서 멤버 b의 값을 구할 수 있다. 이렇게 하면 한번에 할 일을 두 번에 걸쳐서 하는 것이기 때문에 당연히 성능저하가 발생한다.

 

그래서 대부분의 컴파일러는 CPU가 접근하기 쉬운 메모리 위치에 필드를 배치시키기 때문에 아래와 같이 패딩 비트가 자동으로 들어가게 된다.

 

char a: 1byte

padding bit: 3bytes

int b: 4bytes

 = 8byte

위와 같이 패딩 비트가 들어가서 총 8바이트가 되면 CPU가 각 멤버에 접근할 때 한번씩만 메모리를 읽으면 각 멤버의 값을 구할 수 있다. 쓸모 없는 메모리를 3바이트나 낭비하는 꼴이 되어버리지만 CPU가 각 멤버에 접근 할 때 한번씩만 메모리를 읽으면 되기 때문에 성능저하가 발생하지 않는다.

 

하지만 패딩 비트에도 문제점이 발생한다.

구조체를 사용할 때 대부분의 경우에는 위와 같은 복잡한 패딩 비트에 대해 신경 쓸 필요는 없다. 가끔 구조체의 전체 사이즈가 프로그래머가 생각 했던 것과 다르게 나오는 게 문제가 되는 경우도 있겠지만..

 

그런데 네트워크를 통해서 구조체 자체를 전송하려고 하면 패팅 비트가 굉장히 중요한 변수가 된다. 왜냐하면 구조체가 메모리에 정의되는 형태는 OS와 컴파일러에 따라 달라지기 때문이다. 동일한 구조체를 서로 다르게 메모리에 정의하고 있는 시스템끼리 메모리에 있는 구조체 내용을 그대로 주고 받는다면 구조체의 각 멤버는 서로 다른 값을 가지게 된다.

 

패딩 비트는 삽입되는 위치가 컴파일러에 따라 달라진다. 또한 32비트와 64비트 시스템은 동일한 구조체에 대해서 삽입하는 패딩 비트의 수가 각각 다르다.

 

그럼 시스템 A(32비트)가 시스템 B(64비트)에게 아래의 구조체를 네트워크로 전송하고, 시스템 B는 받은 패킷을 아래 구조체로 캐스팅해서 그대로 사용하는 경우 어떤 문제가 생길까?

 

* 참고로 char = 1byte, long long = 8bytes

struct test_s

{

  char a;

  long long b;

} test;

 

32비트 시스템에서는 위 구조체를 사용할 때 멤버 a 뒤에 3바이트의 패딩 비트를 넣어서 구조체 사이즈가 12바이트가 된다. 반면에 64비트 시스템에서는 7바이트의 패딩 비트를 넣어서 구조체 사이즈가 16바이트가 된다.

 

따라서 구조체의 시작위치에 있는 첫 번째 멤버 a는 값이 변하지 않지만, 그 다음 멤버들은 값이 다 바뀌게 된다.

 

그럼 어떻게 하면 구조체를 네트워크로 안전하게 전송 할 수 있을까? 여기엔 두 가지 방법이 있다.

 

첫째, #pragma 또는 #packed 키워드를 사용해서 컴파일러가 패딩 비트를 사용하지 않도록 하는 방법이 있다. 하지만 이 방법은 C 표준이 아닌 관계로 이식성이 없다.

 

#pragma pack(1)

struct test_s

{

  char a;

  int c;

} test;

#pragma pack(8)

구조체 선언할 때 1 byte 단위로 pack 시킨다고 지정해 주고 선언이 끝난 후에 적절히 4 byte 8 byte (원래대로) 확장(원복) 시켜 주는 방법이다.

 

둘째, 프로그래머가 패딩 비트를 수동으로 관리해주면 된다. , 아래와 같이 구조체를 만들 때 dummy 값을 패딩비트로 넣으면 된다.

 

struct test_s

{

  char a;

  char b[3];

  int c;

} test;

 

위에서 멤버 b가 패딩 비트이다. 위 구조체는 4의 배수인 8바이트의 사이즈를 가진다. 그러나 몇 바이트를 기준으로 정렬할지는 순전히 OS와 컴파일러에 따라 달라진다. 따라서 네트워크로 구조체를 직접 보내는 방법은 올바른 방법이 아닌 것으로 생각된다.

 

그럼 하나 더 생각을 해보자. 무조건 4의 배수로만 구조체의 크기를 맞춰주면 문제가 해결이 될까?

int(4바이트)를 기준으로 맞추면 대부분의 경우 정확하다. long long 변수가 있는 경우는 8 바이트를 기준으로 맞춘다. 그러나 OS와 컴파일러에 따라서 약간의 특성을 타기 때문에 항상 보장된다고는 볼 수 없다.

 

struct test_s

{

  char a;

  char b[7];

  long long c;

} test;

 

하지만 아직 바이트오더 문제가 남아있다. 이는 아래 문서를 참조하면 된다.

http://superkkt.com/138

이 댓글을 비밀 댓글로

[MFC] 알아두면 유용한 형변환

by Blogger 하얀쿠아
2011. 6. 30. 16:28 소프트웨어 Note/C++ MFC
// CString -> int 변환
CString CNum = _T("234");
int iNum = _ttoi(CNum);

// int -> CString 변환
int iNum = 234;
CString CNum;
CNum.Format(_T("%d"), iNum);

// CString -> double
CString CNum = _T("41.53");
double dNum = _wtof(CNum);

// double -> CString
double dNum = 41.53;
CString CNum;
CNum.Format(_T("%f"), dNum);

이 댓글을 비밀 댓글로

MFC 재배포 DLL

by Blogger 하얀쿠아
2011. 6. 16. 16:12 소프트웨어 Note/C++ MFC

MFC 재배포 DLL

간단한 MFC용 ODBC을 배포하려고 하는데 필요한 DLL을 확인해보았습니다.

프로젝트 형식은 [Win32]-[Win32 콘솔 응용 프로그램]이고

템플릿 마법사(응용 프로그램 설정)에서 추가 옵션에 '미리 컴파일된 헤더'에 체크 및
공용 헤더 파일 추가 대상에 'MFC' 에 체크하였습니다.

 

미리 컴파일된 헤더(PCH) 헤더 파일인 stdafx.h에 TODO 부분에

  1. #include <afxdb.h> // MFC ODBC

를 추가하고

 

main함수가 있는 cpp 파일에

  1. CDatabase db;
    BOOL res = db.OpenEx(TEXT("~~~~));   // ~~~~부분에는 ODBC 연결 문자열이 들어갔습니다.
    if(res) {
        db.ExecuteSQL(TEXT("Insert into ABBA.dbo.user_info (id, name) values ('1', 'value');"));
    }

를 하여 Insert문을 수행하였습니다.

 

Release 모드에서 빌드를 하고(속성의 C/C++의 '코드 생성'부분의 런타임 라이브러리는 /MD로 되어 있습니다.)

런타임 라이브러리 사용 지정 방법은 MSDN의 /MD, /MT, /LD (Use Run-Time Library)를 참고하세요.


 필요한 DLL들

mfc90u.dll - MFC의 CDatabase 클래스를 사용했기 때문에 DLL에서 사용할 수 있게

msvcr90.dll - /MD 옵션으로 코드생성을 하게 되면 C Run-Time 라이브러리로 이 DLL이 필요합니다.

(참고로 VS 2008에서 개발을 할 때의 경우입니다. VS 2005라면 90대신 80이라는 숫자가 붙습니다)

 

MSDN의 C Run-Time Libraries를 보면 표준 C++ 라이브러를 사용했을 경우에 msvcp90.dll 이 필요하다고 하네요.

 배포할 DLL은 어디서 구하나?

VS2008을 설치할 때 경로를 바꾸지 않았다면

C:\Program Files\Microsoft Visual Studio 9.0\VC\redist 에 배포용 파일이 있다.

x86기반과 amd64, 디버그용 배포하지 말아야할 카테고리 3가지 폴더 아래 파일이 있다.

 
네이트온의 배포 DLL

NATEON 4.0.10.4(1481)을 기준으로 아래와 같은 dll 파일들이 배포가 된다.

(위치 : C:\Program Files\NATEON\BIN)

 nateon4.png

DIR 한 목록

2004-08-24  오후 11:14           640,000 dbghelp.dll
2005-06-28  오전 10:14           356,352 MWDatabase.dll
2005-06-28  오전 10:14           286,773 MSVCRT.DLL
2005-10-07  오전 02:17           258,352 unicows.dll
2005-10-18  오전 06:20           118,272 t2embed.dll
2006-12-01  오후 10:03           626,688 msvcr80.dll
2006-12-01  오후 10:03           548,864 msvcp80.dll
2007-03-02  오후 08:34            61,440 NateOnHook40u.dll
2007-04-04  오후 11:18           126,976 NateMessengerApiActiveX.dll
2008-08-06  오후 04:35            61,541 XecureCSP.dll
2008-08-06  오후 04:35           393,302 XecureCrypto.dll
2008-08-06  오후 04:35            41,059 XecureIO.dll
2009-08-03  오후 01:15            77,824 NateOnUnhandledExceptionFilter.dll
2009-10-19  오후 05:14           278,528 CKAppEx.dll
2010-05-07  오후 01:49           159,744 libCommonDlg_DLL.dll
2010-05-07  오후 01:49         1,052,672 NateOnResDLL_KOR.dll
2010-05-07  오후 01:49           438,272 SLDB.dll
2010-05-07  오후 01:49           561,152 SRControl.dll
              18개 파일           6,087,811 바이트

msvcr80.dll과 msvcp80.dll을 보면 VS 2005로 개발된 것을 알 수 있다.

 

이 댓글을 비밀 댓글로

[C/C++]유용한 #pragma directive

by Blogger 하얀쿠아
2011. 5. 21. 09:51 소프트웨어 Note/C++ MFC
출처 : http://eslife.tistory.com/187

※ 주의 : 아래에서 기술하는 내용은 Visual C++ 컴파일러에서만 확인된 내용입니다.


지난번 #define 팁 에 이어 이번에는 필수는 아니지만 사용할 경우 아주 편리한 #pragma 지시자를 간단하게 소개하려고 합니다.


1. 헤더 파일을 한번만 읽어 들이기


아마도 이 경우가 #pragma를 가장 널리 사용하게 된 이유 중에 하나라고 생각되는데요

저도 언제나 헤더 파일을 새로 코딩 할 때 이 한 줄을 먼저 적게 됩니다. (아주 짧고 멋집니다)

#pragma once

#pragma once 가 없을 당시에는 아래와 같이 헤더 파일 내용을 #ifndef ~  #endif 문장을 사용해서 복잡하게 써주어야 했습니다. (요 복잡한 게 한 줄로 줄었으니 사용하지 않을 수 없죠^^)

#ifndef _MY_HEADER_FILE_H_

#define _MY_HEADER_FILE_H_

// 실제헤더파일내용

 

#endif

하지만 이러한 방식은 헤더 파일마다 새로운 이름의 #define 문을 작성해야 했고 실수로 #endif 를 빼먹거나, #ifndef 과 짝을 잘못 이룬 경우 코딩과 상관없이 재앙을 불러오기 일쑤였습니다.

Visual Studio .NET 2003버전부터였던 것으로 기억되는데 프로젝트 위저드가 자동으로 만들어내는 헤더 파일에 #pragma once 가 들어 있어 그때부터 제가 만드는 헤더 파일도 이 방법을 애용하게 되었습니다.

 

2. Structure Alignment 조정하기


클라이언트 프로그램을 하다 보면 UNIX 나 기타 서버와 소켓연결을 통해 데이터를 주고 받는 경우가 많습니다. 서버와 통신을 하다 보면, 보통 UNIX 로부터 전송되는 구조체와 클라이언트 프로그램의 구조체의 Alignment를 맞춰주어야 하는 경우가 생깁니다.

#pragma 를 사용해서 구조체 Align 을 조정할 수 있다는 것을 몰랐던 시절에는 하는 수 없이 전체 프로젝트의 Align 속성을 ‘1’ 바이트로 변경하곤 했습니다.

사용자 삽입 이미지

이렇게 할 경우

-       Structure Alignment 를 기본인 8바이트로 사용할 경우보다 약간의 메모리 접근 성능이 저하되고

-       3’rd Party Library 와 구조체를 주고 받을 때 양쪽이 Alignment 가 틀려 고생할 가능성이 생기고

-       프로젝트를 신규 생성할 때마다 Alignment 값을 변경하지 않으면 이 역시 코딩과는 상관없이 서버로부터 받은 데이터가 몽땅 깨지는 현상을 만나는 문제가 있었습니다.

그래서 가급적이면 꼭 필요한 구조체에 대해서만(이 경우 서버와 통신하는 구조체) Structure Alignment 를 조정하는 것이 좋습니다.

#pragma pack 을 사용하면 특정 구조체만 간단하게 Alignment 속성을 바꿀 수 있습니다.

#pragma pack(push, 1)

struct ABC

{

           int BaseOption1;

           int BaseOption2;

           int BaseOption3;

           char szText[100];

           BYTE szAddress[100];

};

#pragma pack(pop)

#pragma pack 의 괄호 안에 들어가는 숫자 ‘1’ 1바이트로 Alignment 를 하라는 지시이고, #pragma pack(pop)은 이전 상태(디폴트가 8 바이트 Alignment 이면 8 바이트)로 돌아가라는 지시어입니다.

알고 보면 너무 간단한데 몇 년 동안 이 방법을 몰라 고생했더랬습니다.

 

3. 귀찮고 처치 곤란한 경고 메시지 없애기


좋은 프로그램을 작성하는 개발자라면 늘 Warning Level 을 최고로 올려 빌드 하실 텐데요

이 경우 의미 없는 경고도 어쩔 수 없이 많이 만나게 됩니다.

특히 .NET 2005 에서는 버그인지 모르겠지만, 주석문에 들어 있는 한글을 만나면 희한한 경고를 만나게 되는 경우가 많습니다.

warning C4819: The file contains a character that cannot be represented in the current code page (949). Save the file in Unicode format to prevent data loss

가능한 모든 경고는 없애야겠지만, 어쩔 수 없이 무시하고 넘겨야 하는 경고들도 있는데 이런 경고들은 다음 번 빌드부터는 보지 않도록 아래와 같이 지정할 수 있습니다.

#pragma warning (disable:4819)

위 내용은 4819 오류 경고 표시를 하지 말라는 뜻으로 쓰입니다. 이 경우도 push pop 을 사용해서 특정 소스에서만 경고가 안 나오게 설정할 수도 있습니다.

 

4. 라이브러리 링크하기

사용자 삽입 이미지

일반적으로 라이브러리를 링크하는 방법은 프로젝트 Linker 옵션에서 사용할 프로젝트 라이브러리를 지정해 주는 방식을 많이 사용합니다.

#pragma 를 사용하면, 프로그램 소스에서 직접 다른 라이브러리를 링크할 수 있습니다.

#pragma comment( lib, "../TEST_DLL/release/Testdll.Lib" )

이 방식은 프로젝트 속성창 > 링크옵션 > Testdll.lib 를 추가하는 것과 동일한 방식으로 라이브러리를 링크합니다.

프로젝트 속성을 통해 링크를 지정하는 방식과, #pragma 를 통해 링크를 지정하는 것 중 저희는 후자를 선호합니다.

후자와 같이 프로그램 소스에 링크 정보가 있을 경우 특정 모듈에 대한 종속정보를 단순히 소스 검색을 통해서 확인할 수 있고 프로젝트가 변경, 확장, 제거 될 때 마다 매번 프로젝트 속성을 재차 확인해야 하는 번거로움도 없어 자주 사용하게 되더군요

 

그외에도 MSDN에서 #pragma 를 찾아 보면 상당히 많은 지시자가 있는데 혹 공유할만한 내용 있으시면 많은 지적 바랍니다

Tags
이 댓글을 비밀 댓글로