[펌] #pragma

#pragma
--------------------------------------------
pack
#pragma pack( [ n] )

structure나 union의 맴버들에 대한 묶음 정렬 명세이다.
Specifies packing alignment for structure and union members.
Whereas the packing alignment of structures and unions is
set for an entire translation unit by the /Zp option, the
packing alignment is set at the data-declaration level by
the pack pragma. The pragma takes effect at the first
structure or union declaration after the pragma is seen;
the pragma has no effect on definitions.

When you use #pragma pack(n), where n is 1, 2, 4, 8, or 16, each structure member after the first is stored on the smaller member type or n-byte boundaries. If you use #pragma pack without an argument, structure members are packed to the value specified by /Zp. The default /Zp packing size is /Zp8.

The compiler also supports the following enhanced syntax:

#pragma pack( [ [ { push | pop}, ] [  identifier, ] ] [ n ] )

This syntax allows you to combine program components into a single translation unit if the different components use pack pragmas to specify different packing alignments.

Each occurrence of a pack pragma with a push argument stores the current packing alignment on an internal compiler stack. The pragma’s argument list is read from left to right. If you use push, the current packing value is stored. If you provide a value for n, that value becomes the new packing value. If you specify an identifier, a name of your choosing, the identifier is associated with the new packing value.

Each occurrence of a pack pragma with a pop argument retrieves the value at the top of an internal compiler stack and makes that value the new packing alignment. If you use pop and the internal compiler stack is empty, the alignment value is that set from the command-line and a warning is issued. If you use pop and specify a value for n, that value becomes the new packing value. If you use pop and specify an identifier, all values stored on the stack are removed from the stack until a matching identifier is found. The packing value associated with the identifier is also removed from the stack and the packing value that existed just before the identifier was pushed becomes the new packing value. If no matching identifier is found, the packing value set from the command line is used and a level-one warning is issued. The default packing alignment is 8.

The new, enhanced functionality of the pack pragma allows you to write header files that ensure that packing values are the same before and after the header file is encountered:

/* File name: include1.h
*/
#pragma pack( push, enter_include1 )
/* Your include-file code ... */
#pragma pack( pop, enter_include1 )
/* End of include1.h */

In the previous example, the current pack value is associated with the identifier enter_include1 and pushed, remembered, on entry to the header file. The pack pragma at the end of the header file removes all intervening pack values that may have occurred in the header file and removes the pack value associated with enter_include1. The header file thus ensures that the pack value is the same before and after the header file.

The new functionality also allows you to use code, such as header files, that uses pack pragmas to set packing alignments that differ from the packing value set in your code:

#pragma pack( push, before_include1 )
#include "include1.h"
#pragma pack( pop, before_include1 )

In the previous example, your code is protected from any changes to the packing value that might occur in include.h.

==============================================================
comment
#pragma comment( comment-type [, commentstring] )

object파일이나 실행파일 안으로 comment로 알려진 것이 놓이게
된다. comment의 종류는 아래 써있는대로 다섯가지이다.
옵션으로 주는 commentstring으로 각 comment마다 추가 정보를
줄수 있다. commentstring은 문자열이기 때문에 문자열에 관한
모든 규칙에 맞추기 위해서 " "사이에 넣도록 한다.

Places a comment record into an object file or executable
file. The comment-type is one of five predefined identifiers,
described below, that specify the type of comment record.
The optional commentstring is a string literal that provides
additional information for some comment types. Because
commentstring is a string literal, it obeys all the rules
for string literals with respect to escape characters,
embedded quotation marks ("), and concatenation.

compiler

object 파일에 컴파일한 컴파일러의 이름과 버전 숫자를 기입하게
된다. 이 코멘트는 링크에 의해서 무시된다. 만일 commentstring인자
로 이 타입을 위해 준다면 컴파일러는 경고를 띄울것이다.
Places the name and version number of the compiler in the
object file. This comment record is ignored by the linker.
If you supply a commentstring parameter for this record type,
the compiler generates a warning.

exestr

object파일로 commentstring을 기입한다. 링크시, 이 문자열은
실행파일로 놓이게 된다. 그 문자열은 실행파일이 메모리로
적재되어 실행될때에는 메모리로 로드되지는 않는다. 그러나,
파일들안에서 찍을수 있는 문자열을 찾기를 하는 프로그램에
의해 찾아질수 있다. 실행파일에 이 comment로 버전 숫자나 비슷
한 정보들을 끼워넣을수 있다.

Places commentstring in the object file. At link time,
this string is placed in the executable file. The string
is not loaded into memory when the executable file is
loaded; however, it can be found with a program that
finds printable strings in files. One use for this
comment-record type is to embed a version number or
similar information in an executable file.

lib

object 파일안에 라이브러리-찾기를 넣게 된다.
이 comment타입은 반드시 commentstring 인자가 라이브러리
의 이름이나. 링커가 그 라이브러리를 찾을수 있는 패스명을
함께 써주어야 한다.

Places a library-search record in the object file.
This comment type must be accompanied by a commentstring
parameter containing the name (and possibly the path) of
the library that you want the linker to search. Since the
library name precedes the default library-search records
in the object file, the linker searches for this library
just as if you had named it on the command line. You can
place multiple library-search records in the same source
file; each record appears in the object file in the same
order in which it is encountered in the source file.

linker

object 파일에 링커 옵션을 기입한다. 개발자는 이 comment
타입을 씀으로써 링커에게 특정 옵션을 프로젝트 세팅 대화상자
의 Linker 탭에서 설정하는 것을 대신할수 있다. 예를들어
/include 옵션은 아래와 같은 심볼로 강제로 옵션을 줄수있다.

Places a linker option in the object file. You can use
this comment-type to specify a linker option instead  
placing the option on the Link tab of the Project Settings
dialog box. For example, you can specity the /include
option to force the inclusion of a symbol:

#pragma comment(linker, "/include:__mySymbol")

user

일반적인 주석을 object 파일에 넣게 된다. commentstring인자
에는 주석글을 포함하게 된다. 이때 링크시에는 무시된다.

Places a general comment in the object file. The
commentstring parameter contains the text of the
comment. This comment record is ignored by the linker.

아래와 같은 플라그마는 링커가 EMAPI.LIB를 링킹시 찾도록
알려준다. 링커는 일딴 현재 작업중인 디렉토리를 찾아보고
LIB 환경 변수에 명세된 패스를 찾아보게된다.

The following pragma causes the linker to search for
the EMAPI.LIB library while linking. The linker searches
first in the current working directory and then in the
path specified in the LIB environment variable.

#pragma comment( lib, "emapi" )

아래의 플라그마는 컴파일러에게 컴파일러의 이름과 버전을
obj파일에 기입하도록 한다.

The following pragma causes the compiler to place the
name and version number of the compiler in the object file:

#pragma comment( compiler )

주의: comment들은 commentstring을 인자로 갖을수 있는데
매크로에서 제공하는 문자열 상수를 쓸수 있다.

Note   For comments that take a commentstring parameter,
you can use a macro in any place where you would use a
string literal, provided that the macro expands to a
string literal. You can also concatenate any combination
of string literals and macros that expand to string literals.
For example, the following statement is acceptable:

#pragma comment( user, "Compiled on " __DATE__ " at " __TIME__ )


==============================================================
bss_seg
#pragma data_seg( ["section-name"[, "section-class"] ] )


Specifies the default section for unitialized data.
The data_seg pragma has the same effect but works
with initialized or unitialized data. In some cases,
you can use bss_seg to speed up your load time by
putting all unitialized data in one section.

#pragma bss_seg( "MY_DATA" )

causes uninitialized data allocated following the #pragma
statement to be placed in a section called MY_DATA.

Data allocated using the bss_seg pragma does not retain any
information about its location.

The second parameter, section-class, is included for
compatibilty with versions of Visual C++ prior to
version 2.0, and is now ignored.

==============================================================
auto_inline
#pragma auto_inline( [{on | off}] )

Excludes any functions defined within the range where
off is specified from being considered as candidates
for automatic inline expansion. To use the auto_inline
pragma, place it before and immediately after (not in)
a function definition. The pragma takes effect at the
first function definition after the pragma is seen.
Pragma auto_inline does not apply to explicit inline
functions.


==============================================================
once
#pragma once

현재 파일에대한 명세로서, 빌드시 컴파일러에게 오직 한번만
포함될것을 보장받는다. 보통 아래와 J은 방식으로 쓰게 된다.

Specifies that the file, in which the pragma resides,
will be included (opened) only once by the compiler in
a build. A common use for this pragma is the following:

//header.h
#pragma once
// Your C or C++ code would follow:

===============================================================
optimize
#pragma optimize( "[optimization-list]", {on | off} )

이 기능은 오직 프로페셔날이나 엔터프라이즈 에디션에서만 가능하며
코드 최적화는 오직 비주얼 씨 프로페셔날과 엔터프라이즈에서만 제공된다.

Feature Only in Professional and Enterprise Edition    
Code optimization is supported only in Visual C++ Professional
and Enterprise Editions. For more information, see Visual C++ Editions.

최적화는 함수대 함수를 기초로 이루어진다.
optimize 플라그마는 반드시 함수의 밖에서 있어야 하며
그 뒤에 있을 함수들이 영향을 받게 된다.
on , off 인자를 통해서 최적화 목록안의 특정 최적화를 활성화 또는
비활성화 시킬수 있다.

Specifies optimizations to be performed on a
function-by-function basis. The optimize pragma must appear
outside a function and takes effect at the first function
defined after the pragma is seen. The on and off arguments
turn options specified in the optimization-list on or off.

The optimization-list can be zero or more of the parameters shown in Table 2.2.

Table 2.2   Parameters of the optimize Pragma

Parameter(s) Type of optimization
a 별칭이 없는것을 간주한다. Assume no aliasing.
g 전역 최적화를 가능케 한다. Enable global optimizations.
p 부동소수점 계산을 향상시킨다. Improve floating-point consistency.
s or t 짧은 혹은 빠른 기계어 코드를 생산한다.
       Specify short or fast sequences of machine code.
w 함수 호출간에서 별칭이 없는것을 간주한다.
  Assume no aliasing across function calls.
y 프로그램 스택안에 프레임 포인터를 생산한다.
  Generate frame pointers on the program stack.


/O라는 컴파일러 최적화 옵션은 아래와 같은 플라그마와 동일하다.
These are the same letters used with the /O compiler options.
For example,

#pragma optimize( "atp", on )

최적화 플라그마를 빈 문자열로 쓰게 되면 특별한 형태의 지시어가
되는데 이것은 모든 최적화를 비활성화 시키거나 원래의 기본 세팅
으로 돌려놓을수 있다.

Using the optimize pragma with the empty string (" ") is a
special form of the directive. It either turns off all
optimizations or restores them to their original (or
default) settings.

#pragma optimize( "", off )
.
.
.
#pragma optimize( "", on )