CC(1C++)

Synopsis

   CC [flags] file . . .

Description

The C++ compilation system implements almost all of the ISO standard for the language. See the Standards Compliance section below for details. By option, it can compile with stricter checking against the 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 .ii and .ti suffixes next to the corresponding object files. These files persist across compilations. 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 __SCO_VERSION__  VvvYYYYMML
   	#assert system(unix)
   	#assert cpu(i386)
   	#assert machine(i386)
   	#assert model(ilp32)

For any -X option except -Xo:

   	#define __cplusplus 199711L

   	#define __cplusplus 1

For -Xd and -Xo:

   	#define __STDC__ 0
   	#define i386 1
   	#define unix 1

For -Xw and -Xe:

   	#define __STDC__ 1

Flags

-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. -lthread should not be used.

threadT

Causes the same effect as -Kthread, except that libthreadT (tracing) is linked. If -Kthread and -KthreadT are both specified on the command line, -KthreadT will be used and a warning will be issued. -lthreadT should not be used.

pthread

Causes the same effect as -Kthread, except that in addition POSIX threads semantics are enabled at runtime for the fork(2), raise(3C), thr_exit(3thread), and pthread_exit(3pthread) calls. -lpthread is an acceptable synonym for -Kpthread.

dollar

Specifies that the compiler should allow the character $ to be used in identifiers. Since this usage is an extension to the 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. pentium_pro optimizes for all Intel Pentium^® Pro based processors, such as the Pentium II. 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.

alloca

no_alloca

Specifies whether the compiler generates calls to alloca(3bsd) inline or not. The default is to inline, unless -Xw or -Xe is specified, in which case the default is to not inline.

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. When linking on OpenServer and passing the -Wl,-fosr5 option to ld(1), the -Kno_udk option must be used.

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). Do not specify -lC; CC will ensure that libC is linked in the proper order. Linking libC in the wrong order may cause incorrect execution behavior. Avoid specifying -lc; CC will ensure that libc is linked in the proper order. Linking libc in the wrong order may cause incorrect execution behavior. If you do specify -lc, make sure there are no other dynamic libraries specified after it. Use -Kthread (or -KthreadT) instead of -lthread (or -lthreadT) when linking with the threads library. Using -lthread (or -lthreadT) directly may cause incorrect execution behavior.

-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 path

-R list

The option is overloaded to serve two different purposes. If the option argument starts with one of the keywords related to control of precompiled header files, the whole argument is interpreted for that purpose, as described below. Otherwise, if the option argument begins with a slash or contains a colon, the whole argument is interpreted as a runpath and is passed to the linker -R option. Otherwise, the option is rejected.

-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++ 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 and .ti 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.

oipo[=dir]

Specifies that the "one instantiation per object" scheme be used. This is an advanced option that is usually not needed; see Programming in standard C and C++ in Programming in standard C and C++ for when its use may be indicated. It means that compilation of a source file produces one or more object files: one primary object file with the usual name containing no instantiations, and an object file for each separate instantiation assigned to that source file. These additional object files are placed in directory dir; the default directory is ./Template.dir.

oipo_list

Used as part of the "one instantiation per object" scheme, this finds the complete set of object files, including instantiation objects, for a given set of primary object files and write them to the standard output. It is typically used as a back-quoted command within an invocation of ar(1). When this option is specified, only object files and no source files may be present on the command line.

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++ 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. See ``Selective suppression of warning messages'' below for information on selective suppression of 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 almost all of the ISO standard. See the Standards Compliance section below for a more detailed description of this dialect. This option is the default.

w

Enable strict ISO conformance mode. This mode issues warnings when features not in the ISO standard are used, and disables features that conflict with the 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++ 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 ``full size'' structure members in the compiling phase. Bit field packing is not affected by this option. 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.

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)]

LIBDIR/values-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(). However, the saving of the process image is not done on OpenServer.

Exit codes

Examples

   $ cat <<EOF >hello.C
   #include <iostream.h>
   int main()
   {
      cout << "Hello, C++" << endl;
   }
   EOF
   $ CC hello.C
   $ a.out
   Hello, C++

   $ CC -o report report.c read_in.c write_out.c

   $ CC -c -I../include -DTRACE_ON package.C

Warnings

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).

Do not use mv.1 to move .o files after compilation; this will lose the association with any accompanying .ti or .ii files. Instead, use the CC -c -o option to rename object files during compilation.

The code generated by the C++ compilation system is safe for multithreaded applications; this includes simultaneous execution of static local variables with dynamic initialization expressions. The C++ Standard Library is also safe for multithreaded applications. This means that: all internal data structures in the library are protected against simultaneous access; simultaneous access to distinct containers is safe; and simultaneous read-only access to a shared container is safe. Simultaneous access to a shared container with at least one thread writing, however, must be protected by the application through the use of mutual exclusion primitives.

The older non-standard iostreams classes, and the old C++ Standard Components classes, both of which are provided for compatibility with existing applications, are not thread-safe.

This release of the C++ compilation system is not binary compatible with the native C++ compiler in any SCO OpenServer or UnixWare 2 releases. All sources must be recompiled; existing C++ .o, .a, and .so object files can not be used. This release is binary compatible with previous UnixWare 7 releases. However, existing .ii and .ti files should be deleted before rebuilding template-based source code with this release.

References

Programming in standard C and C++ in Programming in standard C and C++.

Stroustrup, B., The C++ Programming Language, Third Edition, Addison-Wesley, 1997.

International Standard ISO/IEC 14882:1998, Programming Language - C++.

Manual pages for the C++ Standard Library specified by the ISO standard are found in the 3C++std section. Manual pages for the older, non-standard C++ libraries present in previous releases are found in the 3C++ section.

Compatibility

Notices

Selective suppression of warning messages

   $ CC -c tr14.C
   tr14.C", line 1: warning: class "TvDataStoreWorkSpace" has no
   accessible constructors
   class TvDataStoreWorkSpace {
               ^

   $ CC -c -Wf,--display_error_number tr14.C
   "tr14.C", line 1: warning #402-D: class "TvDataStoreWorkSpace" has
   no accessible constructors
   class TvDataStoreWorkSpace {
               ^

   $ CC -c -Wf,--diag_suppress -Wf,402  tr14.C

   $ CC -c -Wf,--diag_suppress -Wf,402 -Wf,--diag_suppress -Wf,414 tr14.C

Standards compliance

By default (or with the -Xd option), the compiler implements almost all of the language and library features of the ISO standard. The only features in the standard that are not implemented are:

• Two-phase name binding in templates, as described in sections 14.6 and 14.6.2 of the standard, is not implemented.

• A partial specialization of a class member template cannot be added outside of the class definition.

• The export keyword for templates is not implemented.

• Placement delete is not implemented.

• Function-try-block (a try block that is the top-level statement of a function, constructor, or destructor) is not implemented.

• Support for multibyte characters in source is not implemented (but support for universal character set escapes such as \u05d0 is implemented).

• String literals do not have const type.

The compiler also accepts most of the preprocessing and assembly-level extensions of the SCO UnixWare 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++ in Programming in standard C and C++.