CC(1C++)
CC --
C++ compiler
Synopsis
CC [flags] file . . .
Description
CC invokes the C++ compilation system to compile and link C++
programs so that they may be executed.
While the command has many options, it is normally quite simple to use; see the
USAGE section below for some basic examples.
The C++ compilation system implements much, but not all, of the
upcoming ANSI/ISO standard for the language. See the Standards
Compliance section below for details.
By option, it can compile with stricter checking against the upcoming
standard.
Also by option, it can compile a dialect that corresponds to a much
older
"cfront"-based definition of the language (such as that implemented by
SCO OpenServer and its predecessors).
See the -X option
for additional descriptions of these dialects.
The compilation system consists of the following conceptual phases:
preprocessing, lexical/syntax/semantic analyzing (front end), code
generating, optimizing, basic block profiling, assembling, template
instantiating (prelinking), and linking.
The CC command examines its options and filename suffixes,
and then executes the proper phases with appropriate options and arguments.
The CC command recognizes the following filename suffixes:
- .C, .c
-
A file that contains unprocessed C++ source;
all phases are applicable. This is the most common usage.
In addition to these two suffixes, the following suffixes are also
recognized as unprocessed C++ source files, for compatibility with
the conventions of other systems: .cpp, .CPP, .cxx,
.CXX, .cc, .CC, .c++, and .C++.
- .i
-
A file that contains preprocessed C++ source;
all phases except for preprocessing are applicable.
- .s
-
A file that contains assembly language source;
only the assembling and linking phases are applicable.
- other
-
A file that contains input applicable only to the linking phase.
This category commonly includes object files (.o),
archive libraries (.a),
and shared object libraries (.so).
If no options are present,
the CC command sends all files through the phases
(as appropriate to their suffixes)
necessary to combine them into
a dynamically linked executable with the name a.out
in the current directory.
If an intermediate result is requested instead,
it is similarly placed in the current directory,
with a filename derived by replacing the incoming suffix
with a suffix appropriate to the resultant file.
If the assembling phase occurs,
the CC command places the object file (.o)
in the current directory,
but this file will be removed
if a single source file is being compiled through to an executable.
If automatic template instantiation is requested, the compiler will
place files with an .ii suffix next to the corresponding object files.
Also, any file in the current directory with the suffix .int.c
may be overwritten and removed.
All other intermediate files
are placed in a temporary directory.
(The choice of directory can be controlled
with the environment variable TMPDIR.)
The prefix part of a filename cannot be empty.
An exception to the filename suffix rule is that any filename,
regardless of suffix, will be accepted with the -E option.
This allows the C++ preprocessor to be invoked as a standalone tool for
use with non-C++ source files.
During the preprocessing phase, certain macros and assertions are defined,
some of which are based on the C++ dialect (-X option) being
compiled. These are:
For any -X option:
#define __USLC__ 1
#define __cplusplus 1
#assert system(unix)
#assert cpu(i386)
#assert machine(i386)
#assert model(ilp32)
For -Xd and -Xo:
#define __STDC__ 0
#define i386 1
#define unix 1
For -Xw and -Xe:
#define __STDC__ 1
Flags
CC takes the following options.
Except where noted, the order in which they are specified is not significant.
- -B str
-
Controls the linking phase library name search mechanism
for subsequent -l options.
The most common option arguments for str are dynamic
(the initial setting) and static, but others exist; see
ld(1).
The order of the -B, -L, and -l options is significant;
see the -l option.
- -C
-
Causes all C++ comments other than on directive lines to be retained;
otherwise, they are removed by the preprocessing phase.
- -c
-
Suppresses the linking phase.
No produced object files (.o) are removed.
- -D name[=tokens]
-
Causes name to be defined to the preprocessor
as a macro to be replaced by tokens,
or by ``1'' if ``=''tokens is not present,
as if by a #define directive.
- -d str
-
Determines the mode of the executable result of the linking phase.
If str is y (the default),
a dynamically linked executable is to be produced;
if str is n,
the result will be statically linked.
- -E
-
Suppresses all phases but preprocessing,
and sends the result to the standard output.
The result will contain lines similar to preprocessing directives
and can be used for a subsequent compiling phase.
The filename being preprocessed may have any suffix.
- -f
-
Causes extra code to be generated that instruments the program to capture
free store usage information,
for use with the Standard Components
fs(3C++)
tool.
- -G
-
Causes the linking phase to produce a shared object
instead of an executable.
- -g
-
Causes the generation of information that facilitates symbolic debugging.
This option clashes with -O but has higher precedence:
debugging information is generated if both are specified.
- -H
-
Causes the preprocessor to print the pathnames of all included files,
one per line, on the standard error output.
- -I dir
-
Causes the preprocessor to search
dir for included files
whose names do not begin with /
before searching the directories
INCDIR/CC and INCDIR (in that order).
The directories for multiple -I options
are searched in the order specified.
Files named by #include directives using the "name" syntax are first
searched for relative to the directory of the file containing the
#include directive, while files named by
#include directives using the <name> syntax are not.
If dir is specified as ``-'', i.e. -I-,
the option indicates
the point in the list of -I options at which the search for
files named by the <name> syntax should begin. That is,
the search for <name> files should only consider directories
named in -I options following the -I-,
and INCDIR/CC and
INCDIR. For files named by the "name" syntax,
using -I- also
removes from the search path the directory of the file containing
the #include directive.
- -K list
-
Enables certain variations in code generation,
optimization
or linking,
or a combination thereof.
For those items in the following list presented in groups of two or more,
the first item is the default choice,
and at most one of each such group will be effective.
The option argument list is a comma-separated list
of one or more of the following items:
- PIC
-
Changes code generation to be position-independent. This is necessary
when compiling for shared libraries. The option argument pic is
also accepted and has the same effect. The default is to generate code
that is not position-independent.
- thread
-
Specifies whether the program will use the multi-threading facilities.
In threaded mode, arranges for the appropriate preprocessor flags to be
turned on, for thread-safe code generation to be emitted, for
thread-safe operations within the C++ support routines
and for the threading library to be linked in the correct order.
- dollar
-
Specifies that the compiler should allow the character $
to be used in identifiers. Since this usage is an extension to the
ANSI/ISO C++ Standard, use of this option with -Xw or -Xe
will result in a warning diagnostic or error diagnostic,
respectively, on the first usage of $ in an identifier.
This option may be needed when porting code from other systems.
- blended
-
- pentium
-
- pentium_pro
-
- i486
-
- i386
-
Causes code generation specifically tuned to the selected Intel
microprocessor.
blended (the default) balances the code generation choices to
work well on
all these processors.
Used only in conjunction with -O.
- ieee
-
- no_ieee
-
Controls whether the generated floating point code
strictly conforms to the IEEE floating point and C standards.
ieee (the default) specifies strict conformance.
no_ieee permits more aggressive floating
point optimization.
It assumes that the application does not change rounding modes,
does not check for exception conditions, and does not produce
NaNs or infinities.
In this mode, errno might not be set as often and exceptions
may not be raised.
- no_frame
-
- fixed_frame
-
- frame
-
Specifies the stack frame layout strategy the compiler is permitted to
use.
frame uses the %ebp register
as a dedicated stack frame pointer.
fixed_frame and no_frame
represent alternate stack layouts:
both permit %ebp to be allocated as a
general purpose register, which
usually produces faster code, but in rare
instances may cause debugging
stack traces to fail. Between the two, fixed_frame
saves instructions at the expense of stack space, while
no_frame does the reverse. fixed_frame
is advantageous for the Intel Pentium Pro processor architecture,
and is the default when -Kpentium_pro is specified.
Otherwise, no_frame is the default.
This option only applies
when the -O option is specified; unoptimized
code always uses the frame pointer layout.
Also, code subject to exception handling will often use the frame
pointer layout regardless of this option.
- no_args_in_regs
-
- args_in_regs
-
Specifies whether the compiler may perform argument
passing in registers, which produces faster code.
This is done for certain types of
calls within a translation unit, and only when -O
is specified.
A consequence of this option is that function breakpointing in
debugging,
and argument information in debugging
stack traces, may be unreliable.
-Kargs_in_regs clashes with inlining but has lower precedence;
no argument passing in registers is done if both are specified
(whether explicitly or by default).
- host
-
- no_host
-
In hosted mode (the default), the compiler assumes that function names in the
C standards are reserved and behave as described by the standard.
The compiler will be free to inline such functions.
If no_ieee is also specified, the compiler assumes that math
functions do not have NaNs or infinities as arguments and do not produce
NaNs or infinities.
- c++_inline
-
- no_inline
-
- inline
-
Specifies the degree of function inlining performed by the compiler.
With c++_inline (the default), those functions specified by the user
as inline in the C++ source code are considered for inlining, as are
all compiler-generated functions. Inlining may not be possible for a
variety of reasons (for example, if a function calls itself recursively).
If the -v option is in use, remarks will
be issued for user-specified inline requests that cannot be honored.
With no_inline, the compiler turns all inlining off.
With inline, the compiler tries to inline every function for which
inlining can reasonably be expected to improve execution speed.
Inlining may yield better execution speed at the expense of extra code size.
The inline and c++_inline options (whether explicitly specified
or as the default) clash with the -ql option and have
lower precedence: inlining is disabled.
- loop_unroll
-
- no_loop_unroll
-
Specifies whether the compiler performs loop unrolling when optimization
is enabled (-O).
Loop unrolling (the default choice) may yield better execution speed at the expense
of extra code size.
- schar
-
- uchar
-
Specifies whether plain char types are considered signed or unsigned.
The default is signed.
- udk
-
- no_udk
-
The system uses certain heuristics in distinguishing
between binaries compiled for OpenServer using
the OpenServer application binary interface
and binaries compiled for UnixWare or UnixWare
using the binary interface specified by the
"System V Application Binary Interface Intel386
Processor Supplement." These heuristics can fail in rare cases.
The udk option can be used in cases when
the heuristcs break down. It instructs the link-editor
to add a special mark to a binary object to
positively identify it as a binary compiled
by the UnixWare compiler and intended to be
able to run on UnixWare, OpenServer and UnixWare.
no_udk indicates that no special
mark should be inserted.
Multiple -K options have the same effect as if
the separate list arguments were merged into one option.
- -L dir
-
Adds dir to the linking phase list of directories
to be searched for subsequent -l options.
The order of the -B, -L, and -l options is significant;
see the -l option.
- -l str
-
Causes the linking phase to search the library
libstr.so or libstr.a.
The order of the -B, -L, and -l options is significant.
A -l option causes the linker
to check first in the directories specified by preceding -L options
(in order)
and then in the directories of the default library search path (-YP).
If -Bdynamic is set at the point of the -l option,
each directory is checked first for libstr.so
and then libstr.a;
otherwise,
only libstr.a is checked.
See also
ld(1).
- -O
-
Enables the optimization phase.
This option clashes with -g but has lower precedence:
the optimization phase is disabled if both are specified.
This option also clashes with -ql but has lower precedence:
the optimization phase is disabled if both are specified.
- -o str
-
Uses str as the name of the output file instead of the default name.
With no options this renames the a.out executable.
With -c this renames the generated .o object file.
With -S this renames the generated .s assembly file.
With -P this renames the generated .i preprocessed source file file.
The -o option has no effect in conjunction with the
-E or -Tprelink_objects options.
- -P
-
Suppresses all phases but preprocessing,
and places the result in a .i-suffixed file.
Unlike -E,
the result will contain no directives.
Compiling this resultant .i file produces
an executable whose line numbers match the .i
file instead of the .c file.
- -p
-
Causes extra code to be generated
that counts the number of calls to each routine.
If the linking phase is enabled,
the default library search path (-YP) is altered to
check directories that are intended to contain
similarly instrumented libraries before the usual directories.
Moreover,
different start-up object files are used
that arrange to record (in the file mon.out)
the time spent in each routine;
see
prof(1).
- -Q str
-
Controls the inclusion of compilation tool identification information
(such as an #ident directive) in the output of each phase.
If str is y (the default),
then the information will be present;
if str is n,
it will not.
- -q str
-
Causes extra code that instruments the program to be generated.
If str is p,
the behavior is the same as the -p option.
If str is l,
the basic block profiling phase is enabled
which generates extra code that counts the number of times
each source line is executed;
see
lprof(1).
If str is f, a flow profile log is created;
see
fprof(1).
The -O option clashes with -ql but has lower precedence:
the optimization phase is not enabled if both are specified.
Inlining also clashes with -ql and also has lower precedence:
inlining is not enabled if both are specified.
- -R list
-
Controls the precompilation of header files. The C++
compilation system is able to take an internal "snapshot"
of header files during compilation, save that to a file,
and then read back that snapshot during subsequent
compilations. Depending upon specific circumstances, this
can greatly reduce compilation time (although at the cost
of additional disk space usage). Precompilation of header
files may be done either automatically by the compiler or
under more user control. By default, no precompilation
of header files is done.
The option argument list is a comma-separated list of one
or more of the following items:
- auto
-
This directs the compiler to automatically look for a
qualifying precompiled header file to read in and/or
create one for use in a subsequent compilation.
- create=filename
-
Create a precompiled header file with the specified
name.
- use=filename
-
Use the precompiled header file with the specified name.
- dir=directoryname
-
Search for and create precompiled header files in the
specified directory. If not specified, the current
directory is used.
If create or use is specified with auto, then auto is
ignored. The create and use items are mutually exclusive;
if both are specified, the last one is used.
If the -v option is specified, a message will be generated
if a precompiled header file was used or created in the
current compilation.
A more detailed description of how the compiler performs
precompilation of header files, of the effect of the
different -R options, and of how source files may best be
coded to take advantage of this feature, may be found in
Programming in standard C and C++.
That topic also
describes two pragma directives, #pragma hdrstop and
#pragma no_pch, that permit the user to control the
precompilation of header files within a specific source
file.
- -S
-
Suppresses the assembling and linking phases, and produces
an assembly file (.s-suffixed file).
- -T list
-
Controls the instantiation of templates. The C++
compilation system is able to perform automatic
instantiation of templates, or control may be
fully or
partly left with the user. Automatic
instantiation
is the default, and is recommended for most uses.
Items in the following list
are presented in groups of two or more; the first item
is the default choice, and at most one of each such
group will be allowed. The option argument list is a
comma-separated list of one or more of the following items:
- auto
-
- no_auto
-
Specifies whether automatic instantiation of templates
should be done. By default, it is done.
In this mode, the compiler and a
template prelinker cooperate to determine necessary
instantiations, assign them to compilation units,
and perform
them as needed. Some of this work is done at link time
rather than compile time. Information about
instantiation assignments is kept in .ii files
alongside corresponding .o files.
- implicit
-
- no_implicit
-
Specifies whether the compiler
will use "implicit inclusion" to locate template
definitions. Implicit inclusion (the default)
means that, if the compiler needs a definition to instantiate a
template entity declared in a .h-suffixed file, then it may
implicitly include (at the end of the main source file) an equivalently
named file with a valid C++ source file suffix in the same directory, to
get the source code for the definition.
With no_implicit, template
definitions must be explicitly coded or included
into the compilation source.
- none
-
- used
-
- all
-
- local
-
These options specify what instantiations are done
when a file is compiled. none specifies
that no template entities should be instantiated,
unless automatic instantiation
is being done. This is the default, and is also
usually the appropriate mode when automatic
instantiation is done. used specifies that
those template entities that were used
in the compilation unit should be instantiated. This includes all
static data members for which there are template
definitions. all specifies to
instantiate all template entities declared or
referenced in the compilation unit. For each
fully instantiated template class, all of its
member functions and static data members will be
instantiated whether or not they were used.
Nonmember template functions will be instantiated
even if the only reference was a declaration.
local is
similar to used except that functions are given
internal linkage. This provides a very simple
mechanism for users getting started with
templates. The compiler will instantiate the
functions that are used in each compilation unit
as local functions, and the program will link and
run correctly (barring problems due to multiple
copies of local static variables). However, it is possible to
end up with many copies of the instantiated
functions, so this is not suitable for production use.
- prelink_objects
-
Specifies that the prelinking phase will run, but not
the linking phase. This is used to instantiate templates
used internally within a set of .o files, before they are
put into an archive. The prelinking phase will not run
if -c is present. If only a single source is specified,
the resulting .o is not deleted after the command (as it
would be in a full link). If -Tno_auto and -Tprelink_objects
are both specified, -Tprelink_objects is ignored.
There are a few circumstances in which the defaults are
changed. If the command is a compile and link of a
single source file with no extra object files or libraries
specified on the command line, then no_auto and used
become the default. (This allows for faster compilation
of small examples and test cases.) If used or all are
specified, then no_auto becomes the default (since
manual user control is probably wanted), but auto
can be explicitly specified if desired. If local is
specified, then auto is forced off, because local
is incompatible with automatic instantiation.
A more detailed description of how the compiler
performs template instantiation, and of the effect of
the different -T options, may be found in
Programming in standard C and C++.
That document also describes
three pragma directives, #pragma instantiate, #pragma
do_not_instantiate, and #pragma can_instantiate, that
permit the user to control the instantiation of
specific template entities or sets of template
entities.
- -U name
-
Causes name to be undefined by the preprocessor
as a macro as if by a #undef directive,
even if name is a predefined macro
or is also the subject of a -D option.
(It is necessary to use -U first when
redefining a predefined macro.)
- -V
-
Causes the CC command and each invoked tool
to print its version information,
one per line,
on the standard error output.
- -v
-
Causes the compiler to issue remarks, which are diagnostic messages
milder than warnings, and causes the prelinker to issue informational
messages about template instantiation.
- -W phase,list
-
This option is mostly used in compilation system maintenance.
It hands the argument(s) specified by the comma-separated list
(in order)
to the single compilation phase named by phase.
An argument in list can include a comma
by escaping it by a preceding \.
If more than one conceptual phase is implemented by a single tool,
all the associated argument lists are passed to the tool.
The phase names are the following:
- p
-
preprocessor
- f
-
front end
- 0
-
code generator
- 2
-
optimizer
- b
-
basic block profiler
- a
-
assembler
- t
-
prelinker
- l
-
linker
Relative to the regular options and arguments passed to the compilation phase,
the location of the arguments specified by list
is unspecified and may change.
- -w
-
Causes the compiler to suppress warning messages.
- -X str
-
Controls the interpretation of the C++ source code with respect to language dialect.
The option argument str can be one of the following:
- d
-
Compile the default dialect of the language. This implements most,
but not all, of the upcoming ANSI/ISO standard.
See the Standards Compliance section below for a more detailed
description of this dialect. This option is the default.
- w
-
Enable strict ANSI/ISO conformance mode.
This mode issues warnings when features not in the upcoming ANSI/ISO standard
are used, and disables features that conflict with the upcoming standard.
- e
-
Same as -Xw except that errors are issued instead of warnings.
- o
-
Enable old cfront transition mode.
This causes the compiler to accept language constructs and anachronisms that,
while not part of the C++ language definition, are accepted by the cfront C++
Language System (such as that implemented by SCO OpenServer and its
predecessors).
These
are described in detail in
Programming in standard C and C++.
Use of these constructs and anachronisms
is discouraged unless they occur in existing code that is
difficult to change.
- -Y str,dir
-
This option is mostly used in compilation system maintenance.
It uses the directory dir
to find the item(s) named by str.
The option argument str is one or more of the following:
- phase
-
Causes the executable for the phase (specified the same as for the -W option)
to be found in the directory dir.
If more than one conceptual phase is implemented by a single executable
and differing directories are specified for the phases,
it is unspecified which directory is used.
- d
-
Changes the directory in which to find the C++ name demangler, which is
used to demangle compiler and linker diagnostic messages.
- h
-
Changes the directory in which to find the C++ post-link editor.
- I
-
Changes either or both of the directories searched
for preprocessing phase include files.
If dir is a single directory, INCDIR is changed to
dir and INCDIR/CC is changed to dir/CC.
If it is two directories separated by a colon, dir1:dir2,
then INCDIR/CC is changed to
dir1 if dir1 is non-empty and INCDIR
is changed to dir2 if dir2 is non-empty.
In this way either or both directories can be changed.
- P
-
Changes the linking phase default library search path
to be the colon-separated list of one or more directories, dir.
(More directories can be added to the front of the path due to other options.)
- S
-
Changes the directory in which to find the implementation's
start-up object files.
- s
-
Changes the directory in which to find the Standard Components fs
tool preprocessor.
- z
-
Changes the directory in which to find the C++ post-assembly editor.
In addition to the ability to specify the directory in which to find
the various compilation phases,
if the CC command is invoked as prefixCC,
then each tool executed will be similarly prefixed,
as will the filenames for the start-up object files.
For example,
if the command ./abcCC is invoked with -Ya,../xyz,
then the assembler would be expected to have the pathname ../xyz/abcas.
As a consequence of this, if the command is renamed, it must end with the
suffix CC. This requirement includes symbolic links to the command,
but not aliases of the command (which can be named anything).
- -Z str
-
Controls the packing of classes and structures in the compiling phase.
The option argument str is one of the following:
- p1
-
Selects at least one byte alignment for all class or structure members;
or, in other words, include no padding.
(This can also be specified as -Zp.)
- p2
-
Selects at least two byte alignment for class or structure members
of at least two bytes in size.
- p4
-
Selects two byte alignment for two byte sized class or structure members
and four byte alignment for larger class or structure members.
This is the default.
The CC command recognizes
-e, -h, -u, and -z
as linking phase options with arguments.
These, and all other unrecognized option-like arguments
are handed to
ld(1).
(A minor exception is the linking phase -s
option. Instead of passing it to the linker,
strip(1)
is run,
so as not to interfere with C++ post-link editing.)
Finally,
the CC command also recognizes the option -#.
If one -# option is present,
the CC command will print each tool with its options and argument
just before it is invoked.
With two -# options,
the pathname of each tool is also printed.
With three -# options, the information is printed but the actual
invocations of the tools are skipped.
All -# information is written to the standard error output.
Files
- a.out
-
default name of resulting executable
- INCDIR/CC
-
next-to-last directory to search for include files
- INCDIR
-
last directory to search for include files
- LIBDIR/
crt1.o,
Crt*.o -
startup code object files
- LIBDIR/c++fe
-
preprocessor and front end
- LIBDIR/fsipp
-
Standard Components fs tool preprocessor
- LIBDIR/c++be
-
code generator
- LIBDIR/optim
-
optimizer
- LIBDIR/basicblk
-
basic block profiler
- BINDIR/as
-
assembler
- LIBDIR/asfilt
-
post-assembly editor
- LIBDIR/prelink
-
template instantiator
- BINDIR/ld
-
linker
- BINDIR/c++filt
-
C++ name demangler
- BINDIR/nm
-
object file name lister
- BINDIR/strip
-
executable file symbol stripper
- LIBDIR/libC.so
-
dynamic shared C++ standard library
- LIBDIR/libC.a
-
archive C++ standard library
- LIBDIR/libcomplex.a
-
archive C++ complex arithmetic library
- LIBDIR/libfs.a
-
Standard Components fs tool library
- LIBDIR/libc.so
-
dynamic shared C standard library
- LIBDIR/libc.a
-
archive C standard library
- LIBDIR/libcrt.a
-
runtime support archive
- DIR/libp
-
subdirectory of each LIBPATH entry in which to check for profiled libraries
- INCDIR
-
usually /usr/include
- LIBDIR
-
usually /usr/ccs/lib
- BINDIR
-
usually /usr/ccs/bin
- LIBPATH
-
usually /usr/ccs/lib:/usr/lib
- TMPDIR
-
usually /var/tmp but can be overridden by the environment variable TMPDIR
- /usr/lib/locale/locale/LC_MESSAGES/uxcds
-
language-specific message file [see LANG on
environ(5)]
- LIBDIRvalues-X?.o
-
runtime objects used to implement the -X option
Environment variables
- TMPDIR
-
location of temporary files used by the compiler
- UNWIND_STACK_BEFORE_TERMINATE
-
affects the execution of the C++ program.
If it is defined and an exception is thrown for which no matching
handler is found, the C++ support runtime will save an image of the
process in file throw.core.process-id, then unwind the stack
fully before calling std::terminate().
Exit codes
CC returns 0 on success (including the possibility of warning messages)
and non-zero on failure.
Usage
For a typical multiuser Intel i486 microprocessor-based system,
the fastest code will probably be generated
by using the -Kno_ieee,
-Kinline, and -O options,
and by using the standard include files such as <string.h>.
Examples
To create, compile and link, and execute a simple program:
$ cat <<EOF >hello.C
#include <iostream.h>
int main()
{
cout << "Hello, C++" << endl;
}
EOF
$ CC hello.C
$ a.out
Hello, C++
To compile and link a multiple source file program, with report as
the resulting executable:
$ CC -o report report.c read_in.c write_out.c
To compile a source file, specifying some information for the preprocessor,
with package.o as the resulting object file:
$ CC -c -I../include -DTRACE_ON package.C
Warnings
CC should always be used when linking; ld should
not be invoked directly if C++ is involved.
If a mode choice option (such as -Q or -X)
is specified more than once,
generally the last is used.
If a combination of options is
specified that is illogical due to one option suppressing the phase that the
other option is applicable to (for example -E and -g),
both options will be accepted, but the option for the phase that is suppressed
(in this case, -g) will have no effect.
Using the -ql option to basic block profile a program might change the behavior
of the program. This is because use of the -ql option will suppress
inlining of C++ functions (which might change the program's actions, if for example
there are incorrect order of evaluation dependencies).
The code generated by the C++ compilation system, and the C++ language support
portion of the C++ Standard Library,
is safe for multithreaded applications.
However, the iostreams part of the C++ Standard Library and
the C++ Standard Components classes are not thread-safe.
This release of the C++ compilation system is not binary
compatible with previous SCO OpenServer or SCO UnixWare 1 and 2 releases.
All sources must be recompiled; existing C++ .o, .a,
and .so object files can not be used.
References
as(1),
c++filt(1C++),
debug(1),
elfmark(1),
fs(3C++),
ld(1),
lprof(1),
monitor(3C),
prof(1),
tmpnam(3S)
Programming in standard C and C++.
Ellis, M. A., and Stroustrup, B.,
The Annotated C++ Reference Manual,
Addison-Wesley, 1990.
Stroustrup, B.,
The C++ Programming Language,
Second Edition, Addison-Wesley, 1991.
Working Paper for Draft Proposed Standard for Information Systems--Programming Language C++,
X3J16/96-0219R1 WG21/N1037, American National Standards Institute, 2
December 1996.
Notices
Future directions
Future releases of the C++ compilation system will include more and more
features from the upcoming ANSI/ISO standard for the language,
leading to a release that fully conforms to the
standard once that standard has been made final.
Standards compliance
There is as yet no ANSI or ISO standard for the C++ language.
What does exist is a series of in-progress Working Papers from the X3J16/WG21
committee that is developing the C++ standard, which reflect the new
or changed language features that have been accepted by the committee so far.
By default (or with the -Xd option), the compiler accepts a dialect
of the C++ language that includes the following features from the
X3J16/WG21 Working Paper that were not found in
The Annotated C++ Reference Manual (ARM),
-
The dependent statement of an if, while, do,
or for statement is considered to be a scope, and the restriction on having
such a dependent statement be a declaration is removed.
-
The expression tested in an if, while, do,
or for statement, as the first operand of a ?: operator, or as
an operand of the &&, ||, or ! operators, may
have a pointer-to-member type or a class type that can be converted to
a pointer-to-member type in addition to the scalar cases permitted by the ARM.
-
Qualified names are allowed in elaborated type specifiers.
-
Use of a global-scope qualifier in member references of the form
x.::A::B and
p->::A::B
.
-
The precedence of the third operand of the ?: operator is changed.
-
If control reaches the end of the main() function, and main() has an
integral return type, it is treated as if a return 0; statement were executed.
-
Pointers to arrays with unknown bounds as parameter types are
diagnosed as errors.
-
A functional-notation cast of the form A() can be used even if
A is a class without a (nontrivial) constructor. The temporary created
gets the same default initialization to zero as a static object of the
class type.
-
A cast can be used to select one out of a set of overloaded
functions when taking the address of a function.
-
Template friend declarations are permitted in class definitions and
class template definitions.
-
The lifetime of temporaries is limited to full-expressions (except in
certain initialization and reference contexts).
-
A reference to const volatile cannot be bound to an rvalue.
-
Qualification conversions, such as conversion from T** to
T const * const * are allowed.
-
Digraphs are recognized.
-
Operator keywords (e.g., and, bitand, etc.) are recognized.
-
Type template parameters are permitted to have default arguments.
-
Function templates may have nontype template parameters.
-
Static data member declarations can be used to declare member constants.
-
wchar_t is recognized as a keyword and a distinct type.
-
bool is recognized.
-
RTTI (run-time type identification), including dynamic_cast and the
typeid operator, is implemented.
-
Declarations in tested conditions (in if, switch, for and
while statements) are supported.
-
Array new and delete are implemented.
-
New style casts (static_cast, reinterpret_cast and const_cast) are
implemented.
-
Definition of a nested class outside its enclosing class is allowed.
-
mutable is accepted on non-static data member declarations.
-
Namespaces are implemented, including using declarations and directives.
Access declarations are broadened to match the corresponding using
declarations.
-
Explicit instantiation of templates is implemented.
-
The typename keyword is recognized.
-
explicit is accepted to declare non-converting constructors.
-
The scope of a variable declared in the for-init-statement
of a for loop is the scope of the loop (not the surrounding
scope).
-
Member templates are implemented.
-
The new specialization syntax (using template <> is
implemented.
-
Cv-qualifiers are retained on rvalues (in particular, on function
return values).
-
The distinction between trivial and non-trivial constructors has been
implemented, as has the distinction between PODs and non-PODs with
trivial constructors.
-
The linkage specification is treated as part of the function type
(affecting function overloading and implicit conversions).
-
extern inline functions are supported, and the default
linkage for inline functions is external. However the
address of extern inline functions do not yet compare
equal across translation units.
-
A typedef name may be used in an explicit destructor call.
-
An array allocated via a placement new can be deallocated via
delete.
-
Covariant return types on overriding virtual functions are supported.
-
enum types are considered to be non-integral types.
-
Partial specialization of class templates is implemented.
-
Partial ordering of function templates is implemented.
-
Function declarations that match a function template are regarded
as independent functions, not as "guiding declarations" that are
instances of the template.
-
Koenig lookup of function names for operators is implemented.
-
The <cstdlib>, <new>, <typeinfo>,
<exception>, and <stdexcept> headers and their
contents, from the C++ Standard Library, are recognized.
In addition, by default the compiler accepts some non-standard, non-ARM language
usages. These usages are described in
Programming in standard C and C++.
Use of them is discouraged unless they occur in existing code that is
difficult to change. All such usages can be flagged via the -Xw
or -Xe options.
The compiler also accepts most of the preprocessing and assembly-level
extensions of the SCO UnixWare 1 and 2 C compiler. These include #assert,
#ident, #pragma ident, #pragma weak, #pragma
pack, old-style asms and enhanced asms. These features are
described in
Programming in standard C and C++.
The following features in the X3J16/WG21 Working Paper
(but not in the ARM) are not yet implemented:
-
Overloading operators using functions that take enumeration types and no class types.
-
New lookup rules for member references of the form x.A::B and p->A::B.
-
Enumeration types containing values larger than can be contained in an int.
-
Explicit qualification of template functions.
-
Name binding in templates in the style of X3J16/WG21 note N0288/93-0081.
-
In a reference of the form f()->g(), with g a static member
function, f() is not evaluated. This is as required by
the ARM.
The Working Paper, however, requires that f() be evaluated.
-
reinterpret_cast does not allow casting a pointer to member of one class to a
pointer to member of another class if the classes are unrelated.
-
Class name injection is not implemented.
-
Placement delete is not implemented.
-
Function-try-block is not implemented.
-
The notation :: template (and -> template, etc.
is not implemented.
-
Template template parameters are not implemented.
-
Koenig lookup of function names other than operators is not implemented.
-
Finding friend functions of the argument class types on name lookup on
the function name in calls is not implemented.
-
Support for multibyte characters in source is not implemented.
-
The C++ Standard Library, other than the five headers and their
contents mentioned above, is not included. (Older, non-standard
versions of the iostreams and complex libraries are supplied, as are
the non-standard container classes of the C++ Standard Components.)
30 January 1998
© 1998 The Santa Cruz Operation, Inc. All rights reserved.