| C++ User's Guide |    
|
| C++ User's Guide |
|
| C H A P T E R 1 |
|
The C++ Compiler |
This chapter provides information about the following:
This section provides a brief overview of the new C compiler features and functionality introduced in the Sun Studio 10 C 5.7 Compiler release. For specific explanations, follow the cross references provided for each item.
For more information about -xregs=[no%]frameptr, see Section A.2.160, -xregs=r[,r...].
Since MyClass<int> is a type, the code example does not use template-template parameters. However, in the following code example, the class template C has a parameter that is a class template, and object x is an instance of C using class template A as its argument. Member y of C has type A<int>.
The C++ standard says that nested classes have no special access to members of the enclosing class. However, most people feel this restriction is not justified because member functions have access to private members, so member classes should too. In the following example, function foo tries to access a private member of class outer. According to the C++ standard, the function has no access unless it is declared a friend function:
class outer { int i; // private in outer class inner { int foo(outer* p) { return p->i; // invalid } }; }; |
The C++ Committee is in the process of adopting a change to the access rules giving the same access to member classes that member functions have. Many compilers have implemented this rule in anticipation of the changed language rule.
To restore the old compiler behavior, disallowing the access, use the compiler option -features=no%nestedaccess. The default is -features=nestedaccess. For more information on -features, see Section A.2.19, -features=a[,a...].
Version 5.6 of the C++ compiler introduces the following improvements and new features.
This release of the compiler includes number of changes to the default values of options that are related to SPARC code generation. The changes reflect the current practice of targeting new applications to the UltraSPARC line of processors.
The changes to default values may affect existing makefiles. In particular, the changes will affect applications targeted to pre-Ultra processors. The following sections detail the new default value for the -xarch, -xcode, -xmemalign, and -xprefetch options:
The default architecture for which the C++ compiler produces code is now v8plus (UltraSPARC). Support for v7 will be dropped in a future release.
The new default yields higher run-time performance for nearly all machines in current use. However, applications that are intended for deployment on pre-UltraSPARC computers no longer execute by default on those computers. Compile with -xarch=v8 to ensure that the applications execute on those computers.
If you want to deploy on v8 systems, you must specify the option -xarch=v8 explicitly on every compiler command line as well as any link-time commands. The provided system libraries run on v8 architectures.
If you want to deploy on v7 systems, you must specify the option -xarch=v7 explicitly on every compiler command line as well as any link-time commands. The provided system libraries use the v8 instruction set. For this release, the only supported operating system for v7 is the Solaris 8 software release. When a v8 instruction is encountered, the Solaris 8 operating system interprets the instruction in software. The program runs, but performance is degraded.
For x86, -xarch defaults to generic. Note that -fast on x86 expands to -xarch=native.
For more information on -xarch, see Section A.2.105, -xarch=isa.
(SPARC) The default on v8 is -xcode=abs32. The default on v9 is -xcode=abs44. For more information, see Section A.2.114, -xcode=a.
(SPARC) The default for all v8 architectures is -xmemalign=8i. The default for all v9 architectures is -xmemalign=8s. For more information, see Section A.2.140, -xmemalign=ab
(SPARC) The default is now -xprefetch=auto,explicit. This change adversely affects applications that have essentially non-linear memory access patterns. To disable the change, specify -xprefetch=no%auto,no%explicit. For more information, see Section A.2.154, -xprefetch[=a[,a...]].
This release provides expanded SPARC support with new -xchip and -xtarget options. The -xchip and -xtarget options now support ultra3i and ultra4 as values so you can build applications that are optimized for the UltraSPARC IIIi and UltraSPARC IV processors. For more information, see Section A.2.113, -xchip=c, and Section A.2.167, -xtarget=t.
The C++ compiler supports new flags for -xarch, -xtarget, and -xchip, flags for the x86 architecture. These new flags are designed to take advantage of Pentium 3 and Pentium 4 chips in combination with the Solaris software support for SSE and SSE2 instructions on the Intel platform. Here are the new flags:
Patches to the Solaris OS and compilers to prevent execution of SSE/SSE2-compiled binaries on platforms not SSE/SSE2-enabled might be made available at a later date.
Solaris OS releases starting with the Solaris 9 4/04 OS are SSE/SSE2-enabled on Pentium 4-compatible platforms. Earlier versions of Solaris OS are not SSE/SSE2-enabled. This warning extends also to programs that employ .il inline assembly language functions or __asm( ) assembler code that utilize SSE/SSE2 instructions.
If you compile and link in separate steps, always link using the compiler and with -xarch={sse|sse2} to ensure that the correct startup routine is linked.
You can determine which combination of the new -xchip, -xtarget, and -xarch flags is appropriate for your needs by following these guidelines:
If so, the compiler makes the following expansions:
If so, the compiler makes the following expansions:
For more information, see Section A.2.105, -xarch=isa, Section A.2.113, -xchip=c, and Section A.2.167, -xtarget=t.
Traditional optimizers have been somewhat conservative due to the legacy of software written before clear language standards and new facilities, such as the volatile keyword, became common. However, now that modern programs are generally much better behaved, it is appropriate to employ more aggressive optimization. Consequently, the -O macro now expands to -xO3 instead of -xO2 on SPARC and x86 platforms.
The change in default yields higher run-time performance. However, -x03 may be inappropriate for programs that rely on all variables being automatically considered volatile. Typical programs that might have this assumption are device drivers and older multi-threaded applications that implement their own synchronization primitives. The work around is to compile with -xO2 instead of -O. For more information, see Section A.2.18, -fast.
This release of the C++ compiler provides a number of enhancements for faster run-time performance such as new options, improved loop optimization, recognition of restricted pointers, and control over function-level optimizations. The following sections detail these improvements.
The -xprefetch_auto_type option enables the compiler to generate indirect prefetches for the loops indicated by the option -xprefetch_level=[1|2|3] in the same fashion that the prefetches for direct memory accesses are generated.
Options such as -xdepend, -xrestrict, and -xalias_level can improve the optimization benefits of -xprefetch_auto_type. They affect the aggressiveness of computing the indirect prefetch candidates and therefore the aggressiveness of the automatic indirect prefetch insertion because they help produce better memory alias disambiguation information. For more information on the -xprefetch_auto_type option, see Section A.2.155, -xprefetch_auto_type=a.
The C++ compiler now supports the following options for optimization of loops. These options require additional compilation time and must be used with an optimization level of -xO3 or higher.
See Section A.2.106, -xautopar, Section A.2.116, -xdepend=[yes|no], and Section A.2.173, -xvector[={yes|no}] for more information.
C++ supports support the C compiler option -xrestrict so pointers are restricted as defined by the C99 standard.
When you specify this option, the compiler assumes that function parameters of pointer type do not refer to the same or overlapping objects. This option is somewhat more dangerous for C++ than for C, because the claim may not be true for inline functions that are defined in header files.
For more information, see Section A.2.161, -xrestrict[=f].
You can combine the #pragma opt directive with the command line option -xmaxopt to specify the level of optimization the compiler applies to individual functions.
The combination is useful when you need to reduce the optimization level for specific functions, for example to avoid a code enhancement like elimination of stack frames, or to increase optimization level for specific functions.
For more information, see Section A.2.139, -xmaxopt[=v] and Section B.2.12, #pragma opt for more information.
One of the causes of poor I/O performance could be the synchronization of C++ iostreams and C stdio. Such synchronization is required by the C++ standard and the compiler enables such synchronization by default. However, you can disable the synchronization by specifying -sync_stdio=no. For more information see Section A.2.88, -sync_stdio=[yes|no].
This release of the C compiler expands the precompiled header facility to include an automatic capability on the part of the compiler to generate the precompiled header file. You still have the option to manually generate the precompiled header file, but if you are interested in the new capability of the compiler, see Section A.2.150, -xpch=v for more information.
The C++ compiler now provides expanded support for UTF-16 character literals and numeric escapes. This compiler also supports extern inline functions.
Version 5.5 of the C++ compiler introduced support for UTF-16 string literals. This release expands support for UTF-16 character literals that use the syntax U'x' which is analogous to the U"x" syntax for strings. The same -xustr option is required to enable recognition of UTF-16 character literals. For example:
This release also supports numeric escapes in UTF-16 character and string literals, which are analogous to numeric escapes in ordinary character literals and strings. For example:
U"ab\123ef" // octal representation of character
U'\xE6' // hexadecimal representation of character
For more information, see Section A.2.172, -xustr={ascii_utf16_ushort|no}.
The C++ standard says that inline functions have external linkage, like non-inline functions, unless declared static. C++ 5.6, for the first time, gives inline functions external linkage by default. If an inline function must be generated out of line (for example, if its address is needed), only one copy is linked into the final program. Previously, each object file that needed a copy had its own copy with local linkage.
This implementation of extern inline functions is compatible with binary files created by earlier compiler versions, in the sense that program behavior is no less standard-conforming than before. The old binaries might have multiple local copies of inline functions, but new code will have at most one copy of an extern inline function.
This implementation of extern inline functions is compatible with the C99 version of inline functions using the C 5.6 compiler that is included in this release. That is, following the C and C++ rules for extern inline functions, the same inline function can be defined in both C and C++ files, and only one copy of the external function will appear in the final program.
There is one incompatibility between the compilers in that the C language permits a non-inline function to support (provide the external definition for) an inline function. The C++ language has no such concept. Mixing the two approaches to inlining will result in a linker error. Consider this example:
//File a.h #ifdef __cplusplus extern "C" { #endif inline int f() {return 1;} #ifdef __cplusplus } #endif //File b.c #include "a.h" int g() {return f();} |
In file c.c, the inline function f is supported by a function that has no indication that it is supporting an inline function.
If you mix c.c with a C++ use of f as shown in d.cc, you will get a "multiple definition" error from the linker.
The solution is to inform the C compiler that the function f supports an inline function. Use the following implementation of c.c instead.
The C++ compiler (CC) supports the ISO International Standard for C++, ISO IS 14882:1998, Programming Language--C++. The readme file that accompanies the current release describes any departures from requirements in the standard.
On SPARC
platforms, the compiler provides support for the optimization-exploiting features of SPARC V8 and SPARC V9, including the UltraSPARC implementation. These features are defined in the SPARC Architecture Manuals, Version 8 (ISBN 0-13-825001-4), and Version 9 (ISBN 0-13-099227-5), published by Prentice-Hall for SPARC International.
In this document, "Standard" means conforming to the versions of the standards listed above. "Nonstandard" or "Extension" refers to features that go beyond these versions of these standards.
The responsible standards bodies may revise these standards from time to time. The versions of the applicable standards to which the C++ compiler conforms may be revised or replaced, resulting in features in future releases of the Sun C++ compiler that create incompatibilities with earlier releases.
The C++ compiler's readme file highlights important information about the compiler, including:
To view the text version of the C++ readme file, type the following at a command prompt:
To access the HTML version of the readme, in your Netscape Communicator 4.0 or compatible version browser, open the following file:
(If your C++ compiler-software is not installed in the /opt directory, ask your system administrator for the equivalent path on your system.) Your browser displays an index of HTML documents. To open the readme, find its entry in the index, then click the title.
Online manual (man) pages provide immediate documentation about a command, function, subroutine, or collection of such things.
You can display a man page by running the command:
Throughout the C++ documentation, man page references appear with the topic name and man section number: CC(1) is accessed with man CC. Other sections, denoted by ieee_flags(3M) for example, are accessed using the -s option on the man command:
The following C++ utilities are now incorporated into traditional UNIX® tools and are bundled with the UNIX operating system:
See Program Performance Analysis Tools and associated man pages for further information on these UNIX tools.
This release of C++ supports the development of applications in languages other than English, including most European languages and Japanese. As a result, you can easily switch your application from one native language to another. This feature is known as internationalization.
In general, the C++ compiler implements internationalization as follows:
Variable names cannot be internationalized and must be in the English character set.
You can change your application from one native language to another by setting the locale. For information on this and other native-language support features, see the operating system documentation.
| C++ User's Guide | 819-0496-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.
