VMS Help
CXX, Language Topics
*Conan The Librarian
|
This section discusses language topics.
Built-in functions allow you direct access hardware and machine
instructions to perform operations that are cumbersome, slow, or
impossible in pure C.
These functions are efficient because they are built into the C++
compiler. This means that a call to one of these functions does
not result in a reference to a function in the C run-time library
or in your programs. Instead, the compiler generates the machine
instructions necessary to carry out the function directly at
the call site. Because most of these built-in functions closely
correspond to single Alpha or I64 machine instructions, the
result is small, fast code.
Some of these functions (such as those that operate on strings or
bits) are of general interest. Others (such as the functions
dealing with process context) are of interest if you are
writing device drivers or other privileged software. Some of the
functions are privileged and unavailable to user mode programs.
Be sure to include the <builtins.h> header file in your source
program to access these built-in functions.
C++ supports the #pragma builtins preprocessor directive for
compatibility with VAX C, but it is not required.
Some of the built-in functions have optional arguments or allow
a particular argument to have one of many different types.
To describe different valid combinations of arguments, the
description of each built-in function may list several different
prototypes for the function. As long as a call to a built-in
function matches one of the prototypes listed, the call is valid.
Furthermore, any valid call to a built-in function acts as if the
corresponding prototype was in scope, so the compiler performs
the argument checking and argument conversions specified by that
prototype.
The majority of the built-in functions are named after the
machine instruction that they generate. For more information
on these built-in functions, see the documentation on the
corresponding machine instruction. In particular, see that
reference for the structure of queue entries manipulated by the
queue built-in functions.
The C++ built-in functions available on OpenVMS Alpha systems
are also available on I64 systems, with some differences. There
are also built-in functions specific to I64 systems. For more
information on built-in functions, see "Built-In Functions" in
the HP C++ User's Guide for OpenVMS Systems.
Translation_Macros
C++ for OpenVMS Alpha and I64 systems does not support the VAX
C built-in functions. However, the <builtins.h> header file
contains macro definitions that translate some VAX C builtins
to the equivalent C++ for OpenVMS Alpha builtins. Consequently,
the following VAX C builtins are effectively supported:
_BBCCI (position, address)
_BBSSI (position, address)
_INSQHI (new_entry, head)
_INSQTI (new_entry, head)
_INSQUE (new_entry, predecessor)
_REMQHI (head, removed_entry)
_REMQTI (head, removed_entry)
_PROBER (mode, length, address)
_PROBEW (mode, length, address)
Intrinsic Functions
On OpenVMS Alpha systems, C++ supports in-line assembly code,
commonly called ASMs on UNIX platforms.
OpenVMS I64 systems do not support ASMs.
Like builtin-functions, ASMs are implemented with a function-
call syntax. But unlike built-in functions, to use ASMs you
must include the <c_asm.h> header file containing prototypes for
the three types of ASMs, and the #pragma intrinsic preprocessor
directive.
Syntax:
__int64 asm(const char *, ...); /* for integer operations,
like mulq */
float fasm(const char *, ...); /* for single precision float
instructions */
double dasm(const char *, ...); /* for double precision float
instructions */
#pragma intrinsic (asm)
#pragma intrinsic (fasm)
#pragma intrinsic (dasm)
The first argument to the asm, fasm, or dasm function contains
the instruction(s) to be generated inline and the metalanguage
that describes the interpretation of the arguments.
The remaining arguments (if any) are the source and destination
arguments for the instruction being generated.
|
2 - Variable Length Argument Lists
|
The set of functions and macros defined and declared in the
<varargs.h> and the <stdarg.h> header files provide a method
of accessing variable-length argument lists. (Note that the
<stdarg.h> functions are defined by the ANSI C++ standard and
are, therefore, portable as compared with those defined in
<varargs.h>.)
The C++ RTL functions such as printf and execl, for example,
use variable-length argument lists. User-defined functions with
variable-length argument lists that do not use <varargs.h> or
<stdarg.h> are not portable due to the different argument-passing
conventions of various machines.
To use these functions and macros in <stdarg.h>, you must include
the <stdarg.h> header file with the following preprocessor
directive:
#include <stdarg.h>
The <stdarg.h> header file declares a type (va_list) and three
macros (va_start, va_arg, and va_end) for advancing through a
list of function arguments of varying number and type. The macros
have the following syntax:
void va_start(va_list ap, parmN);
type va_arg(va_list ap, type);
void va_end(va_list ap);
The va_start macro initializes the object ap of type va_list
for subsequent use by va_arg and va_end. The va_start macro
must be invoked before any access to the unnamed arguments. The
parameter parmN is the identifier of the rightmost parameter in
the variable parameter list of the function definition. If parmN
is declared with the register storage class, with a function
or array type, or with a type that is not compatible with the
type that results after application of the default arguments
promotions, the behavior is undefined. The va_start macro returns
no value.
The va_arg macro expands to an expresion that has the type and
value of the next argument in the call. The parameter ap is the
same as the one initialized by va_start. Each invocation of va_
arg modifies ap so that the values of successive arguments are
returned in turn. The parameter "type" is a type name specified
such that the type of a pointer to an object that has the
specified type can be obtained by postfixing an asterisk (*)
to "type". If there is no actual next argument, or if type is not
compatible with the type of the next actual argument (as promoted
according to the default argument promotions), the behavior
is undefined. The first invocation of va_arg after that of va_
start returns the value of the argument after that specified by
parmN. Successive invocations return the values of the remaining
arguments in turn.
The va_end macro facilitates a normal return from the function
whose variable argument list was referred to by the expansion
of va_start that initialized the va_list ap object. The va_end
macro can modify ap) so that it can no longer be used (without an
intervening invocation of va_start). If there is no corresponding
invocation of va_start or if va_end is not invoked before the
return, the behavior is undefined. The va_end macro returns no
value.
The C++ preprocessor uses directives to affect the compilation of
a source file. For C++ on OpenVMS systems, these directives are
processed by an early phase of the compiler, not by a separate
program.
The preprocessor directives begin with a number sign (#) and
do not end with a semicolon. The number sign must appear in the
first column of the source line.
o Null_directive (#)
A preprocessing directive of the form # <newline> is a null
directive and has no effect.
o Conditional_Compilation
Conditional compilation is provided by the following
directives:
#if constant-expression - Checks whether the constant
expression is nonzero (true).
#ifdef identifier - Checks whether the identifier is
defined.
#ifndef identifier - Checks whether the identifier is
undefined.
#else - Introduces source lines to be compiled as an
alternative to the conditions tested by the previous
directives.
#elif constant-expression - Delimits alternative source
lines to be compiled if the constant expression in the
corresponding #if, ##ifdef, or #ifndef directive is false
and if the additional constant expression presented in the
#elif directive is true. An #elif directive is optional.
#endif - Ends the scope of the previous directives.
If the condition checked by #if, #ifdef, or #ifndef is true,
then all lines between the #else, #elif, and #endif are
ignored. If the condition is false, then any lines between
the conditional directive and the #else or #elif (if any)
are ignored. If there is no #else, then the lines between the
conditional and the #endif are ignored.
o #define
The #define preprocessor directive has the form:
#define identifier token-string
The preprocessor substitutes the token string everywhere
in the program that it finds the identifier except within
comments, character constants, or string constants.
Macro replacements are defined in a #define directive of the
following form:
#define name([parm1[,parm2,...]]) token-string
Within the program, all macro references that have the
following form are replaced by the token string. The arguments
in the macro reference replace the corresponding parameters in
the token string.
name([arg1[,arg2,...]])
o #error
The #error directive issues an optional diagnostic message,
and ends compilation. This directive has the following form:
#error [message]
o #include
The #include directive instructs the preprocessor to insert
the contents of the specified file or module into the program.
An #include directive can have one of three forms:
#include "filespec"
#include <filespec>
#include module-name
The first two forms are ANSI-compliant methods of file
inclusion and are therefore more portable. In these forms,
.h is the default file type, unless the compiler is instructed
to supply no default type (that is, a type of just ".") by the
/ASSUME=NOHEADER_TYPE_DEFAULT qualifier.
The third form is specific to OpenVMS systems for specifying
the inclusion of a module from a text library, and is not
generally needed or recommended because the ANSI forms also
cause the text libraries to be searched.
For the order of search, see /INCLUDE_DIRECTORY.
There is no defined limit to the nesting level of #include
files and modules.
o #line
The #line directive applies a specified line number and
optional file specification to the next line of source
text. This can be useful for diagnostic messages. The #line
directive has the following forms:
#line integer-constant
#line integer-constant "filename"
#line pp-tokens
In the first two forms, the compiler gives the line following
a #line directive the number specified by the integer
constant. The optional filename in quotation marks indicates
the name of the source file that the compiler will provide in
its diagnostic messages. If the filename is omitted, the file
name used is the name of the current source file or the last
filename specified in a previous #line directive.
In the third form, macros in the #line directive are expanded
before it is interpreted. This allows a macro call to expand
into the integer-constant, filename, or both. The resulting
#line directive must match one of the other two forms, and is
then processed as appropriate.
o #pragma
The #pragma directive performs compiler-specific tasks as
designated by each implementation of the C language. HP C++
for OpenVMS Systems supports the following pragmas:
#pragma [no]builtins
Enables the C++ built-in functions that directly access
processor instructions. If the pragma does not appear in your
program, the default is #pragma nobuiltins.
C++ supports the #pragma builtins preprocessor directive for
compatibility with VAX C, but it is not required.
#pragma define_template
Instructs the compiler to instantiate a template with the
arguments specified in the pragma.
Syntax:
#pragma define_template identifier
For example, the following statement instructs the compiler to
instantiate the template mytempl with the arguments arg1 and
arg2:
#pragma define_template mytempl<arg1, arg2>
#pragma environment
Sets, saves, or restores the states of context pragmas.
This directive protects include files from contexts set by
encompassing programs, and protects encompassing programs from
contexts that could be set in header files that they include.
The #pragma environment directive affects the following
pragmas:
o #pragma extern_model
o #pragma extern_prefix
o #pragma member_alignment
o #pragma message
o #pragma pointer_size
o #pragma required_pointer_size
Syntax:
#pragma environment command_line
#pragma environment header_defaults
#pragma environment restore
#pragma environment save
command_line Sets, as specified on the command line, the
states of all the context pragmas. You can
use this pragma to protect header files from
environment pragmas that take effect before
the header file is included.
header_defaults Sets the states of all the context pragmas
to their default values. This is almost
equivalent to the situation in which a
program with no command-line options and
no pragmas is compiled, except that this
pragma sets the #pragma message state to
#pragma nostandard, as is appropriate for
header files.
save Saves the current state of every pragma that
has an associated context.
restore Restores the current state of every pragma
that has an associated context.
#pragma extern_model
Controls the compiler's interpretation of objects that have
external linkage. This pragma lets you choose the global
symbol model to be used for externs.
Syntax:
#pragma extern_model common_block [attr[,attr]...]
#pragma extern_model relaxed_refdef [attr[,attr]...]
#pragma extern_model strict_refdef "name" [attr[,attr]...]
#pragma extern_model strict_refdef
#pragma extern_model globalvalue
#pragma extern_model save
#pragma extern_model restore
The default model on C++ is #pragma relaxed_refdef noshr. This
is different from the model used by VAX C, which is common
block, shr.
Use of an extern_model value other than relaxed_refdef should
be limited to compilations that either declare only POD (Plain
Old Data) objects, or that carefully use the extern_model
#pragma (and/or environment #pragma) directives to ensure that
declarations of non-POD objects appear only in source that is
subject to the default extern_model of relaxed_refdef.
The [attr[,attr]...] are optional psect attribute
specifications chosen from the following (at most one from
each line):
o gbl lcl (Not allowed with relaxed_refdef)
o shr noshr
o wrt nowrt
o pic nopic (Not meaningful for Alpha)
o ovr con
o rel abs
o exe noexe
o vec novec
o 0 byte 1 word 2 long 3 quad
o octa 16 page
See the HP C++ User's Guide for OpenVMS Systems for more
information on the #pragma extern_model directive.
#pragma extern_prefix
Controls the compiler's synthesis of external names, which the
linker uses to resolve external name requests.
When you specify #pragma extern_prefix with a string
argument, the compiler prepends the string to all external
names produced by the declarations that follow the pragma
specification.
This pragma is useful for creating libraries where the
facility code can be attached to the external names in the
library.
Syntax:
#pragma extern_prefix "string"
#pragma extern_prefix save
#pragma extern_prefix restore
Where "string" prepends the quoted string to external names in
the declarations that follow the pragma specification.
The save and restore keywords can be used to save the current
pragma prefix string and to restore the previously saved
pragma prefix string, respectively.
The default external prefix, when none has been specified by a
pragma, is the null string.
#pragma function
Specifies that calls to the specified functions are not
intrinsic but are, in fact, function calls. This pragma has
the opposite effect of #pragma intrinsic.
Syntax:
#pragma function (function1[, function2, ...])
#pragma include_directory
The effect of each #pragma include_directory is as if its
string argument (including the quotes) were appended to the
list of places to search that is given its initial value by
the /INCLUDE_DIRECTORY qualifier, except that an empty string
is not permitted in the pragma form.
Syntax:
#pragma include_directory <string-literal>
This pragma is intended to ease DCL command-line length
limitations when porting applications from POSIX-like
environments built with makefiles containing long lists of
-I options that specify directories to search for headers.
Just as long lists of macro definitions specified by the
/DEFINE qualifier can be converted to #define directives in
a source file, long lists of places to search specified by
the /INCLUDE_DIRECTORY qualifier can be converted to #pragma
include_directory directives in a source file.
Note that the places to search, as described in the help
text for the /INCLUDE_DIRECTORY qualifier, include the use
of POSIX-style pathnames, for example "/usr/base". This form
can be very useful when compiling code that contains POSIX-
style relative pathnames in #include directives. For example,
#include <subdir/foo.h> can be combined with a place to search
such as "/usr/base" to form "/usr/base/subdir/foo.h", which
will be translated to the filespec "USR:[BASE.SUBDIR]FOO.H"
This pragma can appear only in the main source file or in the
first file specified on the /FIRST_INCLUDE qualifier. Also, it
must appear before any #include directives.
#pragma [no]inline
Expands function calls inline. The function call is replaced
with the function code itself.
Syntax:
#pragma inline (id,...)
#pragma noinline (id,...)
If a function is named in an inline directive, calls to that
function will be expanded as inline code, if possible.
If a function is named in a noinline directive, calls to that
function will not be expanded as inline code.
If a function is named in both an inline and a noinline
directive, an error message is issued.
For calls to functions named in neither an inline nor a
noinline directive, C++ expands the function as inline code
whenever appropriate as determined by a platform-specific
algorithm.
#pragma intrinsic
Specifies that calls to the specified functions are intrinsic
(that is, handled internally by the compiler, allowing it to
generate inline code, move or eliminate calls, or do various
other optimizations). This pragma is only valid for functions
that are known to the compiler.
Syntax:
#pragma intrinsic (function1[, function2, ...])
#pragma [no]member_alignment
Tells the compiler to align structure members on the next
boundary appropriate to the type of the member rather than the
next byte. For example, a long variable is aligned on the next
longword boundary; a short variable on the next word boundary.
Syntax:
#pragma nomember_alignment [base_alignment]
#pragma member_alignment [save | restore]
The optional base_alignment parameter can be used with #pragma
nomember_alignment to specify the base alignment of the
structure. Use one of the following keywords to specify the
base_alignment:
o BYTE (1 byte)
o WORD (2 bytes)
o LONGWORD (4 bytes)
o QUADWORD (8 bytes)
o OCTAWORD (16 bytes)
The optional save and restore keywords can be used to save
the current state of the member_alignment and to restore
the previous state, respectively. This feature is necessary
for writing header files that require member_alignment or
nomember_alignment, or that require inclusion in a member_
alignment that is already set.
#pragma message
Controls the issuance of individual diagnostic messages or
groups of messages. Use of this pragma overrides any command-
line options that may affect the issuance of messages.
Syntax:
#pragma message option1 message-list
#pragma message option2
where option1 is:
disable Suppresses the issuance of the indicated
messages.
Only messages of severity Warning (W) or
Information (I) can be disabled. If the
message has severity of Error (E) or Fatal
(F), it is issued regardless of any attempt
to disable it.
enable Enables the issuance of the indicated messages.
error Sets the severity of each message in the
message-list to Error.
fatal Sets the severity of each message on the
message-list to Fatal.
informational Sets the severity of each message in the
message-list to Informational.
warning Sets the severity of each message in the
message-list to Warning.
The message-list can be any one of the following:
o A single message identifier (within parentheses or not).
o A comma-separated list of message identifiers, enclosed in
parentheses.
o The keyword ALL-All the messages in the compiler.
option2 is:
save-saves the current state of which messages are enabled and
disabled.
restore-restores the previous state of which messages are
enabled and disabled.
#pragma module
Changes the system-recognized module name and version number.
You can find the module name and version number in the
compiler listing file and the linker load map.
Syntax:
#pragma module identifier identifier
#pragma module identifier string
The first parameter must be a valid C++ identifier. It
specifies the module name to be used by the linker. The second
parameter specifies the optional identification that appears
on listings and in the object file. It must be either a valid
DEC C identifier of 31 characters or less, or a character-
string constant of 31 characters or less.
Only one #pragma module directive can be processed per
compilation unit, and that directive must appear before any
C language text. The #pragma module directive can follow other
directives, such as #define, but it must precede any function
definitions or external data definitions.
#pragma once
Specifies that the header file is evaluated only once.
Syntax:
#pragma once
#pragma pack
Specifies the byte boundary for packing members of C
structures.
Syntax:
#pragma pack [n]
The n specifies the new alignment restriction in bytes:
1 - align to byte
2 - align to word
4 - align to longword
8 - align to quadword
16 - align to octaword
A structure member is aligned to either the alignment
specified by #pragma pack or the alignment determined by
the size of the structure member, whichever is smaller. For
example, a short variable in a structure gets byte-aligned
if #pragma pack 1 is specified. If #pragma pack 2, 4, or 8 is
specified, the short variable in the structure gets aligned to
word.
If #pragma pack is not used, or if it is specified without the
n, packing defaults to 16 on OpenVMS Alpha and I64 systems,
and to 1 (byte alignment) on OpenVMS VAX systems.
#pragma pointer_size
Controls whether pointers are 32-bit pointers or 64-bit
pointers.
Syntax:
#pragma pointer_size keyword
Where keyword is one of the following:
short-32-bit pointer
long-64-bit pointer
system_default-32-bit pointers on OpenVMS systems; 64-bit
pointers on Tru64 UNIX systems
save-Saves the current pointer size
restore-Restores the current pointer size to its last saved
state
This directive is enabled only when the /POINTER_SIZE command-
line qualifier is specified. Otherwise, #pragma pointer_size
has the same effect as #pragma required_pointer_size.
#pragma required_pointer_size
Intended for use by developers of header files to control
pointer size within header files.
Syntax:
#pragma required_pointer_size keyword
Where keyword is one of the following:
short-32-bit pointer
long-64-bit pointer
system_default-32-bit pointers on OpenVMS systems; 64-bit
pointers on Tru64 UNIX systems
save-Saves the current pointer size
restore-Restores the current pointer size to its last saved
state
This directive is always enabled, even if the /POINTER_
SIZE command-line qualifier is omitted. Otherwise, #pragma
required_pointer_size has the same effect as #pragma pointer_
size.
#pragma [no]standard
Directs the compiler to define regions of source code where
portability diagnostics are not to be issued.
Use #pragma nostandard to suppress diagnostics about non-ANSI
C extensions, regardless of the /STANDARD qualifier specified,
until a #pragma standard directive is encountered.
Use #pragma standard to reinstate the setting of the /STANDARD
qualifier that was in effect before before the last #pragma
nostandard was encountered.
Every #pragma standard directive must be preceded by a
corresponding #pragma nostandard directive.
Note that this pragma does not change the current mode of the
compiler or enable any extensions not already supported in
that mode.
#pragma use_linkage
Associates a special linkage, defined by the #pragma linkage
directive, with the specified functions.
Syntax:
#pragma use_linkage linkage-name (routine1, routine2, ...)
The linkage-name is the name of a linkage previously defined
by the #pragma linkage directive.
The parenthesized list contains the names of functions you
want to associated with the named linkage.
o #undef
The #undef directive cancels a previously defined macro
replacement. Any other macro replacements that occurred before
the #undef directive remain.
The #undef directive has the following syntax:
#undef identifier
The compiler defines the following macros and names. For more
detailed information, see the HP C++ User's Guide for OpenVMS
Systems. The * character following a name indicates that the name
cannot be redefined or undefined.
Macro Description
_BOOL_EXISTS Indicates that bool is a type
or keyword
__BOOL_IS_A_RESERVED_WORD Indicates that bool is a
keyword
__DATE__ A string literal containing
the date of the translation
in the form Mmm dd yyyy, or
Mmm d yyyy if the value of
the date is less than 10
__FILE__ A string literal containing
the name of the source file
being compiled
__IEEE_FLOAT Identifies floating-point
format for compiling the
program. The value is always
1 for HP Tru64 UNIX.
__LINE__ A decimal constant containing
the current line number in
the C++ source file
__PRAGMA_ENVIRONMENT Indicates that that the
pragma environment directive
is supported.
__TIME__ A string literal containing
the time of the translation
in the form of hh:mm:ss
_WCHAR_T Indicates that wchar_t is a
keyword
The following table lists names with a defined value of 1.
Name Description
__cplusplus Language identification name.
__DECCXX Language identification name.
__VMS System identification
__vms System identification
The compiler predefines __VMS; the C compiler predefines VMS and
__VMS. Therefore, C++ programmers who plan to reuse code should
check for __VMS.
The compiler supports the following predefined macro names:
Name Description
__Alpha_AXP System identification name
__ALPHA System identification name
__alpha System identification name
__32BITS Defined when pointers and data of type long
are 32 bits on Alpha platforms
The compiler predefines __32BITS when pointers and data of type
long are 32 bits on Alpha platforms.
On both UNIX and OpenVMS Alpha operating systems, programmers
should use the predefined macro __alpha for code that is intended
to be portable from one system to the other.
Predefined macros (with the exception of vms_version, VMS_
VERSION, __vms_version, __VMS_VERSION, and __INITIAL_POINTER_
SIZE) are defined as 1 or 0, depending on the system (VAX or
Alpha processor), the compiler defaults, and the qualifiers used.
For example, if you compiled using G_FLOAT format, __D_FLOAT and
__IEEE_FLOAT (Alpha processors only) are predefined to be 0, and
__G_FLOAT is predefined as if the following were included before
every compilation unit:
#define __G_FLOAT 1
These macros can assist in writing code that executes
conditionally. They can be used in #elif, #if, #ifdef, and
#ifndef directives to separate portable and nonportable code in
a C++ program. The vms_version, VMS_VERSION, __vms_version, and
__VMS_VERSION macros are defined with the value of the OpenVMS
version on which you are running (for example, Version 6.0).
C++ automatically defines the following macros pertaining to the
format of floating-point variables. You can use them to identify
the format with which you are compiling your program.
__D_FLOAT
__G_FLOAT
__IEEE_FLOAT
_IEEE_FP
__X_FLOAT
The value of __X_FLOAT can be 0 or 1 depending on the floating
point mode in effect. You can use the /FLOAT qualifier to change
the mode.
The following table lists predefined version string and version
number macros.
Name Description
__VMS_VERSION Version identification
__vms_version Version identification
__DECCXX_VER Version identification
__VMS_VER Version identification
For example, the defined value of __VMS_VERSION on OpenVMS
Version 6.1 is character string V6.1.
You can use __DECCXX_VER to test that the current compiler
version is newer than a particular version and __VMS_VER to
test that the current OpenVMS Version is newer than a particular
version. Newer versions of the compiler and the Openvms operating
system always have larger values for these macros. If for any
reason the version cannot be analyzed by the compiler, then the
corresponding predefined macro is defined but has the value of
0. Releases of the compiler prior to Version 5.0 do not define
these macros, so you can distinguish earlier compiler versions by
checking to determine if the __DECCXX_VER macro is defined.
The following example tests for C++ 5.1 or higher:
#ifdef __DECCXX_VER
#if __DECCXX_VER >= 50100000
/ *Code */
#endif
#endif
The following tests for OpenVMS Version 6.2 or higher:
#ifdef __VMS_VER
#if __VMS_VER >= 60200000
/* code */
#endif
#endif
The following table shows the macro names for the listed command-
line qualifiers.
Command-line Option Macro Name
/ASSUME=GLOBAL_ARRAY_NEW __GLOBAL_ARRAY_NEW
/ASSUME=STDNEW __STDNEW
/DEFINE=__FORCE_ __FORCE_INSTANTIATIONS
INSTANTATIONS
/EXCEPTIONS __EXCEPTIONS
/IEEE_MODE _IEEE_FP
/IMPLICIT_INCLUDE __IMPLICIT_INCLUDE_ENABLED
/L_DOUBLE_SIZE __X_FLOAT
/MODEL=ANSI __MODEL_ANSI
/MODEL=ARM __MODEL_ARM
/PURE_CNAME __PURE_CNAME, __HIDE_FORBIDDEN_NAMES
/ROUNDING_MODE __BIASED_FLT_ROUNDS
/RTTI __RTTI
/STANDARD=RELAXED __STD_ANSI, __NOUSE_STD_IOSTREAM
/STANDARD=ANSI __STD_ANSI, __NOUSE_STD_IOSTREAM
/STANDARD=ARM __STD_ARM, __NOUSE_STD_IOSTREAM
/STANDARD=GNU __STD_GNU, __NOUSE_STD_IOSTREAM
/STANDARD=MS __STD_MS, __NOUSE_STD_IOSTREAM
/STANDARD=STRICT_ANSI __STD_STRICT_ANSI,
__USE_STD_IOSTREAM, __PURE_CNAME
__HIDE_FORBIDDEN_NAMES
/STANDARD=STRICT_ANSI __STD_STRICT_ANSI_ERRORS
/WARNINGS=ANSI_ERRORS
__PURE_CNAME, __HIDE_FORBIDDEN_NAMES
/STANDARD=LATEST __STD_STRICT_ANSI,
__USE_STD_IOSTREAM, __PURE_CNAME
__HIDE_FORBIDDEN_NAMES
/STANDARD=LATEST __STD_STRICT_ANSI_ERRORS
/WARNINGS=ANSI_ERRORS
__PURE_CNAME, __HIDE_FORBIDDEN_NAMES
/USING=STD __IMPLICIT_USING_STD