HP C++ X7.1-221 Release Notes for OpenVMS Industry Standard 64 (I64) for Integrity Servers

HP C++ X7.1-221 Release Notes for OpenVMS Industry Standard 64 (I64) for Integrity Servers

December 9, 2004

This document contains information about new and changed features in HP C++ X7.1 for OpenVMS I64 Version 8.2.

Revision/Update Information: This is a new manual

Software Version: HP C++ X7.1 for OpenVMS Industry Standard 64 for Integrity Servers Version 8.2




Hewlett-Packard Company Palo Alto, California

© Copyright 2004 Hewlett-Packard Development Company, L.P.

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

UNIX is a registered trademark of The Open Group.

Portions of the ANSI C++ Standard Library have been implemented using source licensed from and copyrighted by Rogue Wave Software, Inc. All rights reserved.

Information pertaining to the C++ Standard Library has been edited and reprinted with permission of Rogue Wave Software, Inc. All rights reserved.

Portions copyright 1994-2004 Rogue Wave Software, Inc.

Contents

1 Introduction

This document contains the release notes for HP C++ X7.1 for OpenVMS Industry Standard 64 (I64) for Integrity Servers. The HP C++ product requires OpenVMS I64 Version 8.2.

These release notes describe the new features, differences, and restrictions of the C++ X7.1 compiler for I64 systems over the C++ V6.5 compiler for Alpha systems.

This release of the compiler uses a new technology base that differs substantially from both HP C++ for OpenVMS Alpha and HP C for OpenVMS I64. Although a great deal of work has been done to make it highly compatible with HP C++ for OpenVMS Alpha, there are a number of differences that you will likely notice. Some of these differences are temporary, some are changes that will be reflected in the next version of the compiler for Alpha systems, and some are permanent. Among the permanent differences are:

2 Compiler Changes

This section contains the release notes for the C++ X7.1 compiler for OpenVMS I64 systems. See Section 3 for the release notes for the standard library, language run-time support library, and class library.

2.1 New Features in X7.1

The following new features and changes have been made since C++ Version 6.5 for OpenVMS Alpha systems.

2.1.1 cname Header Support

The C++ compiler implements section 17.4.1.2 - Headers [lib.headers] "C++ Headers for C Library Facilities" of the C++ Standard. See also Stroustrup's The C++ Programming Language, 3rd Edition sections 9.2.2 and 16.1.2.

The implementation consists of 18 <cname> headers defined in the C++ Standard: 


 
<cassert> <cctype>  <cerrno>  <cfloat> 
<ciso646> <climits> <clocale> <cmath> 
<csetjmp> <csignal> <cstdarg> <cstddef> 
<cstdio>  <cstdlib> <cstring> <ctime> 
<cwchar>  <cwctype>

As required by the C++ standard, the <cname> headers define C names in the std namespace. In /NOPURE_CNAME mode, the names are also inserted into the global namespace. See the description of the /[NO]PURE_CNAME compiler qualifier.

The <cname> headers are located in the same TLB library that contains the C++ standard and class library headers: SYS$SHARE:CXXL$ANSI_DEF.TLB.

2.1.2 /[NO]FIRST_INCLUDE Qualifier Added

The /[NO]FIRST_INCLUDE qualifier is added. It has the following format:

/[NO]FIRST_INCLUDE=(file[,...])

This qualifier includes the specified files before any source files. It 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 was: 


#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.1.3 #pragma include_directory Added

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.

The #pragma include_directory directive has the following format:

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

2.1.4 Messages

There have been some changes in the /WARNINGS qualifier. These include bug fixes and improved compatibility with the C compiler. Some changes that might affect user compilations are:

The move from Alpha systems to I64 systems will cause some minor differences in certain compiler diagnostics that are signaled from the code generator. As a result, diagnostics for unreachable code and fetches of uninitialized variables might be different on the two platforms. In addition to a change in message text, some conditions detected on one platform might not be detected on the other.

2.1.5 New Front End

A new C++ front end provides improved conformance to the C++ International Standard.

2.2 I64 Differences

This section describes differences between the C++ compiler on I64 systems and Alpha systems.

2.2.1 Quotas

The C++ compiler for I64 systems is built from a different code base than the C++ compiler for Alpha systems, and that code base is larger than the code base for Alpha. Also, I64 images tend to be somewhat larger than Alpha images in general. Image size mostly affects working-set size and the amount of pagefile quota needed to execute an image without exhausting virtual memory. If you find that programs that compile and run successfully on Alpha run out of memory on I64 systems (either during compilation or when run), you probably need to increase your pagefile quota. There are no specific guidelines at this time. You might start by doubling the quota that was sufficient on Alpha, and then use a "binary-search" approach to arrive at a better quota value for I64 systems (doubling again, or halving the increment, until your biggest programs and compilations have just enough memory, and then adding an appropriate safety margin).

2.2.2 Dialect Changes

The following dialect changes have been made:

2.2.3 ABI/Object Model changes

The object model and the name mangling scheme used by the C++ compiler on I64 systems are different from those used on Alpha systems (different from both /MODEL=ARM and /MODEL=ANSI). The I64 compiler uses the interface described by the I64 Application Binary Interface (ABI).

See http://www.codesourcery.com/cxx-abi/abi.html for a draft description of the ABI specification.

The 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 uppercase. /names=3Das_is and /names=3Dupper 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=3Dshorten is specified. Global variables with C++ linkage are treated as if they have non-C++ linkage for compatibility with C and older compilers.

2.2.4 Command-Line Qualifiers

This section describes qualifier differences for HP C++ on I64 systems.

Qualifiers/Features Not Supported on I64 Systems

The following command-line qualifiers and features are not supported on C++ for I64 systems, and are diagnosed by default because ignoring them is likely to alter program behavior:

Changed/Ignored Qualifiers

A number of other qualifiers not supported on I64 systems are, by default, silently ignored by the compiler. These qualifiers fall into two groups:

Two optional compiler messages can be enabled to diagnose most of these cases:

If you encounter porting problems, compile /WARN=ENABLE=QUALCHANGE to determine if a qualifier change might be affecting your application.

If you wish to clean up your build scripts to remove extraneous qualifiers that are not meaningful on I64 systems, you can enable the QUALNA message.

A list of these qualifiers follows:

New Qualifiers

The following command-line qualifier is new for C++ X7.1 for I64 systems:

2.2.5 Floating Point

This section describes floating-point behavior on I64 systems.

IEEE Now the Default

On OpenVMS I64 systems, /FLOAT=IEEE_FLOAT is the default floating-point representation. IEEE format data is assumed and IEEE floating-point instructions are used. There is no hardware support for floating-point representations other than IEEE, although you can specify the /FLOAT=D_FLOAT or /FLOAT=G_FLOAT compiler option.

These VAX floating-point formats are supported in the I64 compiler by generating run-time code that converts VAX floating-point formats to IEEE format to perform arithmetic operations, and then converts the IEEE result back to the appropriate VAX floating-point format. This imposes additional run-time overhead and some loss of accuracy compared to performing the operations in hardware on Alpha and VAX systems. The software support for the VAX formats is provided to meet an important functional compatibility requirement for certain applications that need to deal with on-disk binary floating-point data.

On I64 systems, the default for /IEEE_MODE is DENORM_RESULTS, which is a change from the default of /IEEE_MODE=FAST on Alpha systems. This means that by default, floating-point operations may silently generate values that print as Infinity or Nan (the industry-standard behavior), instead of issuing a fatal run-time error as they would when using VAX floating-point format or /IEEE_MODE=FAST. Also, the smallest-magnitude nonzero value in this mode is much smaller because results are allowed to enter the denormal range instead of being flushed to zero as soon as the value is too small to represent with normalization.

The conversion between VAX floating-point formats and IEEE formats on the Intel Itanium architecture is a transparent process that will not impact most applications. All you need to do is recompile your application. Because IEEE floating-point format is the default, unless your build explicitly specifies VAX floating-point format options, a simple rebuild for I64 systems will use the native IEEE formats directly. For the large class of programs that do not directly depend on the VAX formats for correct operation, this is the most desirable way to build for I64 systems.

When you compile an OpenVMS application that specifies an option to use VAX floating-point on an I64 system, the compiler automatically generates code for converting floating-point formats. Whenever the application performs a sequence of arithmetic operations, this code does the following:

  1. Converts VAX floating-point formats to either IEEE single or IEEE double floating-point formats.
  2. Performs arithmetic operations in IEEE floating-point arithmetic.
  3. Converts the resulting data from IEEE formats back to VAX formats.

Where no arithmetic operations are performed (VAX float fetches followed by stores), no conversion will occur. The code handles such situations as moves.

VAX floating-point formats have the same number of bits and precision as their equivalent IEEE floating-point formats. For most applications, the conversion process will be transparent and, therefore, a non-issue.

In a few cases, arithmetic calculations might have different results because of the following differences between VAX and IEEE formats:

These differences might cause problems for applications that do any of the following:

You can test an application's behavior with IEEE floating-point values by first compiling it on an OpenVMS Alpha system using /FLOAT=IEEE_FLOAT/IEEE_MODE=DENORM.

If that produces acceptable results, then simply build the application on the OpenVMS I64 system using the same qualifier.

If you determine that simply recompiling with an /IEEE_MODE qualifier is not sufficient because your application depends on the binary representation of floating-point values, then first try building for your I64 system by specifying the VAX floating-point option that was in effect for your VAX or Alpha build. This causes the representation seen by your code and on disk to remain unchanged, with some additional runtime cost for the conversions generated by the compiler. If this is not an efficient approach for your application, you can convert VAX floating-point binary data in disk files to IEEE floating-point formats before moving the application to an I64 system.

/IEEE_MODE Notes

On Alpha systems, 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 the following 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.

More Information

For more information on I64 floating-point behavior, see the white paper OpenVMS floating-point arithmetic on the Intel Itanium architecture at a class="udrline" href="http://www.hp.com/products1/evolution/alpha_retaintrust/download/i64-floatin http://www.hp.com/products1/evolution/alpha_retaintrust/download/i64-floating-pt-wp.pdf .

2.2.6 Intrinsics and Builtins

The C++ built-in functions available on OpenVMS Alpha systems are also available on I64 systems, with some differences, as described in this section. This section also describes built-in functions that are specific to I64 systems.

Builtin Differences on I64 Systems

The <builtins.h> header file contains comments noting which built-in functions are not available or are not the preferred form for I64 systems. The compiler issues diagnostics where using a different built-in function for I64 systems would be preferable.

Note
The comments in <builtins.h> reflect only what is explicitly present in that header file itself, and in the compiler implementation. You should also consult the content and comments in <pal_builtins.h> to determine more accurately what functionality is effectively provided by including <builtins.h> . For example, if a program explicitly declares one of the Alpha built-in functions and invokes it without having included <builtins.h> , the compiler might issue the BIFNOTAVAIL error message, regardless of whether or not the function is available through a system service. If the compilation does include <builtins.h> , and BIFNOTAVAIL is issued, then either there is no support at all for the built-in function or a new version of <pal_builtins.h> is needed.

Here is a summary of these differences on I64 systems:

Built-in Functions Specific to I64 Systems

The <builtins.h> header file contains a section at the top conditionalized to just __ia64 with the support for built-in functions specific to I64 systems. This includes macro definitions for all of the registers that can be specified to the __getReg, __setReg, __getIndReg, and __setIndReg built-in functions. Parameters that are const -qualified require an argument that is a compile-time constant.

The following lists the C++ built-in functions available on OpenVMS I64 systems. 


/* Intel compatible */ 
 
unsigned __int64 __getReg(const int __whichReg); 
 
void __setReg(const int __whichReg, unsigned __int64 __value); 
 
unsigned __int64 __getIndReg(const int __whichIndReg, 
                              __int64 __index); 
 
void __setIndReg(const int __whichIndReg, __int64 __index, 
                     unsigned __int64 __value); 
 
void __break(const int __break_arg); /* Native IA64 arg */ 
void __dsrlz(void); 
void __fc(__int64 __address); 
void __fwb(void); 
void __invalat(void); 
void __invala(void); /* alternate spelling of __invalat */ 
void __isrlz(void); 
void __itcd(__int64 __address); 
void __itci(__int64 __address); 
void __itrd(__int64 __whichTransReg, __int64 __address); 
void __itri(__int64 __whichTransReg, __int64 __address); 
void __ptce(__int64 __address); 
void __ptcl(__int64 __address, __int64 __pagesz); 
void __ptcg(__int64 __address, __int64 __pagesz); 
void __ptcga(__int64 __address, __int64 __pagesz); 
void __ptri(__int64 __address, __int64 __pagesz); 
void __ptrd(__int64 __address, __int64 __pagesz); 
void __rsm(const int __mask); 
void __rum(const int __mask); 
void __ssm(const int __mask); 
void __sum(const int __mask); 
void __synci(void); 
__int64 /*address*/ __thash(__int64 __address); 
__int64 /*address*/ __ttag(__int64 __address); 
 
/* Intel _Interlocked intrinsics */ 
 
unsigned __int64 _InterlockedCompareExchange_acq( 
                        unsigned int *__Destination, 
                        unsigned __int64 __Newval, 
                        unsigned __int64 __Comparand); 
 
unsigned __int64 _InterlockedCompareExchange64_acq( 
                        unsigned __int64 *__Destination, 
                        unsigned __int64 __Newval, 
                        unsigned __int64 __Comparand); 
 
unsigned __int64 _InterlockedCompareExchange_rel( 
                        unsigned int *__Destination, 
                        unsigned __int64 __Newval, 
                        unsigned __int64 __Comparand); 
 
unsigned __int64 _InterlockedCompareExchange64_rel( 
                        unsigned __int64 *__Destination, 
                        unsigned __int64 __Newval, 
                        unsigned __int64 __Comparand); 
 
/* GEM-added builtins */ 
 
void __break2(__Integer_Constant __break_code, 
                        unsigned __int64 __r17_value); 
 
void __flushrs(void); 
void __loadrs(void); 
int __prober(__int64 __address, unsigned int __mode); 
int __probew(__int64 __address, unsigned int __mode); 
unsigned int __tak(__int64 __address); 
__int64 __tpa(__int64 __address); 
 
/* _Interlocked* builtins return the old value and have the 
** newval and comparand arguments in a different order than 
** __CMP_SWAP* builtins that return the status (1 or 0). 
** Forms without trailing _ACQ or _REL are equivalent to 
** the _ACQ form. On Alpha, _ACQ generates MB after the swap, 
** _REL generates MB before the swap. 
*/ 
 
int __CMP_SWAP_LONG(volatile void *__addr, 
                    int __comparand, 
                    int __newval); 
 
int __CMP_SWAP_QUAD(volatile void *__addr, 
                    __int64 __comparand, 
                    __int64 __newval); 
 
int __CMP_SWAP_LONG_ACQ(volatile void *__addr, 
                    int __comparand, 
                    int __newval); 
 
int __CMP_SWAP_QUAD_ACQ(volatile void *__addr, 
                    __int64 __comparand, 
                    __int64 __newval); 
 
int __CMP_SWAP_LONG_REL(volatile void *__addr, 
                    int __comparand, 
                    int __newval); 
 
int __CMP_SWAP_QUAD_REL(volatile void *__addr, 
                    __int64 __comparand, 
                    __int64 __newval); 
 
/* 
** Produce the value of R26 (Alpha) or B0 (IA64) on entry to the 
** function containing a call to this builtin. Cannot be invoked 
** from a function with nonstandard linkage. 
*/ 
__int64 __RETURN_ADDRESS(void);

2.2.7 memcpy C Run-Time Library Function

Programs must not use memcpy with overlapping arguments.

HP C++ for OpenVMS I64 optimizes the use of standard C library functions memcpy and memmove somewhat differently than HP C for OpenVMS I64 and the HP C and C++ compilers for OpenVMS Alpha. Because of this, the use of memcpy with arguments that overlap in memory can produce results that differ from the other compilers.

Note that the behavior of memcpy is formally undefined if its arguments overlap; only memmove should be used in this case. However, the other compilers generally treat memcpy in a way that handles overlapping arguments in the same way as memmove , while HP C++ for OpenVMS I64 does not. So when using memcpy , take care that the arguments do not refer to memory that might overlap; if overlap is a possibility, you must use memmove instead of memcpy .

2.2.8 Features Not Yet Supported on I64 Systems

The following feature is not yet supported on I64 systems:

2.2.9 ELF

ELF Used on I64 systems.

On OpenVMS Alpha systems, the C++ compiler uses a proprietary object format specific to OpenVMS.

On OpenVMS I64 systems, the compiler generates ELF objects. ELF is an industry standard object format used on many UNIX platforms, including Linux. This change should be transparent to most users; it is primarily of interest to compiler and tools developers. The greatest benefit of this change is that it should make it easier to create development tools that work on OpenVMS and other platforms.

Extensions to ELF have been used as needed to provide functionality unique to OpenVMS. See the a class="udrline" href="/doc/v81final/pdf/OVMS_v81_port_gd.PDF" Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers for more information on ELF.

COMDATS/Group Sections

One feature that ELF provides that is new to OpenVMS is the COMDAT section group---a group of sections in an object file that can be duplicated in one or more other object files. The linker is expected to keep one group and ignore all others. The benefit of this feature is that it permits compilers to generate definitions for symbols for things used in multiple objects without having to worry about creating a single definition in one place. The most notable uses for this feature are templates and inline functions.

New ELF Type for Weak Symbols

A new Executable and Linkable Format (ELF) type was generated to distinguish between the two types of weak symbol definitions.

For modules with ABI versions equal to 2 (the most common version used by compilers):

The Librarian supports both the ELF ABI versions 1 and 2 of the object and image file formats within the same library.

2.2.10 Templates

This section describes template instantiation for I64 systems.

Implemented using ELF COMDATS/Groups Sections

The Alpha C++ compiler had numerous models for instantiating templates. Each attempted to solve the issue of how to generate one and only one copy of each template. The use of ELF on OpenVMS I64 systems provided the compiler with the additional option of using COMDAT section groups. Since this technique is superior to all the models supported on Alpha, this is the only model supported on I64 systems.

In this model, templates are instantiated in a COMDAT section group inside every object module that uses them. This is very similar to the /TEMPLATE=LOCAL on Alpha systems, except that when the objects are linked together, the linker removes the duplicate copies. The primary advantage of this technique over /TEMPLATE=LOCAL and /TEMPLATE=IMPLICIT_LOCAL is the reduction in image size.

A secondary advantage is the elimination of distinct data for each template. For example, if a template maintained a list of elements it created, each module would have a separate copy of the list. This behavior does not conform to the standard. If you are currently using /TEMPLATE=LOCAL or /TEMPLATE=IMPLICIT_LOCAL, you will likely experience no difficulty from this change.

Not in Repository

The most visible difference that results from this new instantiation model occurs in models that instantiate templates into the repository (/TEMPLATE=AUTOMATIC|ALL_REPOSITORY|USED_REPOSITORY).

With the new model, no repository is needed. Build procedures that use CXXLINK will work transparently. Builds that attempt to manipulate objects in the repository will fail and will need to be changed. In most cases, the reason for manipulating the repository directly has been eliminated with the new template instantiation model.

2.2.11 Exceptions and Condition Handlers

The command-line option /EXCEPTIONS=NOCLEANUP is not implemented. As a result, you might see destructors being called during cleanup in code previously compiled with this option.

Exception specifications are not implemented. Exception specifications on routine declarations and definitions are accepted syntactically, but their run-time behavior has not yet been implemented.

Stack unwinding

According to the C++ Standard, an implementation may or may not unwind the stack before calling terminate when no matching handler is found for a thrown exception. On I64 systems, the implementation unwinds the stack. On Alpha systems, it does not.

Consider the following program: 


      #include <exception> 
      #include <cstdio> 
      #include <cstdlib> 
 
       class C { 
       public: 
         C() { std::printf("Created\n"); } 
         ~C() { std::printf("Destroyed\n"); } 
 
       }; 
 
       void announce1() { 
         std::printf("In terminate\n"); 
         exit(0); 
       } 
 
       int main() { 
         C c; 
         std::set_terminate(announce1); 
         throw 5; 
 
         return 0; 
       }

For the above program, the output on OpenVMS Alpha and I64 systems is: 


   Alpha:            I64: 
 
   Created           Created 
   In terminate      Destroyed 
                     In terminate

Exceptions Not Caught

The compiler assumes that the only two ways an exception can be propagated into a function are:

As a result of this assumption, some exceptions such as those thrown from a signal handler will not be caught.

2.2.12 Overriding new and delete

Full support for allowing a user to override operators new and delete is not yet completed. As a result, when you override new and delete , you might see multiply-defined symbols when linking. This will be fixed in a future release.

2.3 I64 Known Issues

Version X7.1 of the C++ compiler has the following known issues:

Qualifiers

By default the compiler's optimizer will not unroll loops. If you wish to turn the optimization on, you must compile /OPTIMIZE=UNROLL=N

Destruction of Initialized Aggregate Members

If an aggregate class/struct (such as struct B in the example below) contains a member with a destructor, and an object of that class is initialized with a brace-enclosed initializer list, and initialization of some member terminates by throwing an exception (thereby interrupting the initialization of the B object), members already completely initialized at that point will not be destructed. However, if the B object is completely initialized, each of its members will be destructed correctly. 


// Aggregate initialization, cleanup on throw 
extern "C" int printf(const char *, ...); 
int count; 
int stopon; 
struct A { 
  int n; 
  A(int i) : n(i) { 
    if (n == stopon) { 
      printf("throwing...\n"); 
      throw "help"; 
    } 
    printf("A::A(%d)\n", n); 
    count++; 
  } 
  ~A() { 
    printf("A::~A(%d)\n", n); 
    count--; 
  } 
}; 
struct B { 
  A a; 
  const A &r; 
  const A &r2; 
  A aa; 
  ~B() { printf("B::~B()\n"); } 
}; 
main () { 
  for (stopon = 1; stopon <= 5; stopon++) { 
    try { 
      B b = {1, A(2), A(3), 4}; 
      throw 5; 
    } catch (...) { 
      printf("catch\n"); 
      printf("----------\n"); 
    } 
  } 
  return !(count == 0); 
}

Debugger

3 Library Changes

For I64 systems, the C++ standard library has been upgraded and organized as a shareable image. All applicable fixes and enhancements done in the C++ standard library for Alpha systems, have been applied to the C++ standard library for I64 systems.

For I64 systems, the C++ class library is based on the same code as the C++ class library on Alpha systems. The major change in the C++ class library for I64 systems is the removal of the tasks and complex packages.

3.1 Library Reorganization

The standard library, language run-time support library, and class library have been reorganized for I64 systems.

3.1.1 Standard Library and Language Run-Time Support Library

On Alpha systems, the C++ standard library and language run-time support library is delivered in an object library, LIBCXXSTD.OLB, shipped with the compiler kit.

On I64 systems, the C++ standard library and language run-time support library are delivered as separate system shareable images shipped with the base operating system. The names of the images are: CXXL$RWRTL.EXE and CXXL$LANGRTL.EXE, respectively. The images reside in the SYS$LIBRARY directory and are installed at system startup. The LIBCXXSTD.OLB object library does not exist on I64 systems.

3.1.2 Class Library

On Alpha systems, there are three class library shareable images: CXXL$011_SHR.EXE, CXXL$011_SHRTASK.EXE, and CXXL$011_TASK.EXE.

On I64 systems, the C++ class library continues to ship as a system shareable image. Because the tasks and complex packages have been removed, there is only one class library image: CXXL$011_SHR.EXE.

3.2 Language Run-Time Support Library

The following language run-time support library change has been made:

3.3 Class Library

The following class library changes have been made:

3.4 Standard Library

This section describes changes to the C++ standard library.

3.4.1 Changes

There are two major changes in the C++ standard library for I64 systems as compared with the standard library for Alpha systems:

Additional standard library changes, known issues, and platform differences are noted in the following sections.

3.4.2 Library Headers

While from the customers' perspective the change in the library distribution model is supposed to be transparent (except that application images will be much smaller on I64 systems), users on I64 systems may find that the new C++ Standard Library is much less forgiving in terms of including all necessary library headers than the old Standard Library.

For example, the following program compiles cleanly on OpenVMS Alpha systems despite the fact that it does not include the <iostream> header necessary for the std::cout object: 


#ifndef __USE_STD_IOSTREAM 
#define __USE_STD_IOSTREAM 
#endif 
#include <fstream> 
 
using namespace std; 
 
main() { 
  cout << "hello, world"; 
}

However, on OpenVMS I64 systems, compilation fails with the following error: 


%CXX-E-UNDECLARED, identifier "cout" is undefined

It is nearly impossible to describe all combinations of library constructs and header files that would compile cleanly on Alpha systems and yet fail to compile on I64 systems because a library header required by the C++ standard for a particular construct has not been included. If a program that used to compile cleanly on an Alpha system fails to compile on an I64 system, it is always a good idea to check that all necessary library headers are included.

3.4.3 Internal Library Headers and Macros

A program that includes internal RW stdlib V2.0 library headers, like <stddefs> or <stdcomp> , or that uses internal library macros _RW_*, will have to be modified because the new C++ standard library does not necessarily have the same internal headers or use the same internal macros as the old one.

3.4.4 Known Issues

The following are known issues with C++ X7.1 for OpenVMS I64 Field Test release T8.2 and are expected to be resolved in the final release of OpenVMS V8.2:

3.4.5 Differences Between Alpha and I64 Systems

The following are differences between the I64 and Alpha standard libraries:

4 CXXLINK Changes

Because of changes in the architecture on I64 systems, CXXLINK plays a much smaller role. Its only remaining purpose is to provide human readable (demangled) names for mangled C++ names in diagnostics generated by the linker.

Specific changes are:

5 Installation

To install HP C++ X7.1 for OpenVMS I64 systems, set the default directory to a writeable directory to allow the IVP to succeed. Then run the PRODUCT INSTALL command, pointing to the kit location. For example: 


$ SET DEFAULT SYS$MANAGER 
$ PRODUCT INSTALL CXX/SOURCE=node::device:[kit_dir]

After installation, these C++ release notes will be available at:

SYS$HELP:CXX.RELEASE_NOTES

SYS$HELP:CXX_RELEASE_NOTES.PS

Here is a sample installation log: 


$ PRODUCT INSTALL CXX/SOURCE=NODE1$::DEV1$:[I64_CPP_KIT] 
 
The following product has been selected: 
    HP I64VMS CXX V7.1-155                 Layered Product 
 
Do you want to continue? [YES] 
 
Configuration phase starting ... 
 
You will be asked to choose options, if any, for each selected product and for 
any products that may be installed to satisfy software dependency requirements. 
 
HP I64VMS CXX V7.1-155: HP C++ for OpenVMS Industry Standard 
 
    Copyright 2004 Hewlett-Packard Development Company, L.P. 
 
    This software product is sold by Hewlett-Packard Company 
 
    PAKs used: DECCXX or DECCXX-USER 
 
Do you want the defaults for all options? [YES] 
 
    Copyright 2004 Hewlett-Packard Development Company, L.P. 
 
      HP, the HP logo, Alpha and OpenVMS are trademarks of 
      Hewlett-Packard Development Company, L.P. in the U.S. and/or 
      other countries. 
 
      Confidential computer software. Valid license from HP 
      required for possession, use or copying.  Consistent with 
      FAR 12.211 and 12.212, Commercial Computer Software, Computer 
      Software Documentation, and Technical Data for Commercial 
      Items are licensed to the U.S. Government under vendor's 
      standard commercial license. 
 
Do you want to review the options? [NO] 
 
Execution phase starting ... 
                                                
 
The following product will be installed to destination: 
    HP I64VMS CXX V7.1-155                 DISK$ICXXSYS:[VMS$COMMON.] 
The following product will be removed from destination: 
    HP I64VMS CXX V7.1-152                 DISK$ICXXSYS:[VMS$COMMON.] 
 
Portion done: 0%...60%...70%...80%...90%...100% 
                                                
The following product has been installed: 
    HP I64VMS CXX V7.1-155                 Layered Product 
The following product has been removed: 
    HP I64VMS CXX V7.1-152                 Layered Product 
 
%PCSI-I-IVPEXECUTE, executing test procedure for HP I64VMS CXX V7.1-155 ... 
%PCSI-I-IVPSUCCESS, test procedure completed successfully 
 
HP I64VMS CXX V7.1-155: HP C++ for OpenVMS Industry Standard 
 
    The release notes are located in the file SYS$HELP:CXX.RELEASE_NOTES 
 
      for the text form and SYS$HELP:CXX_RELEASE_NOTES.PS for the postscript form.

6 Reporting Problems

Please report problems or offer feedback using the mechanisms specified in the "Read Before Installing" document.

Contents