Challenge Everything

출처 : http://cafe.naver.com/orcinus/13

• CoTaskMemAlloc
• GlobalAlloc
• HeapAlloc
• LocalAlloc
• malloc
• new
• VirtualAlloc

GlobalAlloc, LocalAlloc, HeapAlloc 함수들은 궁극적으로 동일한 힙에 메모리를 할당하지만, 약간의 차이를 가지고 있다. HeapAlloc은 메모리가 할당될 수 없으면 예외를 발생시킬 수 있으며, LocalAlloc은 이런 기능이 없다. LocalAlloc은 핸들 할당을 지원함으로써 핸들값을 바꾸지않고 재할당을 통해 기초메모리 (underlying memory) 를 이동시킬 수 있으며, HeapAlloc은 이런 기능이 없다.

각각의 힙 할당자는 서로 다른 기법을 사용해 구현되었기에, 각 함수에 맞게 메모리를 해제해야 한다. 예를 들어, HeapAlloc으로 할당된 메모리는 LocalFree / GlobalFree이 아닌 HeapFree으로 해제되어야 한다.

VirtualAlloc 함수는 메모리 할당에 추가 옵션을 허용한다. 하지만 이 함수는 페이지 입도를 사용하므로, 더 많은 메모리가 소비될 수 있다.

malloc 함수는 런타임 의존적, new 연산자는 컴파일러/언어 의존적이라는 약점을 가지고 있다.

CoTaskMemAlloc 함수는 C/C++/Visual Basic 모두에서 잘 작동하는 이점을 가지고 있다. 또한 MIDL (Microsoft Interface Definition Language) 이 메모리를 마샬링*하는데 CoTaskMemAlloc / CoTaskMemFree를 사용하므로, COM 기반 애플리케이션에서 메모리를 공유하는 유일한 방법이다.

*마샬링(marshalling) : 하나 이상의 프로그램 또는 연속적이지 않은 저장공간으로부터 데이터를 모은 다음, 이들을 메시지 버퍼에 집어넣고 특정 수신기나 프로그래밍 인터페이스에 맞도록 그 데이터를 조직화하거나, 미래 정해진 다른 형식으로 변환하는 과정.

주로 한 언어로 작성된 프로그램의 출력 매개변수를 다른 언어로 작성된 프로그램의 입력으로 전달해야 하는 경우 필요하다.

읽기 전에…

 첨부파일 : StrdString.H (source)

index.chm (help file for windows)

CStdString - 표준 C++ 을 사용한 CString

출처 : http://www.codeproject.com/string/stdstring.asp

2001년 5월 29일 초안 / 2004년 8월 5일 갱신

필자 : Joe O'Leary

소개

필자는 표준 C++ 라이브러리를 애용해 오면서도, basic_string<> 템플릿 만큼은 좋아하질 않는다.

때때로 디자이너들의 한물간 방식들이 사용하기 어렵게 만드는 것 같다.

반면, 필자는 MFC의 CString 클래스를 사용하기를 즐기는 편이었다.

NULL 포인터를 체크해 주고, 암시적으로 const TCHAR* 로 변환시켜 주며, 문자열 프로그램을 사용하기에 손쉬운 멤버 함수들을 제공해 준다. ( Format(), Load() 등등 )

하지만 물론, 필자는 더 이상 MFC 를 사용하지는 않는다. 사실, 플랫폼 이식을 위해서 어떠한 독점적인 라이브러리도 사용하기를 원하지 않는다.

그래서 필자는 양쪽 세계의 장점만을 모으기로 결심했다.

그것이 클래스(사실은 템플릿) basic_string<TCHAR> 에서 상속받은 클래스 CStdString 이다.

그것은 basic_string 에 CString  전체 API 를 더한 것이다. 거기에 CString 의 사용 용이성에 basic_string 의 호환성을 보장받게 될 것이다.

간단히 말해서, CStdString 객체는 다음에 이야기할 몇몇 예외 사항을 제외하고 basic_string 이다. 그리고 CString 를 대체할 수도 있는 대체물이다.

그것들은 basic_string 과 CString 의 양쪽 API 에서 가장 잘 알려지고 많이 문서화된 부분들이다.

필자는 이 글을 수 년 전, 다른 코드 싸이트에도 올렸었다.

하지만 필자가 CodeProject 를 좋아하기에 여기에도 또한 글을 올려본다.

  필자는 본 클래스를 지난 4년간 상업적인 프로젝트들에도 사용해 왔었다.

그 결과, 이 클래스는 필자가 그 동안 만들어 것 중에 가장 유용한 것으로 증명되었다.

하지만 물론 다방면으로 디버깅되어야 할 것이다. 필자는 독자 분들도 그 점을 좋아하시기를 바란다. 어떤 문제 점이 있다면 이메일을 보내주시기를 바란다. (필자에게)

도움을 주시면 고맙겠다.

CString 함수들의 작동을 나타낸 간단한 어플리케이션 소스를 제공하였다. (하지만 정말 대용품이다.)

예제 프로젝트의 목록들은 CString 과(또는) basic_string 템플릿을 사용한다.

특징

• 일단 CString 의 대체물로써 잠깐 생각하시라. (아래 예외 사항도 보라.)
• 두 개의 항상 사용 가능한 사례 --- wchar_t 기반한 버전 CStdStringW 와 char 기반 버전 CStdStringA. CStdString 는 단지 두 개중 typedef 된 것들의 하나이다.
• CString 처럼 모든 함수에서 문자열 NULL 체크의 안정성.
• 특정 생성자와 할당 연산자는 자동으로 wchar_t 기반한 문자열과 char 기반한 문자열 간에 변환을 해 준다.
• c_str() 으로의 암시적 변환 기능. (C++ 위원회에서는 이런 방식을 권장하지 않는다.)
• Windows, UNIX, LINUX 를 포함한 몇몇 플랫폼에서의 빌딩되었다. Dinkumware, GNU, CodeWarrior, STLPort 를 포함해서 표준 C++ 라이브러리에서 구현 작동한다.
• Win32 Building 은 DCOM IStream 를 사용하는 CStdString 객체의 멤버 함수로써, UNICODE/MBCS 변환 매크로 추가 기능(MFC처럼)을 해 줄 것이다.
• 기반 클래스 템플릿인 basic_string 의 어떠한 세부 구현도 할 필요가 없다.
• 상속받은 템플릿은 basic_string 에 어떠한 멤버 변수와 가상 함수도 더하지 않는다.

그리고 이 코드에서 지적할 두 가지 주목할 점(CString 과의 호환성과 basic_string 에서의 상속)이 있다.

CString 호환성

필자는 완전하게 똑같이 CString API 와 같이 재구현할 수는 없었다.

그래서 (공유할 수 있지만 다르게 구현된) CString 와 basic_string 를 위한 두 가지 함수들로 되게 하였다.

이러한 경우에 CString 처럼 이라기보다는 basic_string 처럼 행동하는 CStdString 를 만드는 것이 최선이라고 느꼈다. (정확하게는…)

• CStdString::operator[] 는 (CString 의 by-reference 와는 다르게) by-value 문자들을 반환한다.
• 생성자는 (CString 이 선언하는 것의 반대 순서로) 순서별로 문자를 가지고 숫자를 센다. 그것은 basic_string<> 의 정렬 방식이다. 그리고 양쪽 버전 모두의 구현은 불가능할 것이다.

또한, CString 에서 구현하지 못한 두 개의 함수들이 있다. ( LockBuffer() 와 UnlockBuffer() )

basic_string<> 의로부터의 상속

필자가 작성한 basic_string 로부터 상속받은 템플릿은 가상 파괴자(virtual destructor)가 없는 클래스 템플릿이다.

어떤 C++ 에 관한 소개글들에서는 가상 파괴자가 없는 클래스는 위험하다고 말한다. 

때로는 정의되지 않은 것처럼 정의되지 않은 것처럼 해야 할 수도 있다.

다음같이 기반 클래스의 포인터를 통해 CStdStringA 를 삭제하는 것처럼 코딩할려면, 기술적으로 정의되지 않은 행동을 해야 한다.   

하지만 (개인적으로) 많이 주목할 점이라고 생각하지는 않는다.

아마도 문제는 정말 얼마나 자주 문자열 객체를 이처럼 할 것인가 하는냐는 점이다.

필자는 그 동안 거의 동적으로 문자열 객체를 힙에 할당하는 일은 없었던 것 같다.

그리고 베이스 클래스 포인터를 사용하지 않을 것이다.

이 같은 사용하지 않는다면 크게 걱정할 일은 없을 것이다.

사실 이러한 방식으로 코딩한다면 CStdString 를 사용하는 것에 문제점이 있다고 의심해 볼 만하다.

적어도 Microsoft Visual C++ 에서 이야기 하자면 에러와 메모리 누수가 없다고 이야기 할 수 있다.

아마 많은 다른 컴파일러들이 문제를 준다는 것에도 의심해 보야야 할 것이다.

하지만 필자의 의심은 C++ 세계의 현실성에 이용하지는 않을 것이다.

Caveat Emptor 씀.

 역돌이 外書

 : MFC 를 사용하여도 다음같이 문자열을 관리하는 일은 드물 것이다.

(물론 MFC 를 모르시고 Java 만 아시다면 이게 뭐가 문제야 하시겠지만…--;)

역자도

와 같은 방식보다는,

가 더 정상적인 관리라고 생각하며, 필자의 의견에 동의해 본다.  

이 팁은 담비님(천리안 FREKBS)님이 98년 12월 14일에 천리안 프로그래머포럼에 올리신 것입니다.
담비님으로부터는 전제하여 올리는 데 대해 허락을 받았습니다.
좋은 정보를 공유하도록 허락해주신 담비님께 감사드립니다.

-----------------------------------------------------------------------
안녕하세요! 담비입니다.

본 문서는 제가 가지고 있는 책과 제공된 도움말을 기초로 하여 작성되어졌습니다.
제가 영어 실력이 부족한 탓으로 내용의 이해가 약간(?)은 힘들거나, 문맥상의
오류가 있을 수 있습니다. 혹 이런 내용을 발견하시거나, 잘못된 내용을
발견하시거나, 추가되어져야 할 내용을 발견하신다면 메일 주시면 감사하겠습니다.
보내주신 내용은 검토 후 문서에 재반영하여 올리도록 하겠습니다.

frekbs@chollian.net

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
선행처리기중의 하나인 pragma에 관한 사용법을 정리하여 올립니다.
문법은 다음과 같습니다.

┏━━━━━━━━━━━┓
┃#pragma directive-name┃
┗━━━━━━━━━━━┛

#pragma는 이것을 지원하는 다른 compiler에서 방해가 없이 C++ Builder에서 원하는
지시어를 정의할 수 있도록 해줍니다. 만일 지시명을 인식하지 못한다면 에러 또는
경고 메세지를 수반하지 않고서 #pragma의 지시를 무시하게 됩니다.

Borland C++ Builder에서 지원하는 #pragma지시어는 모두 18가지가 있습니다.
이제부터 그것들을 하나 하나 살펴보기로 하겠습니다.

1. #pragma anon_struct
    . 사용법
      #pragma anon_struct on
      #pragma anon_struct off
    . Class에 익명의 구조체를 포함하여 compile하는것을 허락할 것인지를
      지시합니다. 익명이란 tag를 갖지 않는다는것을 의미합니다.
    ex)
    #pragma anon_struct on
    struct S {
       int i;
       struct {  // 익명구조체를 포함한다.
          int   j ;
          float x ;
       };
       class {  // 익명 클래스를 포함한다.
       public:
          long double ld;
       };
    S() { i = 1; j = 2; x = 3.3; ld = 12345.5;}
    };
    #pragma anon_struct off

    void main() {
       S mystruct;
       mystruct.x = 1.2;  // 포함된 data에 값을 할당한다.
   }

//--------------------------------------------------------------------------
2. #pragma argsused
    . argsused 프라그마는 함수 정의 사이에서만 허용되고 바로 다음 함수에만
      영향을 미치며 경고 메세지를 disable시킵니다.
      이 pragma를 사용하지 않은 경우 사용되지 않은 argument가 있으면
      "Parameter name is never used in function func-name"
      라는 경고 메세지를 표시하게 됩니다.
    ex)
    #pragma argsused
    void __fastcall TImageForm::FileEditKeyPress(TObject* Sender, Char &Key)
    {     if (Key == 0x13) {
             FileListBox1->ApplyFilePath(FileEdit->Text);
             Key = 0x0;
          }
    }
    위의 예에서는 함수내에서 Sender라는 인수가 사용되지 않았지만 경고 메세지가
    표시되지 않습니다.

//--------------------------------------------------------------------------
3. #pragma codeseg
    . 사용법
      #pragma codeseg <seg_name> <"seg_class"> <group>
    . codeseg 프라그마는 함수들을 위치시킬 group, class 또는 segment의 이름을
      줄수 있도록 지시합니다. 만일 option없이 사용하였다면 함수의 배치를 위해서
      default code segment가 사용되어질것입니다. 결국 이 pragma를 사용하지 않는
      경우와 동일한 결과를 가져옵니다.

//--------------------------------------------------------------------------
4. #pragma comment
    . 사용법
      #pragma comment (comment type, "string")
    . comment 프라그마는 출력되어지는 file에 주석을 기록시킬것을 지시합니다.
      comment type에 올수 있는 값들은 다음중의 하나가 될것입니다.
      * exestr
        linker가 ".OBJ" file에 string을 기록합니다. 이렇게 기록된 string은
        실행파일내부에 기록되어지며, 이것은 결코 메모리로 load되지 않습니다.
        하지만 적당한 파일 검색 유틸리티를 사용하여 실행파일에서 string을
        찾아볼 수 있습니다.
      * lib
        ".OBJ" file에 주석의 내용을 기록합니다.
        library에 새로운 module을 추가하는 경우 에만 comment 프라그마를 사용하여
        linker에게 결과 file에 명시할 수 있도록 지시할 수 있습니다. 다시 말하면
        기존에 작성되어진 module에는 comment 프라그마를 사용하여 string을 추가
        시킬수 없습니다. 새롭게 library를 작성한다면 예외일 수 있겠지요.
        linker는 최종의 library에서 string에 명시된 library module 이름을 포함
        합니다. 여러개의 module들도 이름지어질 수 있으며 이름을 만들기 위하여
        linke되어집니다.
      * user
        compiler는 ".OBJ" file에 string을 기록합니다. 하지만 linker에 의해
        string은 무시되어집니다. object 파일에만 그 내용이 남게 됩니다.

//--------------------------------------------------------------------------
5. #pragma exit
    . 사용법
      #pragma startup function-name <priority>
      #pragma exit function-name <priority>
    . 이들 두 프라그마는 프로그램이 프로그램 시동시(main이 호출되기 전) 호출
      되어야 할 함수와 프로그램 탈출(프로그램이 _exit를 통해 종료하기 바로 전)
      을 명시할 수 있도록 합니다. 명시된 function-name은 반드시 인수를 취하지
      않고 void를 return하는 미리 선언된 함수여야합니다. 다시 말하면 다음과
      같이 선언될 수 있습니다.
      void func (void);
      priority는 반드시 64-255의 범위 내에 있는 정수여야하며 최상의 우선권은
      0입니다. 0-63사이의 priority는 C library에서 사용하므로 사용자가 이를
      사용해서는 안됩니다. 최상위 우선권을 가진 함수는 시동시에 맨 먼저 호출
      되고 탈출시에 맨 마지막으로 호출됩니다. 우선권을 명시해 주지 않을 경우
      기본적으로 100의 우선권을 갖게 됩니다. pragma startup 또는 exit에 사용된
      함수명은 반드시 프라그마 라인에 도달하기 전에 정의(또는 선언)되어야함에
      주의하십시요.
    ex)
      #include <stdio.h>
      void startFunc(void)
      {
          printf("Startup Function.\n");
      }
      #pragma startup startFunc 64 //우선권 64로 시동시에 맨 먼저 호출됩니다.

      void exit Func(void)
      {
          pirntf("Wrapping up execution.\n");
      }
      #pragma exit exitFunc //기본적으로 우선권이 100으로 지정됩니다.

      void main(void)
      {
          printf("This is main.\n");
      }

//--------------------------------------------------------------------------
6. #pragma hdrfile
    . 사용법
      #pragma hdrfile "filename.CSM"
    . 이 지시어는 프리컴파일된 헤더를 저장할 파일의 이름을 설정합니다. IDE
      프로젝트를 위한 디폴트 파일명은 <projectname>.CSM이고 command line용
      으로는 BC32DEF.CSM이라는 이름을 갖습니다.  프리컴파일된 헤더를 사용하지
      않으면 이 지시어는 효력이 없으며 명령라인 컴파일러 옵션 -H=filename 또는
      프리 컴파일된 헤더를 사용하면 프리 컴파일된 헤더를 저장하기 위해 사용되는
      파일명을 변경할 수 있습니다.
      명령라인 옵션은 다음과 같습니다.
      * 프리컴파일드 헤더를 사용하는 경우
        -H=filename
      * 프리컴파일드 헤더를 사용은 하지만 새로운 프리컴파일드 헤더파일을
        변환하지 않는 경우
        -Hu
      * 프리컴파일드 헤더를 사용하지 않거나 새로운 프리컴파일드 헤더파일을
        변환하지 않는 경우. (기본값)
        -H-

//--------------------------------------------------------------------------
7. #pragma hdrstop
    . 사용법
      #pragma hdrstop
    . 이 지시어는 프리컴파일에 적합한 헤더 파일의 목록을 종료시키는데, 이것을
      사용하면 프리컴파일된 헤더가 사용하는 디스크 공간의 양을 줄일 수 있습니다.
      프리컴파일드 헤더파일은 #pragma hdrstop이 선언되기 전에 #include를
      사용하여 포함된 헤더파일들을 동일하게 프로젝트 내의 source들간에 공유시킬
      수 있습니다. 그러므로 #pragma hdrstop전에 일반적인 헤더파일들을 포함하면
      최상의 콤파일러의 성능을 얻을 수 있습니다. 확실하게 #pragma hdrstop 전에
      #include를 사용한다면 모든 source file들에게 동일하게 적용되거나 아주
      조그마한 변화만이 있을 것입니다. IDE 환경에서는 강화된 프리컴파일드 헤더의
      성능을 가지는 코드로 변환합니다. 예를 들자면 다음의 New Application의 소스
      파일인 "Unit1.cpp"는 다음과 같이 될것입니다.

      #include <vcl.h> // 일반적인 헤더파일
      #pragma hdrstop  // 헤더파일의 리스트는 여기서 끝난다.

      #include "Unit1.h" // 헤더파일의 명시
      //....
      이 pragma 지시어는 오직 source file에서만 사용하며, 헤더파일에서 사용했다
      면 아무런 효과도 없을 것입니다.

//--------------------------------------------------------------------------
8. #pragma inline
    . 사용법
      #pragma inline
    . 이 지시어는 명령 라인 콤파일러 옵션 -B 또는 IDE의 인라인 옵션과 동일
      합니다. 이것은 컴파일러에게 프로그램 내에 인라인 어셈블리 언어 코드가
      있음을 알려줍니다. 컴파일러는 #pragma inline을 만날때 -B옵션을 사용하여
      스스로 재시동하므로 이 지시어는 파일의 상단에 배치되는 것이 최선입니다.
      실제로 -B옵션과 #pragma inline을 모두 off시켜둘 수 있습니다. 그러면
      컴파일러는 asm문을 만나자마자 스스로 재시동합니다. 이 옵션과 지시어의
      목적은 컴파일 시간을 다소 절약하는 것입니다.

//--------------------------------------------------------------------------
9. #pragma intrinsic
    . 사용법
      #pragma intrinsic [-]function-name
    . #pragma intrinsic를 사용하면 함수의 inline화를 위해 command-line 스위치나
      IDE의 옵션이 무시되어집니다.  intrinsic함수를 인라인화할 때는 그 함수를
      사용하기 전에 반드시 그것을 위한 원형을 포함시켜야만 합니다. 이것은
      인라인화 할 때 컴파일러가 인라인화한 함수를 내부적으로 인식하는 함수로
      개명하는 매크로를 실제로 생성하기 때문입니다. 가령 strcpy 함수를 인라인
      화 하기 위하여 다음과 같은 문장을 사용하였다면
      #pragma intrinsic strcpy
      컴파일러는 다음과 같은 매크로를 생성합니다.
      #define strcpy __strcpy__
      컴파일러는 두 선행 밑줄과 두 후미 밑줄을 사용하여 함수 호출을 인식하고
      그 함수의 원형을 내부적으로 저장해 둔 원형과 부합시키려 합니다. 그러므로
      원형을 공급하지 않거나 공급한 원형이 콤파일러 내부의 원형과 부합되지 않을
      경우, 콤파일러는 그 함수를 인라인화 하려는 시도를 불식시키고 에러를
      발생시킵니다. 이 프라그마 사용의 궁극적인 목적은 함수 호출에 대한
      오버헤드를 줄위기 위한것입니다. 함수호출은 빨라지겠지만 그만큼 크기는
      증가하게 될것입니다.
      ex)
      #pragma intrinsic strcpy
      #pragma intrinsic -strcpy

//--------------------------------------------------------------------------
10.#pragma link
    . 사용법
      #pragma link "[path]modulename[.ext]"
    . 이 지시어는 실행화일에 파일을 링크시킬것을 링커에세 지시합니다.
      기본적으로 링커는 -L옵션으로 지정된 패스와 로칼 디렉토리에서 modulename을
      찾습니다. path 아규먼트를 이용하여 디렉토리를 지정할 수도 있습니다. 또한
      링커는 확장자를 ".obj"를 기본으로 간주합니다.

//--------------------------------------------------------------------------
11.#pragma message
    . 사용법
      #pragma message ("text" ["text"["text" ...]])
      #pragma message text
    . #pragma message는 프로그램 코드 내에서 사용자 정의 메세지를 명시합니다.
      첫번째 형식은 하나 이상의 스트링 상수들로 구성된 문장을 필요로 하고
      메세지는 괄호안에 싸여있어야만 합니다.(이 형식은 MSC와 호환됩니다.)
      두번째 형식은 경고 메세지의 문장을 위해 #pragma에 연속되는 문장을
      사용합니다. #pragma의 두가지 형태와 함께 다른 메크로의 참조는 메세지가
      디스플레이 되기전에 확장되어집니다.  사용자 정의 메세지가 디스플레이
      되는것은 기본치이며 명령 라인 옵션의 Show Warnings를 사용하여
      on/off 시킬 수 있습니다. 이 옵션은 콤파일러의 -wmsg에 해당합니다.

    ex)
      // msacm.h
      #if defined(UNICODE) && !defined(_UNICODE)
      #ifndef RC_INVOKED
      #pragma message("MSACM.H: defining _UNICODE
                       because application defined UNICODE")
      #endif
      #define _UNICODE
      #endif

      // ustring.h
      #pragma message osl/ustring.h has been replaced by winsys/string.h
      #include <winsys/string.h>

//--------------------------------------------------------------------------
12.#pragma obsolete
    . 사용법
      #pragma obsolete identifier
    . #pragma obsolete 프로그램 코드에서 pragma의 선언 이후에 마주치게 되는
      identifier의 첫번째 사용에 대해서 경고를 발생합니다. 경고는 identifier를
      쓸모없는 상태로 만듭니다.
    ex)
    // io.h
    #if !defined(RC_INVOKED)

    /* Obsolete functions */
    #pragma obsolete _chmod
    #pragma obsolete _close
    #pragma obsolete _creat
    #pragma obsolete _open
    #pragma obsolete _read
    #pragma obsolete _write

    /* restore default packing */
    #pragma pack(pop)

    #if defined(__STDC__)
    #pragma warn .nak
    #endif

    #endif  /* !RC_INVOKED */

//--------------------------------------------------------------------------
13.#pragma option
    . 사용법
      #pragma option options
      #pragma option push options
      #pragma option pop
    . #pragma option은 프로그램 원시 코드 내에 명령라인 옵션을 포함시키고자
      할 때 사용하며 push 또는 pop 옵션과 함께 사용되어질 수 있습니다.
      options는 임의의 명령라인 옵션(단, 아래에 수록된 것은 제외합니다.)이며
      하나의 지시어 내에서 여러개의 option들을 나타낼 수 있습니다.
      예를 들자면 다음과 같습니다.

      #pragma option -C
      #pragma option -C -A

      toggle option(-a, -K같은)은 comman line에서 on/off될수 있습니다.
      이들 toggle option들은 option 다음에 마침표를 두면 그 명령라인, 구성 파일,
      옵션 메뉴 설정값에 대해 옵션을 리털할 수 있으며 이를 이용하면 정확한
      설정값을 기억하지 않고도(혹은 알 필요가 없거나) 옵션을 임시로 변경했다가
      다시 그것을 디폴트로 복귀시킬 수 있습니다.

      pragma optino에 포함하여 나타날 수 없는 옵션들은 다음과 같습니다.
      -B   -c   -dname
      -Dname=string   -efilename   -E
      -Fx  -h   -lfilename
      -lexset   -M   -o
      -P   -Q   -S
      -T   -Uname   -V
      -X   -Y
      다음의 경우에 #pragmas, #indluces, #define과 약간의 #ifs를 사용할 수
      있습니다.
      * #if, #ifdef, #ifndef 또는 #elif지시어 내에서 두 밑줄로 시작하는 매크로명
        (그리고 그에 따른 내장 매크로도 가능합니다.)의 사용 전.
      * 첫번째 실재 token이 발생하기 전(첫번째 C 또는 C++ 선언문)

      특정 명령 라인 옵션은 이들 사건 앞의 #pragma option 내에서만 나타날 수
      있는데 그러한 option들은 다음과 같습니다.
      -Efilename        -f      -i#
      -m*   -npath   -ofilename
      -u   -W   -z

      다른 option들은 어디서나 변경될 수 있는데 다음 option들은 함수 또는 대상
      선언문 사이에서 변경될 경우 컴파일러에만 영향을 미칩니다.
      -1        -h      -r
      -2   -k   -rd
      -a   -N   -v
      -ff  -O   -y
      -G   -p   -Z

      다음의 option들은 언제든지 변경될 수 있으며 즉시 영향을 미칠 수 있습니다.
      -A   -gn   -zE
      -b   -jn   -zF
      -C   -K   -zH
      -d   -wxxx
      이들 option들은 그 명령 라인 상태로 재설정하기 위해 점(.)앞에 추가로
      나타날 수 있습니다.

      push 또는 pop을 사용한 #pragma option
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      또한 콤파일러 지시어들을 쉽게 변경할 수 있도록 push 그리고 pop 아규먼트들
      과 함께 #pragma option 지시어를 사용할 수도 있습니다.

      잠재적으로 많은 컴파일러 옵션과 경고들을 변경하는 파일들을 포함하기 위해
      #pragma option push를 사용할 수 있고, #pragma option pop은 단일 문장으로서
      이전의 상태를 되돌려준다. 예를 들자면 다음과 같다.

      #pragma option push
      #include <theworld.h>
      #pragma option pop
      #include "mystuff.h"

      #pragma option push 지시어는 첫번째로 모든 콤파일러 옵션들과 경고 설정들을
      스택에 push한 후에 다른 옵션들이 존재한다면 이를 처리한다. 다음의 예는
      #pragma option push가 옵션들을 사용하거나 혹은 그렇지 않을수 있음을
      보여줍니다.

      #pragma option push -C -A
      #pragma option push

      #pragma option pop directive은 스택으로부터 옵션들과 경고들의 마지막 설정
      을 pop함으로서 컴파일러 옵션과 경고들을 변경합니다. 만일 스택이 비어있고
      option pop과 일치하는 option push가 없으며 아무것도 발생하지 않은경우
      경고가 주어집니다. 다음은 빈 스택에대해서 경고를 발생시킵니다.

      #pragma option push
      #pragma option pop
      #pragma option pop      /* 경고가 발생합니다.

      권장하지는 않지만 지시어를 사용하여 이 경고를 off시킬 수 있습니다.
      #pragma warn -nop.

      만일 pop의 다음에 어떤 옵셥들을 명시할려고 한다면 에러가 발생하게되며
      pragma option pop 다음에는 어떤것도 허락하지 않습니다. 예를 들면, 다음은
      에러를 발생합니다.

      #pragma option pop -C         /* ERROR
      만일 push된 옵션들의 스택이 파일의 시작과 마지막이 동일하지 않다면
      다음과 같은 경고메세지가 발생합니다.

      Previous options and warnings not restored.

      이 경고메세지를 off시키기 위하여 지시어 #pragma nopushoptwarn를 사용할
      수 있습니다.

//--------------------------------------------------------------------------
14.#pragma pack
    . 사용법
      #pragma pack(n)
      #pragma pack(push, n)
      #pragma pack(pop)
    . #pragma pack 지시어는 콤파일러 옵션 -a와 함께 #pragma option을 사용하는
      것과 동일합니다. n은 콤파일러가 저장된 메모리에 데이터를 정렬하는 방법을
      결정하는 byte의 정렬이다. 보다 자세한 사항은 -a 콤파일러 옵션에 관한
      내용을 참고하십시요. #pragma pack은 또한 #pragma option지시어에 push나
      pop을 사용하는것과 동일한 기능을 제공 하도록 push나 pop 아규먼트와 함께
      사용할 수 있습니다.  아래의 내용은 #pragma pack과 #pragma option을 비교한
      내용입니다.
      ━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━
      #pragma pack              ┃     #pragma option
      ━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━
      #pragma pack(n)           ┃     #pragma option -an
      #pragma pack(push, n)     ┃     #pragma option push -an
      #pragma pack(pop)         ┃     #pragma option pop
      ━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━
//--------------------------------------------------------------------------
15.#pragma package
    . 사용법
      #pragma package(smart_init)
      #pragma package(smart_init, weak)
    . smart_init 아규먼트
      #pragma package(smart_init)는 패키지된 유닛들이 의존할 순서를 결정하기위해
      초기화 되어집니다.(패키지 소스파일 내에 기본적으로 포함됩니다.)
      일반적으로, 패키지들을 생성하는 .CPP 파일들에 #pragma package를 사용할 수
      있습니다.
      이 프라크마는 유닛을 콤파일하는기위한 초기의 순서에 영향을 미칩니다.
      초기화는 다음의 순서에 의하여 발생합니다.
      1. 만일 unitA가 unitB에 의존한다면 unitB는 반드시 unitA전에 초기화
         되어져야만하는 사용("uses")에 의존합니다.
      2. 링크의 순서(The link order)
      3. unit에서의 우선권의 순서.(Priority order within the unit.)

      보통의 .OBJ 파일들은(unit들로 생성하지 않은), 첫째로 우선권의 순서에 따라
      초기화가 일어나고서 링크가 됩니다. .OBJ 파일들의 링크 순서의 변경은
      글로발 오브젝트가 호출되어져 생성되는 순서에 의해 변경됩니다.

      다음의 예는 보통의 .OBJ 파일들과 unit들의 초기화에 어떤 차이점이 있는가를
      보여줍니다. 세개의 unit 파일들 A,B,C가 #pragma package(smart_init)를
      사용하여 "smart initialized"되고 우선권은 10, 20, 30의 값을 갖는다고
      예를 듭니다. 함수는 우선권의 값과 parent .OBJ에 의하여 이름지어져 a10,
      a20, a30, b10등과 같은 이름을 갖습니다. 세가지는 모두 unit들이며 A는 B와
      C를 사용하며 A,B,C의 순서로 링크되고 초기화의 순서는 다음과 같습니다.
           B10 B20 B30 C10 C20 C30 A10 A20 A30
      위와 같이 되었다면 .OBJ 파일들은 (unit들이 아니다)다음의 순서가 되어질
      것입니다.
           A10 B10 C10 A20 B20 C20 A30 B30 C30
      #pragma package(smart_init)를 사용한 .CPP 파일들은 또한 #pragma package
      (smart_init)를 정의한 .CPP 파일로부터 다른 .OBJ 파일들을 참조하는 #pragma
      link를 필요로 하며 unit에 의해 결정되어져야만 합니다. #pragma link는, 결정
      되지 않은 .OBJ는 라이브러리 등에 의하여 여전히 결정되어질 수 있도록 참조
      할 수 있습니다.
    . weak packages
      #pragma package(smart_init, weak)지시어는 .OBJ 파일이 패키지의 .BPI와
      .BPL 파일들에 정장되는 방법에 영향을 미칩니다. 만일 #pragma package(smart_
      init, weak)가 unit파일 내에 나타난다면 콤파일러는 가능하다면 BPL들로부터
      unit을 생략하고, 다른 에플리케이션이나 패키지에 의해 필요로 할 때면
      비 패키지화된(non-packaged) 로칼 복사본의 unit을 생성합니다. 유닛이 이
      지시어와 함께 콤파일 되었다는 것은 약하게 패키지화 되었음을 이야기 합니다.
      ("weakly packaged")
      #pragma package(smart_init, weak)는 동일한 외부 라이브러리(external librar
      y)들에 의존할수 있는 여러 패키지들 사이에서의 충돌을 제거하는데 사용되어
      집니다.  #pragma package(smart_init, weak) 지시어를 가지는 unit 파일들은
      글로발 변수들을 갖지 않아야 합니다.

//--------------------------------------------------------------------------
16.#pragma resource
    . 사용법
      #pragma resource "*.dfm"
    . 이 프라그마는 form unit에 의해 선정되어지는 파일로서 일치되는 .DFM 파일과
      헤더파일을 필요로 합니다. 이러한 모든 파일들은 IDE에 의해 관리되어집니다.
      만일 폼을 위한 다른 변수들을 필요로한다면 pragma resource가 사용되어지고난
      후에 즉시 선언되어져야만 합니다. 선언은 반드시 form이 되어져야만 합니다.
          TFormName *Formname;

//--------------------------------------------------------------------------
17.#pragma startup
    . 사용법
      #pragma startup function-name <priority>
      #pragma exit function-name <priority>
    . #pragma exit의 내용을 참조하십시요.

//--------------------------------------------------------------------------
18.#pragma warn
    . 사용법
      #pragma warn [+:-:.]www
    . warn지시어를 이용하면 특정 명령라인 옵션 -wxxx를 우선할 수 있습니다.
      #pragma warn -aus 스위치를 사용하면 함수 단위로 취급됩니다. 개별적인
      변수들을 위해서 함수 내부에서 경고를 off시킬수는 없습니다. 함수 전체를
      off시키거나 혹은 그렇지 않거나 둘중 하나입니다.
    ex)
    #pragma warn +xxx
    #pragma warn -yyy
    #pragma warn .zzz

    위의 예에서는 xxx경고문은 on되고 yyy경고문은 off되며 zzz경고문은 파일의
    컴파일이 시작할 때 갖고 있던 값으로 재저장됩니다.

//----- End of Document ----------------------------------------------------