|
VMS Help CXX *Conan The Librarian |
The CXX command invokes the C++ compiler to compile C++ source
programs. The syntax is as follows:
CXX file-spec,... +library-file-spec/LIBRARY...
Qualifiers indicate special actions to be performed by the
compiler or special input file properties. Compiler qualifiers
can apply to either the CXX command or to the specification
of the file being compiled. When a qualifier follows the CXX
command, it applies to all the files listed. When a qualifier
follows the file specification, it applies only to the file
immediately preceding it.
For help on the C++ Class Library, type
$ HELP CXXL
For help on the Standard Library, type
$ HELP CXXLSTD
An HTML version of this online help is accessible from:
file:/sys$common/syshlp/cxx$help/cphelp.htm
| 1 - Command Parameters |
file-spec,...
One or more C++ source files separated by plus signs or commas.
If plus signs are used, the input files are concatenated into
a single object file. If commas are used, each file is compiled
separately to create separate object files. If no input file type
is specified, C++ assumes the .CXX default file type.
library-file-spec
A text library containing #include modules referenced in one
or more of the source files. A library file specification must
be concatenated with a file specification with a plus sign and
qualified using the /LIBRARY qualifier. If the input file type is
not specified, C++ assumes the .TLB default file type.
Format
CXX
| 2 - Qualifiers |
2.1 - /ALTERNATIVE_TOKENS
/ALTERNATIVE_TOKENS
/NOALTERNATIVE_TOKENS
Enables use of the following operator keywords and digraphs to
generate tokens:
Operator
Keyword Token
and &&
and_eq &=
bitand &
bitor |
compl ~
not !
not_eq !=
or ||
or_eq |=
xor ^
xor_eq ^=
Digraph Token
:> ]
%: #
%> }
<% {
<: [
The default is /NOALTERNATIVE_TOKENS when compiling with the
/STANDARD=ARM, /STANDARD=MS, or /STANDARD=RELAXED option.
The default is /ALTERNATIVE_TOKENS when compiling with the
/STANDARD=STRICT_ANSI or /STANDARD=GNU option. Specifying
/ALTERNATIVE_TOKENS also defines the __ALTERNATIVE_TOKENS macro.
2.2 - /ANSI_ALIAS
/ANSI_ALIAS
/ANSI_ALIAS (D)
/NOANSI_ALIAS
Directs the compiler to assume the ANSI/ISO C aliasing rules,
which gives it the freedom to generate better optimized code.
/NOANSI_ALIAS specifies that any pointer can point to any object,
regardless of type. /ANSI_ALIAS specifies that pointers to a type
T can point to objects of the same type, ignoring type qualifiers
such as const, unaligned, or volatile, or whether the object
is signed or unsigned. Pointers to a type T can also point to
structures, unions, or array members whose type follows the rules
above.
The aliasing rules are further explained in Section 3.3,
paragraphs 20 and 25, of the ANSI C89 Standard (Section 6.3 of
the ISO version, same paragraphs).
2.3 - /ARCHITECTURE
/ARCHITECTURE=option
/ARCHITECTURE=GENERIC (D)
Determines the Alpha or Intel processor instruction set to be
used by the compiler. The /ARCHITECTURE qualifier uses the same
keyword options (keywords) as the /OPTIMIZE=TUNE qualifier.
Where the /OPTIMIZE=TUNE qualifier is primarily used by
certain higher-level optimizations for instruction scheduling
purposes, the /ARCHITECTURE qualifier determines the type of code
instructions generated for the program unit being compiled.
OpenVMS Version 7.1 and subsequent releases provide an operating
system kernel that includes an instruction emulator. This
emulator allows new instructions, not implemented on the
host processor chip, to execute and produce correct results.
Applications using emulated instructions will run correctly, but
may incur significant software emulation overhead at runtime.
All Alpha processors implement a core set of instructions.
Certain Alpha processor versions include additional instruction
extensions.
Select one of the /ARCHITECTURE qualifier options shown in the
following table.
Option Usage
GENERIC Generates code that is appropriate for all
processor generations. This is the default.
HOST Generates code for the processor generation
in use on the system being used for
compilation.
Running programs compiled with this option
on other implementations of the Alpha
architecture may encounter instruction-
emulation overhead.
ITANIUM2 (I64 only) Generates code for the Intel Itanium 2
processor family. For use on I64 systems
only.
EV4 (Alpha only) Generates code for the 21064, 21064A,
21066, and 21068 implementations of the
Alpha architecture.
Programs compiled with the EV4 option run
without instruction-emulation overhead on
all Alpha processors.
EV5 (Alpha only) Generates code for some 21164 chip
implementations of the Alpha architecture
that use only the base set of Alpha
instructions (no extensions).
Programs compiled with the EV5 option will
without instruction-emulation overhead on
all Alpha processors.
EV56 (Alpha only) Generates code for some 21164 chip
implementations that use the byte and word-
manipulation instruction extensions of the
Alpha architecture.
Running programs compiled with the EV56
option might incur emulation overhead on
EV4 and EV5 processors, but will still
run correctly on OpenVMS Version 7.1 (or
higher) systems.
PCA56 (Alpha only) Generates code for the 21164PC chip
implementation that uses the byte- and
word-manipulation instruction extensions
and multimedia instruction extensions of
the Alpha architecture.
Programs compiled with the PCA56 option
might incur emulation overhead on EV4,
EV5, and EV56 processors, but still run
correctly on OpenVMS Version 7.1 (or
higher) systems.
EV6 (Alpha only) Generates code for the 21264 implementation
of the Alpha architecture.
EV68 (Alpha only) Generates code for the 21264/EV68
implementation of the Alpha architecture.
EV7 (Alpha only) Generates code for the EV7 implementation
of the Alpha architecture.
See also /OPTIMIZE=TUNE, which is a more typical option.
Note that if /ARCHITECTURE is explicitly specified and
/OPTIMIZE=TUNE is not, the tuning processor defaults to the
architecture processor; for example, /ARCHITECTURE=EV6 implies
/OPTIMIZE=TUNE=EV6.
2.4 - /ASSUME
/ASSUME
/ASSUME=(option[,...])
Controls compiler assumptions. You may select the following
options:
Option Usage
[NO]WRITABLE_STRING_ Stores string constants in a writable
LITERALS psect. Otherwise, such constants are
placed in a nonwriteable psect. The
default is NOWRITABLE_STRING_LITERALS.
[NO]ACCURACY_ Specifies whether certain code
SENSITIVE transformations that affect floating-point
operations are allowed. These changes
may or may not affect the accuracy of the
program's results.
If you specify NOACCURACY_SENSITIVE, the
compiler is free to reorder floating-
point operations based on algebraic
identities (inverses, associativity, and
distribution). This allows the compiler to
move divide operations outside of loops,
which improves performance.
The default, ACCURACY_SENSITIVE, directs
the compiler to use only certain scalar
rules for calculations. This setting can
prevent some optimization.
[NO]ALIGNED_OBJECTS Controls an optimization for dereferencing
pointers.
Dereferencing a pointer to a longword- or
quadword-aligned object is more efficient
than dereferencing a pointer to a byte-
or word-aligned object. Therefore, the
compiler can generate more optimized code
if it makes the assumption that a pointer
object of an aligned pointer type does
point to an aligned object.
Because the compiler determines the
alignment of the dereferenced object
from the type of the pointer, and the
program is allowed to compute a pointer
that references an unaligned object (even
though the pointer type indicates that
it references an aligned object), the
compiler must assume that the dereferenced
object's alignment matches or exceeds the
alignment indicated by the pointer type.
The default, /ASSUME=ALIGNED_OBJECTS,
allows the compiler to make such an
assumption. With this assumption made,
the compiler can generate more efficient
code for pointer dereferences of aligned
pointer types.
To prevent the compiler from assuming
the pointer type's alignment for
objects to which it points, use the
/ASSUME=NOALIGNED_OBJECTS qualifier.
This option causes the compiler to
generate longer code sequences to perform
indirect load and store operations to
avoid hardware alignment faults for
arbitrarily aligned addresses. Although
/ASSUME=NOALIGNED_OBJECTS might generate
less efficient code than the default
/ASSUME=ALIGNED_OBJECTS option, by
avoiding hardware alignment faults, it
speeds the execution of programs that
reference unaligned data.
[NO]GLOBAL_ARRAY_NEW Controls whether calls to global array new
and delete are generated as specified by
ANSI. Pre-ANSI global array new generated
calls to operator new(). According to
ANSI, use of global array new generates
calls to operator new()[]. The GLOBAL_
ARRAY_NEW option also defines the macro
__GLOBAL_ARRAY_NEW.
GLOBAL_ARRAY_NEW generates calls to
operator new()[] for global array
new expressions such as new int[4];
this is the default when compiling
/STANDARD=RELAXED, /STANDARD=STRICT_ANSI,
/STANDARD=GNU, and /STANDARD=MS.
NOGLOBAL_ARRAY_NEW generates calls to
operator new() for global array new
expressions such as new int[4]; and
preserves compatibility with Version
5.n; this is the default when compiling
/STANDARD=ARM.
[NO]HEADER_TYPE_ Controls whether the compiler appends a
DEFAULT file extension to a file name. The default
is /ASSUME=NOHEADER_TYPE_DEFAULT. To
prevent the compiler from appending a file
extension to files (such as STL header
files that must not have file extensions)
use the /ASSUME=NOHEADER_TYPE_DEFAULT
qualifier.
[NO]MATH_ERRNO Controls whether intrinsic code is
generated for math functions that set
the errno variable. The default is
/ASSUME=MATH_ERRNO, which does not allow
intrinsic code for such math functions to
be generated, even if /OPTIMIZE=INTRINSICS
is in effect. Their prototypes and call
formats, however, are still checked.
[NO]POINTERS_TO_ Controls whether the compiler can safely
GLOBALS assume that global variables have not had
their addresses taken in code that is not
visible to the current compilation.
The default is /ASSUME=POINTERS_TO_
GLOBALS, which directs the compiler to
assume that global variables have had
their addresses taken in separately
compiled modules and that, in general,
any pointer dereference could be accessing
the same memory as any global variable.
This is often a significant barrier to
optimization.
While the /ANSI_ALIAS option allows
some resolution based on data type,
/ASSUME=POINTERS_TO_GLOBALS provides
significant additional resolution and
improved optimization in many cases.
The /ASSUME=NOPOINTERS_TO_GLOBALS option
tells the compiler that any global
variable accessed through a pointer
in the compilation must have had its
address taken within that compilation.
The compiler can see any code that takes
the address of an extern variable. If it
does not see the address of the variable
being taken, the compiler can assume that
no pointer points to the variable.
Note that /ASSUME=NOPOINTERS_TO_GLOBALS
does not tell the compiler that the
compilation never uses pointers to access
global variables.
Also note that on I64 systems, the
NOPOINTERS_TO_GLOBALS option is ignored
and should not cause any behavior changes.
[NO]STDNEW Controls whether calls are generated to
the ANSI or pre-ANSI implementation of
the operator new(). On memory allocation
failure, the ANSI implementation throws
std::bad_alloc, while the pre-ANSI
implementation returns 0.
/ASSUME=STDNEW generates calls to the ANSI
new() implementation; this is the default
when compiling with /STANDARD=RELAXED,
/STANDARD= STRICT_ANSI, and /STANDARD=GNU.
/ASSUME=NOSTDNEW generates calls to the
pre-ANSI new() implementation; this is the
default when compiling with /STANDARD=ARM
and /STANDARD=MS.
[NO]TRUSTED_SHORT_ Allows the compiler additional assumptions
ALIGNMENT about the alignment of short types that,
although thought to be naturally aligned,
might cross a quadword boundary.
The TRUSTED_SHORT_ALIGNMENT option
indicates that the compiler should assume
any datatype accessed through a pointer
is naturally aligned. This generates the
fastest code, but can silently generate
the wrong results when an unaligned short
object crosses a quadword boundary.
Note that on I64 systems, the TRUSTED_
SHORT_ALIGNMENT option is ignored and
should not cause any behavior changes.
The NOTRUSTED_SHORT_ALIGNMENT tells the
compiler that short objects might not be
naturally aligned. The compiler generates
slightly larger (and slower) code that
gives the correct result, regardless of
the actual alignment of the data. This is
the default.
Note that the NOTRUSTED_SHORT_ALIGNMENT
option does not override the __unaligned
type qualifier or the /ASSUME=NOALIGNED_
OBJECTS option.
[NO]WHOLE_PROGRAM Tells the compiler that except for well-
behaved library routines, the whole
program consists only of the single
object module being produced by this
compilation. The optimizations enabled
by /ASSUME=WHOLE_PROGRAM include all those
enabled by /ASSUME=NOPOINTERS_TO_GLOBALS
and possibly other optimizations.
Note that on I64 systems, the WHOLE_
PROGRAM option is ignored and should not
cause any behavior changes.
The default is /ASSUME=NOWHOLE_PROGRAM.
2.5 - /CHECK
/CHECK
/CHECK[=([NO]UNINITIALIZED_VARIABLES)] (Alpha only)
/NOCHECK (D)
Use this qualifier as a debugging aid.
Use /CHECK=UNINITIALIZED_VARIABLES to initialize all automatic
variables to the value 0x7ff580057ff58005. This value is a
floating NaN and, if used, causes a floating-point trap. If used
as a pointer, this value is likely to cause an ACCVIO.
Note that on I64 systems, /CHECK=UNINITIALIZED_VARIABLES emits a
warning and is ignored.
2.6 - /COMMENTS
/COMMENTS
/COMMENTS[=option]
/COMMENTS=SPACE (D)
/NOCOMMENTS
Specifies whether comments appear in preprocessor output files.
If comments do not appear, this qualifier specifies what replaces
them. The options are:
Option Usage
AS_IS Specifies that the comment appear in the output file. This
is the default if you use the /COMMENTS qualifier without
specifying an option.
SPACE Specifies that a single space replaces the comment in the
output file. This is the default if you do not specify the
/COMMENTS qualifier at all.
Specifying /NOCOMMENTS tells the preprocessor that nothing
replaces the comment in the output file. This may result in
inadvertent token pasting.
The preprocessor may replace a comment at the end of a line
or replace a line by itself with nothing, even if you specify
/COMMENTS=SPACE. Specifying /COMMENTS=SPACE cannot change the
meaning of the program.
2.7 - /DEBUG
/DEBUG
/DEBUG[=(option[,...])]
/DEBUG=(TRACEBACK,NOSYMBOLS) (D)
/NODEBUG
Requests that information be included in the object module for
use with the OpenVMS Debugger. You can select the following
options:
Option Usage
ALL Includes all possible debugging
information. /DEBUG=ALL is equivalent to
/DEBUG=(TRACEBACK,SYMBOLS), which on I64
systems is equivalent to /DEBUG=(TRACEBACK,
SYMBOLS=NOBRIEF).
NONE Excludes all debugging information.
This option is equivalent to specifying
/NODEBUG, which is equivalent to
/DEBUG=(NOTRACEBACK,NOSYMBOLS).
NOSYMBOLS Turns off symbol generation
SYMBOLS Generates symbol-table records. On I64
systems, /DEBUG= SYMBOLS is equivalent to
/DEBUG=SYMBOLS=BRIEF. On Alpha systems,
/DEBUG=SYMBOLS is effectively equivalent to
/DEBUG=NOBRIEF.
SYMBOLS=BRIEF Generates debug information with unreferenced
(I64 only) labels and types pruned out to produce smaller
object sizes. On Alpha systems, BRIEF is ignored.
SYMBOLS=NOBRIEF Generates complete debug information. On Alpha
(I64 only) systems, the NOBRIEF keyword is ignored, but you
still get complete debug information.
NOTRACEBACK Excludes traceback records. This option is
equivalent to specifying /NODEBUG and is used
to avoid generating extraneous information from
thoroughly debugged program modules.
TRACEBACK Includes only traceback records. This option
is the default if you do not specify the /DEBUG
qualifier on the command line.
On Alpha systems /DEBUG is equivalent to
/DEBUG=(TRACEBACK,SYMBOLS).
On I64 systems /DEBUG is
equivalent to /DEBUG=(TRACEBACK,SYMBOLS), which is equivalent
to /DEBUG=(TRACEBACK,SYMBOLS=BRIEF).
2.8 - /DEFINE
/DEFINE
/DEFINE=(identifier[=definition][,...])
/NODEFINE (D)
Performs the same function as the #define preprocessor
directive. That is, /DEFINE defines a token string or macro to
be substituted for every occurrence of a given identifier in the
program.
DCL converts all input to uppercase unless it is enclosed in
quotation marks.
The simplest form of a /DEFINE definition is as follows:
/DEFINE=true
This results in a definition like the one that would result from
the following definition:
#define TRUE 1
When more than one /DEFINE is present on the CXX command line or
in a single compilation unit, only the last /DEFINE is used.
When both /DEFINE and /UNDEFINE are present on a command line,
/DEFINE is evaluated before /UNDEFINE.
2.9 - /DEFINE
/DEFINE=__FORCE_INSTANTIATIONS (Alpha only)
/NODEFINE=__FORCE_INSTANTIATIONS (D)
Forces the standard library template preinstantiations to be
created in the user's repository. Normally these instantiations
are suppressed because the library already contains them.
On I64 systems, defining __FORCE_INSTANTIATIONS has no effect.
2.10 - /DEFINE
/DEFINE=__[NO_]USE_STD_IOSTREAM
/DEFINE=__NO_USE_STD_IOSTREAM (D)
Use or do not use the standard iostreams. Specifying
/DEFINE=__USE_STD_IOSTREAM forces the inclusion of the ANSI
standard version of the iostream header file. This is the default
in STRICT_ANSI mode. Otherwise, the pre-standard AT&T-compatible
version of iostreams is used.
2.11 - /DIAGNOSTICS
/DIAGNOSTICS
/DIAGNOSTICS[=file-spec]
/NODIAGNOSTICS (D)
Creates a file containing compiler diagnostic messages. The
default file extension for a diagnostics file is .DIA. The
diagnostics file is used with the DEC Language-Sensitive
Editor (LSE). To display a diagnostics file, enter the command
REVIEW/FILE=file-spec while in LSE.
2.12 - /DISTINGUISH_NESTED_ENUMS
/DISTINGUISH_NESTED_ENUMS
/NODISTINGUISH_NESTED_ENUMS (D)
Causes the compiler, when forming a mangled name, to include the
name of any enclosing classes within which an enum is nested,
thereby preventing different functions from receiving the same
mangled name.
This qualifier has no meaning on I64 systems because it modifies
the behavior of programs compiled with /MODEL=ARM, and that model
is not supported on I64 systems.
2.13 - /ENDIAN
/ENDIAN
/ENDIAN={BIG | LITTLE}
/ENDIAN=LITTLE (D)
Controls whether big or little endian ordering of bytes is
carried out in character constants.
2.14 - /ERROR_LIMIT
/ERROR_LIMIT
/ERROR_LIMIT[=number]
/ERROR_LIMIT=30 (D)
/NOERROR_LIMIT
Limits the number of error-level diagnostic messages that are
acceptable during program compilation. Compilation terminates
when the limit (number) is exceeded. /NOERROR_LIMIT specifies
that there is no limit on error messages.
The default is /ERROR_LIMIT=30, which specifies that compilation
terminates after issuing 30 error messages.
2.15 - /EXCEPTIONS
/EXCEPTIONS
/EXCEPTIONS=CLEANUP (D)
/EXCEPTIONS=NOCLEANUP (Alpha only)
/EXCEPTIONS=EXPLICIT (D)
/EXCEPTIONS=IMPLICIT (Alpha only)
/NOEXCEPTIONS
Controls whether support for C++ exceptions is enabled or
disabled. C++ exceptions are enabled by default (equivalent
to /EXCEPTIONS=CLEANUP). When C++ exceptions are enabled, the
compiler generates code for throw expressions, try blocks, and
catch statements. The compiler also generates special code for
main programs so that the terminate() routine is called for
unhandled exceptions. You can select from the following options:
CLEANUP Generate cleanup code for automatic objects. When an
exception is handled at run-time and control passes
from a throw-point to a handler, call the destructors
for all automatic objects that were constructed because
the try-block containing the handler was entered.
NOCLEANUP Do not generate cleanup code. Using this option can
(Alpha reduce the size of your executable when you want to
only) throw and handle exceptions and cleanup of automatic
objects during exception processing is not important
for your application.
The NOCLEANUP option is ignored on I64 systems.
EXPLICIT Tells the compiler to assume the standard C++ rules
about exceptions. Catch clauses can catch only those
exceptions resulting from the evaluation of a throw
expression within the body of the catch clause's try
block or from within a procedure called from within the
catch clause's try block.
IMPLICIT On Alpha systems, tells the compiler that an exception
(Alpha might be thrown at any time the program is executing
only) code within the body of the try block. These exceptions
might be the result of a throw expression, hardware
errors, or software errors (such as dereferencing an
invalid pointer).
Specifying /EXCEPTIONS=IMPLICIT seriously interferes
with the compiler's ability to optimize code. When the
compiler optimizes a function, it must ensure that the
values of all variables after an exception is caught
remain the same as they were at the point where the
exception was throw. The optimizer is therefore limited
in its ability to rearrange stores and expressions that
might cause an exception to be thrown.
With /EXCEPTIONS=EXPLICIT, this is not a serious
restriction, because the compiler cannot rearrange
stores and expressions around the code that explicitly
raises an exception. In implicit exception mode,
however, almost any code has the potential to cause an
exception to be thrown, thereby dramatically reducing
the optimizer's ability to rearrange code.
Also, if the compiler can determine that no throw
expressions occur within a try block, it can eliminate
the exception handling overhead the try block
introduces, including all code within the catch clauses
associated with the try block. Because no exceptions
can occur during the execution of the code within
the try block, no code within the catch clauses can
ever be executed. The compiler cannot do this with
/EXCEPTIONS=IMPLICIT.
Use /EXCEPTIONS=IMPLICIT if your program converts
signals to C++ exceptions by calling cxxl$set_
condition(cxx_exception). Failure to do so may result
in your code not catching the exceptions produced by
signals.
The /NOEXCEPTIONS qualifier disables C++ exceptions as follows:
1. The compiler issues errors for throw expressions, try blocks,
and catch statements, but might generate code for these
constructs.
2. On Alpha systems, the compiler does not generate cleanup code
for automatic objects.
3. The compiler does not generate special code for main programs
so that the terminate() function is called for unhandled
exceptions.
The /EXCEPTIONS qualifer defines the macro __EXCEPTIONS.
2.16 - /EXPORT_SYMBOLS
/EXPORT_SYMBOLS=(OPTIONS_FILE=<name>
[,EXCLUDE=<list of images>]
[,export_option]
[,NOTEMPLATES]) (I64 only)
Creating OpenVMS shareable images that contain C++ code has long
been a problem for users. When building a shareable image, you
must specify a list of exported global symbols. For C++ code,
determining this list can be very difficult for the following
reasons:
o Required C++ name mangling makes it difficult to know the name
of the external symbol created for a C++ name.
o OpenVMS CRC encoding (to 31 characters) further complicates
mapping source names to object names.
o Certain C++ constructs require compiler-generated names to be
created and exported.
To help solve the problem, the HP C++ compiler provides the
/EXPORT_SYMBOLS qualifier and __declspec(dllexport) declaration
modifier.
The default file extension for the OPTIONS_FILE <name> is .OPT.
If the file exists, the compiler appends to it. If the file does
not exist, the compiler creates it.
The output for the compilation is:
!
! Entries added for <module>
!
<symbol vector>
<symbol vector>
.
.
.
The output file is suitable input to a linker options file that
can be used to build a shareable image containing the compiled
object.
The format of each <symbol vector> is:
SYMBOL_VECTOR=(<global name>={DATA | PROCEDURE}) ! <comment field>
The <comment field> format is:
<unmangled name> [<promoted static flag>] [<class information>]
The <promoted static flag> is one of the following:
*PSDM* - for promoted static data members
*PTSDM* - for promoted template static data members
The <promoted static flag> is output whenever the symbol is a
promoted local static or a promoted template static data member.
This is important because these variables, while declared static,
actually become global symbols when compiled.
The <class information> field is present if the symbol is a
member of a class. It contains the name of the class.
NOTES
o When /EXPORT_SYMBOLS is specified, an object file must
also be generated. So /EXPORT_SYMBOLS cannot be used with
/NOOBJ, /PREPROCESS_ONLY, or any other qualifier that
prevents the creation of an object file.
o When the options file already exists, the compiler reads
all the symbols that are listed there. If the current
compilation also defines one of those symbols, that
symbol will not be added to the options file. This is
necessary to prevent SYMVALRDEF warnings from the linker.
o When the compiler reads the existing file, it treats
SYMBOL_VECTOR directives that are in comments (of the
form !SYMBOL_VECTOR...) as if they were not commented.
In this way, if a user does not want to export a symbol,
placing it in comments will prevent the compiler from
emitting a directive for that symbol when it compiles
other sources that might also define the symbol.
o The symbols placed in the options file are a subset
of the symbols defined in the output object file. The
export_option value controls exactly which symbols are
placed there. There are three choices:
Export_
option
Value Usage
ALL Place all symbols suitable for placement in
a sharable image into the options file. The
compiler knows that certain symbols are not
suited for placement in a shareable image
and excludes them from the options file.
Some examples are certain compiler-generated
constructor/destructor jackets and symbols in
the unnamed namespace.
EXPLICIT Place only those symbols marked with the
__declspec(dllexport) declaration modifier
into the options file.
AUTOMATIC(If the compiler processes a
__declspec(dllexport), then act as if EXPLICIT
was specified. If the compiler does not
process a __declspec(dllexport), then act
as if ALL was specified.
o The EXCLUDE option of the /EXPORT_SYMBOLS qualifier
can be used to specify a list of shareable images. The
compiler searches these images for any symbols that it
might want to place in the output options file. If it
finds the symbol in the image, then that symbol will not
be put into the options file.
o The NOTEMPLATES option can be used to control
the emission of symbols associated with template
instantiations. Specifying this option causes the
compiler to suppress symbols created by template
instantiation. This includes instantiations of class
templates, its data members and member functions, and
instantiations of function templates. This option could
be used to avoid multiple definition diagnostics from the
linker if multiple sharable images might be instantiating
(and exporting) the same template symbols. Symbols
marked with __declspec(dllexport) still get exported.
This option has no effect on symbols from template
specializations. Note that while this option might
make the sharable images smaller by not exporting the
template symbols, the executable image that links with
these sharable images might be larger because it will
contain the instantiated template symbols.
Because shareable images almost always contain a number of
objects, the commands for creating the options file the first
time might be:
$ DELETE options_file.OPT;*
$ CXX SOURCE1/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
$ CXX SOURCE2/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
$ CXX SOURCE3/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
.
.
.
$ CXX SOURCEn/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
Where SOURCE1 - SOURCEn are the sources for the shareable. After
the compilations, the options_file.OPT will contain correct
symbol vector information for the shareable.
The first time this options file is created, it can be considered
a candidate options file. It contains all the symbol vector
entries for all the C++ globals that make sense to export from
the C++ language point of view. A user can then edit this file to
exclude (by commenting out) entries that should not be exported,
based on the design of the library.
Once an options file is created, it should be maintained for
input to subsequent compilations. In this way, any new symbols
caused by a change in the source will be added to the end of the
compilation. Any existing symbols will not be added, as described
in the NOTES section above. This technique ensures that the order
of symbols remains unchanged, and that future shared libraries
are compatible with existing ones.
2.17 - /EXTERN_MODEL
/EXTERN_MODEL
/EXTERN_MODEL=option
/EXTERN_MODEL=RELAXED_REFDEF (D)
In conjunction with the /SHARE_GLOBALS qualifier, controls the
initial extern model of the compiler. Conceptually, the compiler
behaves as if the first line of the program being compiled was a
#pragma extern_model directive with the model and psect name, if
any, specified by the /EXTERN_MODEL qualifier and with the SHR or
NOSHR keyword specified by the /SHARE_GLOBALS qualifier.
For example, assume the command line contains the following
qualifier:
/EXTERN_MODEL=STRICT_REFDEF="MYDATA"/NOSHARE
The compiler acts as if the program began with the following
line:
#pragma extern_model strict_refdef "MYDATA" noshr
For more information on the various models, see "C++
Implementation" in the HP C++ User's Guide for OpenVMS Systems.
The /EXTERN_MODEL qualifier takes the following options, which
have the same meaning as for the #pragma extern_model directive:
COMMON_BLOCK
RELAXED_REFDEF
STRICT_REFDEF=["NAME"]
GLOBALVALUE
The default is RELAXED_REFDEF.
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 (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.
2.18 - /FIRST_INCLUDE
/FIRST_INCLUDE
/FIRST_INCLUDE=(file[, . . . ])
/NOFIRST_INCLUDE (D)
Includes the specified files before any source files. This
qualifier corresponds to the Tru64 UNIX -FI switch.
When /FIRST_INCLUDE=file is specified, file is included in the
source as if the line before the first line of the source were:
#include "file"
If more than one file is specified, the files are included in
their order of appearance on the command line.
This qualifier is useful if you have command lines to pass to the
C compiler that are exceeding the DCL command-line length limit.
Using the /FIRST_INCLUDE qualifier can help solve this problem by
replacing lengthy /DEFINE and /WARNINGS qualifiers with #define
and #pragma message preprocessor directives placed in a /FIRST_
INCLUDE file.
The default is /NOFIRST_INCLUDE.
2.19 - /FLOAT
/FLOAT
/FLOAT=option
/FLOAT=G_FLOAT (Alpha only) (D)
/FLOAT=IEEE_FLOAT (I64 only) (D)
Controls the format of floating-point variables. The options are:
Option Usage
D_FLOAT double variables are represented in VAX D_
floating format. float variables are represented
in VAX F_floating format. The __D_FLOAT macro is
predefined.
G_FLOAT double variables are represented in VAX G_
floating format. float variables are represented
in VAX F_floating format. The __G_FLOAT macro is
predefined.
IEEE_FLOAT float and double variables are represented in
IEEE floating-point format (S_float and T_
float, respectively). The __IEEE_FLOAT macro
is predefined. Use the /IEEE_MODE qualifier for
controlling the handling of IEEE exceptional
values.
On Alpha systems, the default is /FLOAT=G_FLOAT.
On I64 systems, the default is /FLOAT=IEEE_FLOAT.
See the HP C++ User's Guide for OpenVMS Systems for additional
information on floating-point representation on I64 and Alpha
systems.
2.20 - /GRANULARITY
/GRANULARITY
/GRANULARITY=option
/GRANULARITY=QUADWORD (D)
Controls the size of shared data in memory that can be safely
accessed from different threads. The possible size values are
BYTE, LONGWORD, and QUADWORD.
Specifying BYTE allows single bytes to be accessed from different
threads sharing data in memory without corrupting surrounding
bytes. This option will slow runtime performance.
Specifying LONGWORD allows naturally aligned 4-byte longwords
to be accessed safely from different threads sharing data in
memory. Accessing data items of 3 bytes or less, or unaligned
data, may result in data items written from multiple threads
being inconsistently updated.
Specifying QUADWORD allows naturally aligned 8-byte quadwords
to be accessed safely from different threads sharing data in
memory. Accessing data items of 7 bytes or less, or unaligned
data, might result in data items written from multiple threads
being inconsistently updated. This is the default.
2.21 - /IEEE_MODE
/IEEE_MODE
/IEEE_MODE=option
/IEEE_MODE=FAST (D) (Alpha only)
/IEEE_MODE=DENORM_RESULTS (D) (I64 only)
Selects the IEEE floating-point mode to be used if the
/FLOAT=IEEE_FLOAT qualifier is specified. The options are:
Option Usage
FAST During program execution, only finite values
(no infinities, NaNs, or denorms) are created.
Underflows and denormal values are flushed to
zero. Exceptional conditions, such as floating-
point overflow, divide-by-zero, or use of an IEEE
exceptional operand are fatal.
UNDERFLOW_ Generate infinities and NaNs. Flush denormalized
TO_ZERO results and underflow to zero without exceptions.
DENORM_ Same as the UNDERFLOW_TO_ZERO option, except that
RESULTS denorms are generated.
INEXACT Same as the DENORM_RESULTS option, except that
inexact values are trapped. This is the slowest
mode, and is not appropriate for any sort of
general-purpose computations.
On Alpha systems, the default is /IEEE_MODE=FAST.
On I64 systems, the default is /IEEE_MODE=DENORM_RESULTS.
The INFINITY and NAN macros defined in <math.h> are available to
programs compiled with /FLOAT=IEEE and /IEEE_MODE={anything other
than FAST}.
On Alpha sytems, the /IEEE_MODE qualifier generally has its
greatest effect on the generated code of a compilation. When
calls are made between functions compiled with different /IEEE_
MODE qualifiers, each function produces the /IEEE_MODE behavior
with which it was compiled.
On I64 systems, the /IEEE_MODE qualifier primarily affects
only the setting of a hardware register at program startup.
In general, the /IEEE_MODE behavior for a given function is
controlled by the /IEEE_MODE option specified on the compilation
that produced the main program: the startup code for the main
program sets the hardware register according the command-line
qualifiers used to compile the main program.
When applied to a compilation that does not contain a main
program, the /IEEE_MODE qualifier does have some effect: it might
affect the evaluation of floating-point constant expressions, and
it is used to set the EXCEPTION_MODE used by the math library for
calls from that compilation. But the qualifier has no effect on
the exceptional behavior of floating-point calculations generated
as inline code for that compilation. Therefore, if floating-point
exceptional behavior is important to an application, all of its
compilations, including the one containing the main program,
should be compiled with the same /IEEE_MODE setting.
Even on Alpha systems, the particular setting of /IEEE_
MODE=UNDERFLOW_TO_ZERO has this characteristic: its primary
effect requires the setting of a runtime status register, and
so it needs to be specified on the compilation containing the
main program in order to be effective in other compilations.
Also see the /FLOAT qualifier.
2.22 - /IMPLICIT_INCLUDE
/IMPLICIT_INCLUDE
/IMPLICIT_INCLUDE (D)
/NOIMPLICIT_INCLUDE
/IMPLICIT_INCLUDE enables inclusion of source files as a method
of finding definitions of template entities. By default it is
enabled for normal compilation, and disabled for preprocessing
only. The search rules for finding template definition files is
the same as for include files.
/NOIMPLICIT_INCLUDE disables inclusion of source files as a
method of finding definitions of template entities. You might
want to use this option in conjunction with the /STANDARD=MS
command line option, to match more closely the behavior on
Microsoft C++.
2.23 - /INCLUDE_DIRECTORY
/INCLUDE_DIRECTORY
/INCLUDE_DIRECTORY=(place[,...])
/NOINCLUDE_DIRECTORY (D)
Provides an additional level of search for user-defined include
files. Each pathname argument can be either a logical name or
a legal UNIX style directory in a quoted string. The default is
/NOINCLUDE_DIRECTORY.
The /INCLUDE_DIRECTORY qualifier provides functionality similar
to the -I option of the cxx command on Tru64 UNIX systems.
This qualifier allows you to specify additional locations to
search for files to include. Putting an empty string in the
specification prevents the compiler from searching any of the
locations it normally searches but directs it to search only
in locations you identify explicitly on the command line with
the /INCLUDE_DIRECTORY And /LIBRARY qualifiers (or by way of
the specification of the primary source file, depending on the
/NESTED_INCLUDE_DIRECTORY qualifier).
The basic order for searching depends on the form of the header
name (after macro expansion), with additional aspects controlled
by other command line qualifiers as well as the presence or
absence of logical name definitions. The valid possibilities
for names are as follows:
o Enclosed in quotes. For example: "stdio.h"
o Enclosed in angle brackets. For example: <stdio.h>
Unless otherwise defined, searching a location means that the
compiler uses the string specifying the location as the default
file specification in a call to an RMS system service (that is,
a $SEARCH/$PARSE) with a primary file specification consisting
of the name in the #include (without enclosing delimiters). The
search terminates successfully as soon as a file can be opened
for reading.
Specifying a null string in the /INCLUDE qualifier causes the
compiler to do a non-standard search. This search path is as
follows:
1. The current directory (quoted form only)
2. Any directories specified in the /INCLUDE qualifier
3. The directory of the primary input file
4. Text libraries specified on the command line using /LIBRARY
For standard searches, the search order is as follows:
1. Search the current directory (directory of the source
being processed). If angle-bracket form, search only if no
directories are specified with /INCLUDE_DIRECTORY.
2. Search the locations specified in the /INCLUDE_DIRECTORY
qualifier (if any).
3. If CXX$SYSTEM_INCLUDE is defined as a logical name, search
CXX$SYSTEM_INCLUDE:.HXX or just CXX$SYSTEM_INCLUDE:.,
depending on the qualifier /ASSUME=NOHEADER_TYPE_DEFAULT.
If nothing is found, go to step 6.
4. If CXX$LIBRARY_INCLUDE is defined as a logical name,
CXX$LIBRARY_INCLUDE:.HXX or CXX$LIBRARY_INCLUDE:., depending
on the qualifier /ASSUME=NOHEADER_TYPE_DEFAULT. If nothing is
found, go to step 6.
5. If /ASSUME=HEADER_TYPE_DEFAULT is not specified, search the
default list of locations for plain-text copies of compiler
header files as follows:
SYS$COMMON:[CXX$LIB.INCLUDE.CXXL$ANSI_DEF]
SYS$COMMON:[CXX$LIB.INCLUDE.DECC$RTLDEF_HXX].HXX
SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF].H
SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C].H
If /ASSUME=HEADER_TYPE_DEFAULT is specified, search the
default list of locations for plain-text copies of compiler
header files as follows:
SYS$COMMON:[CXX$LIB.INCLUDE.DECC$RTLDEF_HXX].HXX
SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF].H
SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C].H
SYS$COMMON:[CXX$LIB.INCLUDE.CXXL$ANSI_DEF]
6. Search the directory of the primary input file.
7. If quoted form, and CXX$USER_INCLUDE is defined as a logical
name, search CXX$USER_INCLUDE:.HXX or CXX$USER_INCLUDE:.,
depending on the /ASSUME=NOHEADER_TYPE_DEFAULT qualifier.
8. Search the text libraries. Extract the simple file name and
file type from the #include specification, and use them to
determine a module name for each text library. There are three
forms of module names used by the compiler:
1. type stripped:
The file type will be removed from the include file
specification to form a library module name. Examples:
#include Module name "FOO"
"foo.h"
#include Module name "FOO"
"foo"
#include Module name "FOO"
"foo"
2. type required:
The file type must be a part of the file name. Examples:
#include Module name "FOO.H"
"foo.h"
#include Module name "FOO."
"foo"
#include Module name "FOO."
"foo"
3. type optional:
First an attempt is made to find a module with the type
included in the module name. If this is unsuccessful, an
attempt is made with the type stripped from the module
name. If this is unsuccessful, the search moves on to the
next library.
If /ASSUME=HEADER_TYPE_DEFAULT is specified, the following
text libraries are searched in this order:
Libraries specified on the command line with the /LIBRARY
qualifier (all files, type stripped)
CXX$TEXT_LIBRARY (all files, type stripped)
DECC$RTLDEF (H files and unspecified files, type stripped)
SYS$STARLET_C (all files, type stripped)
CXXL$ANSI_DEF (unspecified files, type stripped)
Otherwise, these text libraries are searched in this order:
Libraries specified on the command line with the /LIBRARY
qualifier (all files, type optional)
CXX$TEXT_LIBRARY (all files, type optional)
CXXL$ANSI_DEF (all files, type required)
DECC$RTLDEF (H files and unspecified files, type stripped)
SYS$STARLET_C (all files, type stripped)
Two text library search examples (stop when something is
found):
Example 1
#include "foo"
1. For each library specified via the /LIBRARY qualifier:
- Look for "FOO."
- Look for "FOO"
2. Look for "FOO." in CXX$TEXT_LIBRARY
3. Look for "FOO" in CXX$TEXT_LIBRARY
4. Look for "FOO." in CXXL$ANSI_DEF (Do not look for "FOO"
because the type is required as part of the module name)
5. Look for "FOO" in DECC$RTLDEF (not "FOO." because the type
must not be part of the module name)
6. Look for "FOO" in SYS$STARLET_C (not "FOO." because the
type must not be part of the module name)
Example 2
#include "foo.h"
1. For each library specified via the /LIBRARY qualifier:
- Look for "FOO.H"
- Look for "FOO"
2. Look for "FOO.H" in CXX$TEXT_LIBRARY
3. Look for "FOO" in CXX$TEXT_LIBRARY
4. Look for "FOO.H" in CXXL$ANSI_DEF (Do not look for "FOO"
because the type is required as part of the module name)
5. Look for "FOO" in DECC$RTLDEF (not "FOO.H" because the type
must not be part of the module name)
6. Look for "FOO" in SYS$STARLET_C (not "FOO.H" because the
type must not be part of the module name)
7. If neither CXX$LIBRARY_INCLUDE nor CXX$SYSTEM_INCLUDE is
defined as a logical name, then search SYS$LIBRARY:.HXX.
2.24 - /L_DOUBLE_SIZE
/L_DOUBLE_SIZE
/L_DOUBLE_SIZE=option
/L_DOUBLE_SIZE=128 (D)
Determines how the compiler interprets the long double type. The
qualifier options are 64 and 128.
Specifying /L_DOUBLE_SIZE=64 treats all long double references
as G_FLOAT, D_FLOAT, or T_FLOAT, depending on the value of the
/FLOAT qualifier. Specifying /L_DOUBLE_SIZE=64 also defines the
macro __X_FLOAT=0.
Note: The /L_DOUBLE_SIZE=64 option is not available on I64
systems. If it is specified, the compiler issues a warning
message and uses /L_DOUBLE_SIZE=128.
Specifying /L_DOUBLE_SIZE=128 treats all long double references
as X_FLOAT. The /L_DOUBLE_SIZE=128 option also defines the macro
__X_FLOAT=1. This is the default.
2.25 - /LIBRARY
Indicates that the associated input file is a text library
containing source text modules specified in #include directives.
The compiler searches the specified library for all #include
module names that are not enclosed in angle brackets or quotation
marks. The name of the library must be concatenated with
the file specification using a plus sign. For example: CXX
DATAB/LIBRARY+APPLICATION
2.26 - /LINE_DIRECTIVES
/LINE_DIRECTIVES
/LINE_DIRECTIVES (D)
/NOLINE_DIRECTIVES
Controls whether #line directives appear in preprocessed output
files.
2.27 - /LIST
/LIST
/LIST[=file-spec] (Batch default)
/NOLIST (Interactive default)
Controls whether a listing file is produced. The default output
file extension is .LIS.
2.28 - /MACHINE_CODE
/MACHINE_CODE
/NOMACHINE_CODE (D)
Controls whether the listing produced by the compiler includes
the machine-language code generated during the compilation. If
you use this qualifier you also need to use the /LIST qualifier.
On Alpha systems, machine-language code is not added to the
listing file when object-file generation is disabled (using the
/NOOBJECT qualifier).
2.29 - /MAIN
/MAIN=POSIX_EXIT
/MAIN=POSIX_EXIT
/NOMAIN (D)
Directs the compiler to call __posix_exit instead of exit when
returning from main.
2.30 - /MEMBER_ALIGNMENT
/MEMBER_ALIGNMENT
/MEMBER_ALIGNMENT (D)
/NOMEMBER_ALIGNMENT
Directs the compiler to naturally align data structure members.
This means that data structure members are aligned on the next
boundary appropriate to the type of the member, rather than on
the next byte. For instance, a long variable member is aligned on
the next longword boundary; a short variable member is aligned on
the next word boundary.
Any use of the #pragma member_alignment or #pragma nomember_
alignment directives within the source code overrides the setting
established by this qualifier. Specifying /NOMEMBER_ALIGNMENT
causes data structure members to be byte-aligned (with the
exception of bit-field members).
2.31 - /MMS_DEPENDENCIES
/MMS_DEPENDENCIES
/MMS_DEPENDENCIES[=(option[,option)]]
/NOMMS_DEPENDENCIES (D)
Instructs the compiler to produce a dependency file. The format
of the dependency file is as follows:
object_file_name:<tab><source file name>
object_file_name:<tab><full path to first include file>
object_file_name:<tab><full path to second include file>
You can specify none, one, or both of the following qualifier
options:
FILE[=filespec] Specifies where to save the dependency file.
The default file extension for a dependency
file is .mms. Other than using a different
default extension, this qualifier uses the
same procedure that /OBJECT and /LIST use for
determining the name of the output file.
SYSTEM_INCLUDE_ Specifies whether to include dependency
FILES information about system include files
(that is, those included with #include
<filename>). The default is to include
dependency information about system include
files.
2.32 - /MODEL
/MODEL (Alpha only)
/MODEL={ANSI | ARM}
/MODEL=ARM (D)
On Alpha systems, determines the layout of C++ classes, name
mangling, and exception handling.
On I64 systems, the default (and only) object model & demangling
scheme used is the I64 Application Binary Interface (ABI). The
compiler accepts the /MODEL qualifier, but it has no effect.
On Alpha systems, /MODEL=ARM is the default and generates objects
that are link compatible with all releases prior to HP C++
version 6.3, and with all objects compiled with the /MODEL=ARM
qualifier in releases of HP C++ Version 6.3 or later. Specifying
this option defines the macro __MODEL_ARM.
The /MODEL=ANSI qualifier supports the complete ISO/ANSI C++
specification, including distinct name mangling for templates.
The ANSI model also reduces the size of C++ non-POD class
objects. Note that this option generates objects that are not
compatible with all prior and future releases of HP C++, or with
objects compiled using the /MODEL=ARM qualifier.
If you specify the /MODEL=ANSI qualifier, you must recompile
and relink (using CXXLINK/MODEL=ANSI) your entire application,
including libraries. Specifying this option defines the macro
__MODEL_ANSI.
2.33 - /NAMES
/NAMES
/NAMES=(option1,option2)
/NAMES=(UPPERCASE,TRUNCATED) (D)
Option1 converts all definitions and references of external
symbols and psects to the case specified. Option1 values are:
Option Usage
UPPERCASE Converts to uppercase.
AS_IS Leaves the case as specified in the source.
Option2 controls whether or not external names greater than 31
characters get truncated or shortened. Option2 values are:
Option Usage
/NAMES=TRUNCATED Truncates long external names to the first 31
(default) characters.
/NAMES=SHORTENED Shortens long external names.
A shortened name consists of the first 23
characters of the name followed by a 7-
character Cyclic Redundancy Check (CRC)
computed by looking at the full name, and
then a "$".
The default is /NAMES=(UPPERCASE,TRUNCATED).
NOTE
The I64 C++ compiler has some additional encoding rules that
are applied to symbol names after the ABI name mangling
is determined. All symbols with C++ linkage have CRC
encodings added to the name, are uppercased and shorten to
31 characters if necessary. Since the CRC is computed before
the name is uppercased, the symbol name is case-sensitive
even though the final name is in uppercase. /NAMES=AS_IS and
/NAMES=UPPER are not applicable to these symbols.
All symbols without C++ linkage will have CRC encodings
added if they are longer then 31 characters and
/NAMES=SHORTEN is specified. Global variables with C++
linkage are treated as if they have non-C++ linkage for
compatibility with C and older compilers.
2.34 - /NESTED_INCLUDE_DIRECTORY
/NESTED_INCLUDE_DIRECTORY
/NESTED_INCLUDE_DIRECTORY[=option]
/NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE (D)
Controls the first step in the search algorithm the compiler
uses when looking for files included using the quoted form of
the #include preprocessing directive: #include "file-spec" The
/NESTED_INCLUDE_DIRECTORY qualifier has the following options:
Option Usage
PRIMARY_ Directs the compiler to search the default file type
FILE for headers using the context of the primary source
file. This means that only the file type (".H" or ".")
is used for the default file-spec but, in addition,
the chain of "related file-specs" used to maintain
the sticky defaults for processing the next top-level
source file is applied when searching for the include
file.
INCLUDE_ Directs the compiler to search the directory
FILE containing the file in which the #include directive
itself occurred. The meaning of "directory containing"
is: the RMS "resultant string" obtained when the file
in which the #include occurred was opened, except that
the filename and subsequent components are replaced
by the default file type for headers (".H", or just
"." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect).
The "resultant string" will not have translated any
concealed device logical.
NONE Directs the compiler to skip the first step of
processing #include "file.h" directives. The compiler
starts its search for the include file in the
/INCLUDE_DIRECTORY directories.
For more information on the search order for included files, see
the /INCLUDE_DIRECTORY qualifier.
2.35 - /OBJECT
/OBJECT
/OBJECT[=file-spec]
/OBJECT=.OBJ (D)
/NOOBJECT
Controls whether the compiler produces an output object module.
The default output file extension is .OBJ.
Note that the /OBJECT qualifier has no impact on the output file
of the /MMS_DEPENDENCIES qualifier.
2.36 - /OPTIMIZE
/OPTIMIZE
/OPTIMIZE[=option]
/OPTIMIZE=(LEVEL=4,INLINE=AUTOMATIC,INTRINSICS,UNROLL=0,
NOOVERRIDE_LIMITS,TUNE=GENERIC) (D)
/NOOPTIMIZE
Controls the level of code optimization that the compiler
performs. The options are as follows:
Option Usage
LEVEL=n Selects the level of code optimization. Specify
an integer from 0 (no optimization) to 5 (full
optimization).
[NO]INLINE Provides inline expansion of functions that yield
optimized code when they are expanded. You can
specify one of the following keywords to control
inlining:
NONE No inlining is done, even if requested by
the language syntax.
MANUAL Inlines only those function calls for
which the program explicitly requests
inlining.
AUTOMATIC Inlines all of the function calls in
the MANUAL category, plus additional
calls that the compiler determines are
appropriate on this platform. On Alpha
systems, the heuristics for AUTOMATIC
are similar to those for SIZE; on I64
systems, they are more like those for
SPEED. AUTOMATIC is the default.
SIZE Inlines all of the function calls in
the MANUAL category plus any additional
calls that the compiler determines would
improve run-time performance without
significantly increasing the size of the
program.
SPEED Performs more aggressive inlining for
run-time performance, even when it might
significantly increase the size of the
program.
ALL Inlines every call that can be inlined
while still generating correct code.
Recursive routines, however, will not
cause an infinite loop at compile time.
On I64 systems, ALL is treated as if SIZE
had been specified.
Note that /OPT=INLINE=ALL is not
recommended for general use, because
it performs very aggressive inlining and
can cause the compiler to exhaust virtual
memory or take an unacceptably long time
to compile.
[NO]OVERRIDE_ Controls whether or not the compiler uses certain
LIMITS (I64 built-in limits on the size and complexity of
only) a function to "throttle back" the amount of
optimization performed in order to reduce the
likelihood that the compiler will use excessive
memory resources or CPU time attempting to optimize
the code.
The default is NOOVERRIDE_LIMITS, which means that
when compiling a function that has an unusually
large number of basic blocks, live variables, or
other properties that tend to cause the optimizer
to use extra resources, the informational message
OPTLIMEXC might be issued to notify you that
optimization has been reduced to avoid excessive
resource use.
You can choose to ignore this message or disable
it (the message is not issued on compilations with
optimization disabled).
Or you can specify /OPTIMIZE=OVERRIDE_LIMITS, which
instructs the compiler to not check the limits and
to attempt full optimization no matter how large or
complex the function, knowing that the compilation
might exhaust memory or seem to be in a loop.
If using /OPTIMIZE=OVERRIDE_LIMITS does result
in excessive resource use, you are sure that
the compiler process has plenty of memory quota
available, you are convinced that the compilation
does not contain any unusually large or complex
functions, and you can provide complete source
code, then you might want to contact your support
channel to see if there is a problem in the
compiler causing it to use more resources than
it should for the particular compilation at hand.
TUNE Specifies the preferred processor for execution.
This option makes some decisions preferentially
for the specified processor (for example, for code
scheduling). Note that code valid only for the
specified processor can be generated. However,
parallel code can be generated for processors down
to the specified architecture level if necessary;
that is, tuning specifies the preferred target,
while architecture level specifies a lower boundary
on available processor features.
For example, /ARCHITECTURE=EV56/OPTIMIZE=TUNE=EV6
specifies that the code does not need to run on
a processor older than an EV56, and that the code
will probably run on an EV6. The generated code
will run on all EV56 and later systems without any
emulation. The code might have run-time selected
conditional regions specifically for EV6. Also,
note that because emulation is provided, the code
should run, but potentially at very significantly
reduced speed, on pre-EV56 processors.
The options for TUNE are the same as the options
for /ARCH. You can specify one of the following
keywords:
GENERIC Selects instruction tuning
that is appropriate for all
implementations of the operating
system architecture. This option is
the default.
HOST Selects instruction tuning that is
appropriate for the machine on which
the code is being compiled.
ITANIUM2 Selects instruction tuning for the
(I64 only) Intel Itanium 2 processor.
EV4 (Alpha Selects instruction tuning for the
only) 21064, 21064A, 21066, and 21068
implementations of the operating
system architecture.
EV5 (Alpha Selects instruction tuning for
only) the 21164 implementation of the
operating system architecture.
EV56 (Alpha Selects instruction tuning for
only) 21164 chip implementations that
use the byte- and word-manipulation
instruction extensions of the Alpha
architecture.
Running programs compiled with the
EV56 keyword might incur emulation
overhead on EV4 and EV5 processors,
but will still run correctly on
OpenVMS Version 7.1 (or later)
systems.
PCA56 (Alpha Selects instruction tuning for the
only) 21164PC chip implementation that
uses the byte- and word-manipulation
instruction extensions and
multimedia instruction extensions
of the Alpha architecture.
Programs compiled with the PCA56
keyword might incur emulation
overhead on EV4, EV5, and EV56
processors, but will still run
correctly on OpenVMS Version 7.1
(or later) systems.
EV6 (Alpha Selects instruction tuning for
only) the first-generation 21264
implementation of the Alpha
architecture.
EV67 (Alpha Selects instruction tuning for
only) the second-generation 21264
implementation of the Alpha
architecture.
[NO]INTRINSICSControls whether certain functions are handled as
intrinsic functions without explicitly enabling
each of them as an intrinsic through the #pragma
intrinsic preprocessor directive.
Functions that can be handled as intrinsics are:
Main Group - ANSI:
abs atanl atan2l ceill cosl floorf memcpy sinf
atan atan ceil cos fabs floorl memmove sinl sin
atanf atan2f ceilf cosf floor labs memset strcpy strlen
Main Group - Non-ANSI:
alloca atand2 bzero sind
atand bcopy cosd
Printf functions:
fprintf printf sprintf
Printf non-ANSI:
snprintf
ANSI math functions that set errno, thereby
requiring /ASSUME=NOMATH_ERRNO:
acos asinf coshl log log10f powl sqrt tanf
acosf asinl exp logf log10l sinh sqrtf tanl
acosl cosh expf logl pow sinhf sqrtl tanh tanhl
asin coshf expl log10 powf sinhl tan tanhf
Non-ANSI math functions that set errno, thereby
requiring /ASSUME=NOMATH_ERRNO:
log2 tand
The /OPTIMZE=INTRINSICS qualifier works with
/OPTIMIZE=LEVEL =n and some other qualifiers to
determine how intrinsics are handled:
o If the optimization level specified is less than
4, the intrinsic-function prototypes and call
formats are checked, but normal run-time calls
are still made.
o If the optimization level is 4 or higher,
intrinsic code is generated.
o Intrinsic code is not generated for math
functions that set the errno variable unless
/ASSUME=NOMATH_ERRNO is specified. Such math
functions, however, do have their prototypes and
call formats checked.
The default is /OPTIMIZE=INTRINSICS, which turns
on this handling.
To turn it off, use /NOOPTIMIZE or
/OPTIMIZE=NOINTRINSICS.
UNROLL=n Controls loop unrolling done by the optimizer.
Specify a positive integer to indicate the number
of times to unroll loop bodies. If you specify 0
or do not supply a value, the optimizer determines
its own unroll amount. The default is UNROLL=0.
Specifying UNROLL=1 effectively disables loop
unrolling.
On I64 systems, you do not have the ability to
control the number of times a loop is unrolled. You
can either disable loop unrolling with UNROLL=1,
or accept the UNROLL=0 default, which lets the
optimizer determine the unroll amount.
The default is /OPTIMIZE, which is equivalent to
/OPTIMIZE=LEVEL=4.
2.37 - /PENDING_INSTANTIATIONS
/PENDING_INSTANTIATIONS
/PENDING_INSTANTIATIONS[=n]
/PENDING_INSTANTIATIONS=64(D)
Limit the depth of recursive instantiations so that infinite
instantiation loops can be detected before some resource is
exhausted. The /PENDING_INSTANTIATIONS qualifier requires a
positive non-zero value as argument and issues an error when
n instantiations are pending for the same class template. The
default value for n is 64.
2.38 - /POINTER_SIZE
/POINTER_SIZE
/POINTER_SIZE=option
/NOPOINTER_SIZE (D)
Controls whether pointer-size features are enabled, and whether
pointers are 32 bits or 64 bits long.
On both Alpha and I64 systems, the default is /NOPOINTER_SIZE,
which disables pointer-size features, such as the ability to use
#pragma pointer_size, and directs the compiler to assume that all
pointers are 32-bit pointers. This default represents no change
over previous versions of HP C++.
You can specify one of the following options:
SHORT The compiler assumes 32-bit pointers.
32 Same as SHORT.
LONG The compiler assumes 64-bit pointers.
LONG[=ARGV] The compiler assumes 64-bit pointers. If the ARGV
option to LONG or 64 is present, the main argument
argv will be an array of long pointers instead of an
array of short pointers. (I64 only)
64 Same as LONG.
Specifying /POINTER_SIZE=32 directs the compiler to assume that
all pointers are 32-bit pointers. But unlike the default of
/NOPOINTER_SIZE, /POINTER_SIZE=32 enables use of the #pragma
pointer_size long and #pragma pointer_size short preprocessor
directives to control pointer size throughout your program.
Specifying /POINTER_SIZE=64 directs the compiler to assume that
all pointers are 64-bit pointers, and also enables use of the
#pragma pointer_size directives.
2.39 - /PREFIX_LIBRARY_ENTRIES
/PREFIX_LIBRARY_ENTRIES
/PREFIX_LIBRARY_ENTRIES=(option,...)
/NOPREFIX_LIBRARY_ENTRIES
/PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES (D)
Controls C Run-Time Library (RTL) name prefixing. For user
programs that do not include the ANSI header files but call the
ANSI library, the compiler automatically adds a DECC$ prefix to
all C RTL library calls just before the name for the external
reference or global definition is put into the object file. The
C RTL shareable image (DECC$SHR.EXE) resides in IMAGELIB.OLB
with a DECC$ prefix for its entry points. Every external name in
IMAGELIB.OLB has a DECC$ prefix, and, therefore, has an OpenVMS-
conformant name space (a requirement for inclusion in IMAGELIB).
The options are as follows:
Option Usage
EXCEPT=(name,...)The names specified are not prefixed.
ALL_ENTRIES All HP C++ names are prefixed.
Note: ALL_ENTRIES prefixes all functions defined
by the C99 standard, including those that
may not be supported in the current run-time
library. So calling functions introduced in
C99 that are not yet implemented in the OpenVMS
C RTL will produce unresolved references to
symbols prefixed by DECC$ when the program is
linked. In addition, the compiler will issue a
CC-W-NOTINCRTL message when it prefixes a name
that is not in the current C RTL.
ANSI_C89_ Only ANSI/ISO C library names are prefixed.
ENTRIES
RTL=name References to the C RTL, indicated by NAME,
are generated. NAME must be 1017 characters or
fewer.
If you want no names prefixed, specify /NOPREFIX_LIBRARY_ENTRIES.
2.40 - /PREPROCESS_ONLY
/PREPROCESS_ONLY
/PREPROCESS_ONLY[=filename]
/NOPREPROCESS_ONLY (D)
Causes the compiler to perform only the actions of the
preprocessor phase and write the resulting processed text out
to a file. The default output file extension is .IXX. Use of
/PREPROCESS_ONLY prevents the generation of an object or XREF
file.
2.41 - /PSECT_MODEL
/PSECT_MODEL
/PSECT_MODEL=MULTILANGUAGE
/PSECT_MODEL=NOMULTILANGUAGE (D)
Controls whether the compiler allocates the size of overlaid
psects to ensure compatibility when the psect is shared by code
created by other HP compilers.
This qualifier solves a problem that can occur when a psect
generated by a Fortran COMMON block is overlaid with a psect
consisting of a C struct. Because Fortran COMMON blocks are not
padded, if the C struct is padded, the inconsistent psect sizes
can cause linker error messages.
Compiling with /PSECT_MODEL=MULTILANGUAGE ensures that
the compiler uses a consistent psect size allocation
scheme. The corresponding Fortran squalifier is
/ALIGN=COMMON=[NO]MULTILANGUAGE.
The default is /PSECT=NOMULTILANGUAGE, which should be sufficient
for most applications.
2.42 - /PURE_CNAME
/PURE_CNAME
/PURE_CNAME (D) (/STANDARD=STRICT_ANSI)
/NOPURE_CNAME (D) (All other modes)
Affects insertion of the names into the global namespace by
<cname> headers.
In /PURE_CNAME mode, the <cname> headers insert the names into
the std namespace only, as defined by the C++ Standard. In this
mode, the __PURE_CNAME and __HIDE_FORBIDDEN_NAMES macros are
predefined by the compiler.
In /NOPURE_CNAME mode, the <cname> headers insert the name into
the std namespace and also into the global namespace. In this
mode, the __PURE_CNAME and __HIDE_FORBIDDEN_NAMES macros are not
predefined by the compiler.
The default depends on the standard mode:
o In /STANDARD=STRICT_ANSI mode, the default is /PURE_CNAME.
o In all other standard modes, the default is /NOPURE_CNAME.
Inclusion of a <name> header instead of its <cname> counterpart
(for example, <stdio.h> instead of <cstdio>) results in inserting
names defined in the header into both the std namespace and the
global namespace. Effectively, this is the same as the inclusion
of a <cname> header in /NOPURE_CNAME mode.
2.43 - /QUIET
/QUIET
/QUIET
/NOQUIET (D)
Specifying /QUIET causes the compiler to report errors like
the Version 5.n compiler (issue fewer messages). This is the
default for ARM mode (/STANDARD=ARM). All other modes default to
/NOQUIET.
Use /WARNINGS=ENABLE to enable specific messages normally
disabled with /QUIET.
2.44 - /REENTRANCY
/REENTRANCY
/REENTRANCY=option
/REENTRANCY=TOLERANT (D)
Controls the type of reentrancy that reentrant HP C RTL routines
exhibit. (See also the DECC$SET_REENTRANCY RTL routine.)
This qualifier is for use only with a module containing the main
routine.
The reentrancy level is set at run time according to the
/REENTRANCY qualifier specified while compiling the module
containing the main routine. This option affects the behavior
of the C RTL, but has no effect on the C++ libraries.
You can specify one of the following options:
Option Usage
AST Uses the __TESTBITSSI built-in function to perform
simple locking around critical sections of RTL code,
and may additionally disable asynchronous system traps
(ASTs) in locked region of codes. This type of locking
should be used when AST code contains calls to DEC C
RTL I/O routines.
MULTITHREADDesigned to be used in conjunction with the DECthreads
product. It performs DECthreads locking and never
disables ASTs.
NONE Gives optimal performance in the RTL, but does
absolutely no locking around critical sections of
RTL code. It should be used only in a single threaded
environment when there is no chance that the thread of
execution will be interrupted by an AST that would call
the HP C RTL.
TOLERANT Uses the __TESTBITSSI built-in function to perform
simple locking around critical sections of RTL code,
but ASTs are not disabled. This type of locking should
be used when ASTs are used and must be delivered
immediately. This is the default reentrancy type.
2.45 - /REPOSITORY
/REPOSITORY
/REPOSITORY=(PATHNAME [,...])
/REPOSITORY=[.CXX_REPOSITORY] (D)
Specifies a repository that C++ uses to store requested template
instantiations. The default is /REPOSITORY=[.CXX_REPOSITORY]. If
multiple repositories are specified, only the first is considered
writable and the default repository is ignored unless specified.
2.46 - /ROUNDING_MODE
/ROUNDING_MODE
/ROUNDING_MODE=option
/ROUNDING_MODE=NEAREST (D)
Lets you select an IEEE rounding mode if /FLOAT=IEEE_FLOAT is
specified. The options are as follows:
Option Usage
CHOPPED Rounds toward 0.
DYNAMIC Sets the rounding mode for IEEE floating-point
instructions dynamically, as determined from the
contents of the floating-point control register.
MINUS_ Rounds toward minus infinity.
INFINITY
NEAREST Sets the normal rounding mode (unbiased round to
nearest). This is the default.
If you specify either /FLOAT=G_FLOAT or /FLOAT=D_FLOAT, then
rounding defaults to /ROUNDING_MODE=NEAREST, with no other choice
of rounding mode.
2.47 - /RTTI
/RTTI
/RTTI (D)
/NORTTI (Alpha only)
Enables or disables support for RTTI (runtime type
identification) features: dynamic_cast and typeid. Disabling
runtime type identification can also save space in your object
file because static information to describe polymorphic C++
types is not generated. The default is to enable runtime type
information features and generate static information in the
object file. The /RTTI qualifier defines the macro __RTTI.
Note that specifying /NORTTI does not disable exception handling.
2.48 - /SHARE_GLOBALS
/SHARE_GLOBALS
/SHARE_GLOBALS
/NOSHARE_GLOBALS (D)
Controls whether the initial extern_model is shared or not
shared (for those extern_models where it is allowed). The initial
extern_model of the compiler is a fictitious pragma constructed
from the settings of the /EXTERN_MODEL and /SHARE_GLOBALS.
The default value is /NOSHARE_GLOBALS, which has the following
effects:
o When linking old object files or object libraries with newly
produced object files, you might get "conflicting attributes
for psect" messages, which can be safely ignored as long as
you are not building shareable libraries.
o The /noshare_globals default makes building shareable
libraries easier.
2.49 - /SHOW
/SHOW
/SHOW=(option[,...])
/SHOW=(HEADER,SOURCE) (D)
Used with the /LIST qualifier to set or cancel specific listing
options. You can select the following options:
Option Usage
ALL Print all listing information.
[NO]HEADER Print/do not print header lines at the top of each
page (D = HEADER)
[NO]INCLUDE Print/do not print contents of #include files (D =
NOINCLUDE)
NONE Print no listing information
[NO]SOURCE Print/do not print source file statements (D =
SOURCE)
[NO]STATISTICPrint/do not print compiler performance
statistics (D = NOSTATISTICS). On I64 systems, the
/SHOW=STATISTICS option is ignored.
2.50 - /STANDARD
/STANDARD
/STANDARD=(option)
/STANDARD=RELAXED (D)
The compiler implements the International ANSI C++ Standard. The
/STANDARD qualifier directs the compiler to interpret source code
according to certain nonstandard syntax conventions followed by
other implementations of the C++ language. The options are:
Option Usage
RELAXED Allow language constructs required by the International
ANSI C++ Standard. This mode also supports some
non-ANSI extensions and issues messages for some
nonstandard usage that does not strictly comply with
the standard. This is the default compiler mode. This
option also defines the macro __STD_ANSI. Please note
that ANSI is accepted as a synonym for RELAXED to be
compatible with previous C++ versions.
ARM Minimize source changes when compiling programs
developed using Version 5.n. This option also defines
the macro __STD_ARM. The /STANDARD=ARM qualifier uses
the pre-ansi AT&T version of the iostream library and
defines the macro __NO_USE_STD_IOSTREAM.
CFRONT As of HP C++ Version 7.1, support for /STANDARD=CFRONT
is retired.
GNU Use this option if you want to compile programs
developed using the GNU C++ compiler. This option
also defines the __STD_GNU macro. The /STANDARD=GNU
qualifier uses the pre-ansi AT&T version of the
iostream library and defines the macro __NO_USE_
STD_IOSTREAM. The following changes in behavior are
provided for compatibility with the GNU C++ compiler:
o These options are enabled by default:
/ALTERNATIVE_TOKENS
/TEMPLATE_DEFINE=LOCAL
/NOIMPLICIT_INCLUDE
o Access control is not enforced for types defined
inside a class.
o Unrecognized character escape sequences in string
literals produce an informational instead of a
warning message.
o The __INLINE keyword is enabled and is equivalent to
inline.
o The severity of the error "incompatible parameter"
(tag incompatibleprm) is reduced to warning.
o When overloading, enum types are treated as integral
types.
The following known incompatibility is not addressed in
the /STANDARD=GNU mode:
o The compiler strictly enforces the requirement
to define functions before they are used. This
requirement also applies to built-in functions such
as strlen.
MS Allow language constructs supported by the Visual C++
compiler. This option also defines the macro __STD_
MS. The /STANDARD=MS qualifier uses the pre-ansi AT&T
version of the iostream library and defines the macro
__NO_USE_STD_IOSTREAM.
STRICT_ Enforce the ANSI standard strictly but permit some ANSI
ANSI violations that should be errors to be warnings. This
option also defines the macro __STD_STRICT_ANSI. To
force ANSI violations to be issued as errors instead
of warnings, use /WARNINGS=ANSI_ERRORS in addition to
/STANDARD=STRICT_ANSI. This combination defines the
macro __STD_STRICT_ANSI_ERRORS. The /STANDARD=STRICT_
ANSI qualifier uses the ANSI/ISO standard version of
the iostream library and defines the macro __USE_STD_
IOSTREAM.
LATEST Latest C++ standard dialect (Alpha, I64).
/STANDARD=LATEST is currently equivalent to
/STANDARD=STRICT_ANSI, but is subject to change when
newer versions of the C++ standard are released.
For more information on the effect of the /STANDARD qualifier on
HP C++ compile-time error checking, "Compiler Compatibility" in
the HP C++ User's Guide for OpenVMS Systems.
2.51 - /TEMPLATE_DEFINE
/TEMPLATE_DEFINE=(option,...)
/NOTEMPLATE_DEFINE
Controls compiler behavior pertaining to the instantiation of C++
templates. See "Using Templates" in the HP C++ User's Guide for
OpenVMS Systems for details on how to instantiate templates using
this qualifier.
Note that you must specify a value for /TEMPLATE_DEFINE.
Select only one of the following optional values to determine the
template instantiation model:
Option Usage
ALL Instantiate all template entities declared
or referenced in the compilation unit,
including typedefs. For each fully
instantiated template class, all its
member functions and static data members
are instantiated even if they were not
used. Nonmember template functions are
instantiated even if the only reference
was a declaration. Instantiations are
created with external linkage. Overrides
/REPOSITORY at compile time. Instantiations
are placed in the user's object file
ALL_REPOSITORY Instantiate all templates declared or
used in the source program and put the
object code generated as separate object
files in the repository. Instantiations
caused by manual instantiation directives
are also put in the repository. This is
similar to /TEMPLATE_DEFINE=ALL except that
explicit instantiations are also put in the
repository, rather than than an external
symbol being put in the main object file.
This qualifier is useful for creating a
pre-instantiation library.
AUTOMATIC Directs the compiler to use the automatic
instantiation model of C++ templates.
/TEMPLATE_DEFINE=AUTOMATIC is the default.
NOAUTOMATIC Directs the compiler to not implicitly
instantiate templates.
IMPLICIT_LOCAL Same as /TEMPLATE_DEFINE=LOCAL, except
manually instantiated templates are placed
in the repository with external linkage.
This is useful for build systems that need
to have explicit control of the template
instantiation mechanism. This mode can
suffer the same limitations as /TEMPLATE_
DEFINE=LOCAL. This mode is the default when
/STANDARD=GNU is specified.
LOCAL Similar to /TEMPLATE_DEFINE=USED except
that the functions are given internal
linkage. This qualifier provides a
simple mechanism for getting started with
templates. The compiler instantiates as
local functions the functions used in
each compilation unit, and the program
links and runs correctly (barring problems
resulting from multiple copies of local
static variables). However, because many
copies of the instantiated functions can be
generated, this qualifier might not be not
suitable for production use.
The /TEMPLATE_DEFINE=LOCAL qualifier cannot
be used in conjunction with automatic
template instantiation. If automatic
instantiation is enabled by default, it
is disabled by the /TEMPLATE_DEFINE=LOCAL
qualifier. Explicit use of /TEMPLATE_
DEFINE=LOCAL and /TEMPLATE_DEFINE=AUTO
is an error.
USED Instantiate those template entities that
were used in the compilation. This includes
all static data members for which there are
template definitions. Overrides /TEMPLATE_
DEFINE=AUTO at compile time.
USED_REPOSITORY Like ALL_REPOSITORY, but instantiates only
templates used by the compilation. The
explicit instantiations are also put into
the repository as separate object files.
The following /TEMPLATE_DEFINE optional values are independent of
the model used and each other:
Option Usage
DEFINITION_FILE_ Specifies a string that contains a
TYPE="file-type- list of file types that are valid for
list" template definition files. Items in
the list must be separated by commas
and preceded by a period. A type is not
allowed to exceed the OpenVMS limit of 31
characters. This qualifier is applicable
only when automatic instantiation has
been specified. The default is /TEMPLATE_
DEFINE=DEF=".CXX,.C,.CC,.CPP".
PRAGMA Determines whether the compiler ignores
#pragma define_template directives
encountered during the compilation. This
qualifier lets you quickly switch to
automatic instantiation without having
to remove all the pragma directives from
your program's code base. The default is
/TEMPLATE_DEFINE=PRAGMA, which enables
#pragma define_template.
VERBOSE Turns on verbose or verify mode to display
each phase of instantiation as it occurs.
During the compilation phase, informational
level diagnostics are generated to indicate
which templates are automatically being
instantiated. This qualifier is useful as a
debugging aid.
TIMESTAMP (Alpha only applicable if a repository is being
only) used. Causes the compiler to create a
timestamp file named TIMESTAMP. in the
repository. Thereafter, instantiations are
added or regenerated only if needed; that
is, if they do not alreay exist, or if
existing ones are older than the timestamp.
Also see /REPOSITORY.
Also see /PENDING_INSTANTIATIONS.
2.52 - /UNDEFINE
/UNDEFINE
/UNDEFINE=(identifier[,...])
/NOUNDEFINE (D)
Performs the same function as the #undefine preprocessor
directive: it cancels a macro definition.
The /UNDEFINE qualifier is useful for undefining the predefined
C++ preprocessor constants. For example, if you use a
preprocessor constant to conditionally compile segments of code
specific to C++ for OpenVMS systems, you can undefine constants
to see how the portable sections of your program execute. For
example:
/UNDEFINE="deccxx"
When both /DEFINE and /UNDEFINE are present on the CXX command
line, /DEFINE is evaluated before /UNDEFINE.
2.53 - /UNSIGNED_CHAR
/UNSIGNED_CHAR
/UNSIGNED_CHAR
/NOUNSIGNED_CHAR (D)
The /UNSIGNED_CHAR qualifier changes the default for all
char types from signed to unsigned. The /NOUNSIGNED_CHAR
qualifier causes all plain char declarations to have the same
representation and set of values as signed char declarations.
2.54 - /USING_STD
/USING_STD
/USING_STD
/NOUSING_STD (D)
Controls whether standard library header files are processed as
though the compiled code were written as follows:
using namespace std;
#include <header>
These options are provided for compatibility for users who do not
want to qualify use of each standard library name with std:: or
put using namespace std; at the top of their sources.
/USING_STD turns implicit using namespace std on; this is
the default when compiling /STANDARD=ARM, /STANDARD=GNU,
/STANDARD=MS, or /STANDARD=RELAXED.
/NOUSING_STD turns implicit using namespace std off; this is the
default when compiling /STANDARD=STRICT_ANSI.
2.55 - /VERSION
/VERSION
/VERSION
/NOVERSION (D)
Causes the compiler to identify (print out) its version and
operating system. The listing file also contains the compiler
version. You cannot specify this qualifier with any other
qualifiers.
2.56 - /WARNINGS
/WARNINGS
/WARNINGS[=(option[,...])]
/WARNINGS (D)
/NOWARNINGS
Controls the issuance of compiler diagnostic messages and lets
you modify the severity of messages.
The default qualifier, /WARNINGS, outputs all enabled warning
and informational messages for the compiler mode you are using.
The /NOWARNINGS qualifier suppresses warning and informational
messages.
Options apply only to warning and informational messages.
The message-list in the following table of options can be any one
of the following:
o A single message identifier (within parentheses, or not). The
message identifier is the name following the message severity
letter on the first line of an issued message. For example, in
the following message, the message identifier is GLOBALEXT:
%CC-W-GLOBALEXT, a storage class of globaldef, globalref, or globalvalue
is a language extension.
o A comma-separated list of message identifiers, enclosed in
parentheses.
o The keyword ALL.
The options are processed and take effect in the following order:
NOWARNINGS Suppresses warnings.
NOINFORMATIONALS Suppresses informational messages.
ENABLE=message-list Enables issuance of the specified
messages. Can be used to enable specific
messages that normally would not be issued
when using /QUIET or messages disabled
with /WARNINGS=DISABLE.
DISABLE=message-list Disables issuance of the specified
messages. Can be used for any nonerror
message specified by a message number
or tag. Specify ALL to suppress all
informationals and warnings.
INFORMATIONALS=message-Sets the severity of all specified
list messages to Informational. Fatal and Error
messages cannot be made less severe. Can
also be used to enable informationals that
are disabled by default.
Note: With C++ Version 7.1, using
/WARNINGS=INFORMATIONALS=<tag> no longer
enables all other informational messages.
WARNINGS=message- Sets the severity of the specified
list messages to Warning. Fatal and Error
messages cannot be made less severe.
[NO]ANSI_ERRORS Issues error messages for all ANSI
violations when in STRICT_ANSI mode. The
default is /WARNINGS=NOANSI_ERRORS.
[NO]TAGS Displays a descriptive tag at the end
of each message. "D" indicates that the
severity of the message can be controlled
from the command line. The tag displayed
can be used as the message identifier in
the /WARNINGS qualifier options.
ERRORS=message-list Sets the severity of the specified
messages to Error.
Supplied Error and Fatal messages cannot
be made less severe. (Exception: A message
can be upgraded from Error to Fatal, then
later downgraded to Error again, but it
can never be downgraded from Error.)
Warnings and Informationals can be made
any severity.
FATALS=message-list Sets the severity of the specified
messages to Fatal.
Also see the #pragma message preprocessor directive.
2.57 - /XREF
/XREF (Alpha only)
/XREF[=file-spec]
/NOXREF (D)
Controls whether the compiler generates a file of source code
analysis information. The default file name is the file name of
the primary source file; the default file type is .XREF. Use the
SCA IMPORT command to convert an .XREF file into an analysis data
file that is ready for loading into an SCA library.
| 3 - Language Topics |
This section discusses language topics.
3.1 - Built-In Functions
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.
3.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.
3.3 - Preprocessor
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
3.4 - Predefined Macros
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
| 4 - Release Notes |
The release notes for C++ are contained in the following files:
SYS$HELP:CXX.RELEASE_NOTES
SYS$HELP:CXX_RELEASE_NOTES.PS
You can type or print these files to read the release notes
information.
| 5 - Class Library |
To access help on the C++ Class Library, enter the following
command at the DCL command prompt:
$ HELP CXXL
| 6 - Standard Library |
To access help on the C++ Standard Library, enter the following
command at the DCL command prompt:
$ HELP CXXLSTD
| 7 - Customer Support |
Premium support is available on a per-incident basis
http://www.hp.com/hps/perevent/pv_software.html
and annual contracts
http://www.hp.com/hps/os/os_openvms.html
from HP Services in the US and some other countries. In the US
and Canada, call, toll-free, 1-800-354-9000. In other countries,
support phone numbers are available on the web at:
http://welcome.hp.com/country/us/en/wwcontact.html
Free support is limited to bug reports that can be sent to
compaq_cxx.bugs@hp.com
Send a complete but short example reproducing the problem,
including the following:
o Compiler and operating system versions
o All necessary sources (such as INCLUDE files and module
sources)
o Data files
o Commands used to compile, link and run the program
o Expected results and incorrect results obtained
Please try to reduce the problem to as small a source
as possible, because we may be unable to diagnose large
applications.
We answer most quickly those problem reports that include a small
but complete reproducible example, along with descriptions of
the compile and link options used and the exact text of any
diagnostic messages or other incorrect results. Reports that
include only program fragments or involve very large applications
generally will not be accepted.
Please note that this is not a "programming consulting service"
and that you should have clear evidence of a product problem
before contacting us. If you need consulting services, please
contact HP Services.
| 8 - CXXLINK |
To access help on the CXXLINK facility, enter the following
command at the DCL command prompt:
$ HELP CXXLINK
| 9 - CXXDEMANGLE |
To access help on the CXXDEMANGLE facility, enter the following
command at the DCL command prompt:
$ HELP CXXDEMANGLE
|
|