______________________________________________ HP C++ V7.1-011 Release Notes for OpenVMS Industry Standard 64 (I64) for Integrity Servers November 24, 2004 This document contains information about new and changed features in HP C++ V7.1 for OpenVMS I64 Version 8.2. Revision/Update Information: This is a new manual Software Version: HP C++ V7.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. This document was prepared using DECdocument, Version 3.3-1n. ________________________________________________________________ Contents 1 Introduction................................. 1 2 Compiler Changes............................. 2 2.1 New Features in V7.1..................... 2 2.1.1 cname Header Support................... 2 2.1.2 /[NO]FIRST_INCLUDE Qualifier Added..... 3 2.1.3 #pragma include_directory Added........ 3 2.1.4 Messages............................... 4 2.1.5 New Front End.......................... 4 2.2 I64 Differences.......................... 5 2.2.1 Quotas................................. 5 2.2.2 Dialect Changes........................ 5 2.2.3 ABI/Object Model changes............... 6 2.2.4 Command-Line Qualifiers................ 6 2.2.5 Floating Point......................... 11 2.2.6 Intrinsics and Builtins................ 14 2.2.7 memcpy C Run-Time Library Function..... 19 2.2.8 Features Not Yet Supported on I64 Systems................................ 19 2.2.9 ELF.................................... 20 2.2.10 Templates.............................. 21 2.2.11 Exceptions and Condition Handlers...... 22 2.2.12 Overriding new and delete.............. 23 2.3 I64 Known Issues......................... 23 3 Library Changes.............................. 30 3.1 Library Reorganization................... 30 3.1.1 Standard Library and Language Run-Time Support Library........................ 30 3.1.2 Class Library.......................... 30 3.2 Language Run-Time Support Library........ 31 3.3 Class Library............................ 31 iii 3.4 Standard Library......................... 31 3.4.1 Changes................................ 31 3.4.2 Library Headers........................ 32 3.4.3 Internal Library Headers and Macros.... 33 3.4.4 Known Issues........................... 33 3.4.5 Differences Between Alpha and I64 Systems................................ 33 4 CXXLINK Changes.............................. 39 5 Installation................................. 39 6 Reporting Problems........................... 41 iv 1 Introduction This document contains the release notes for HP C++ V7.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, differ- ences, and restrictions of the C++ V7.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: o Resource requirements Programs will usually use more memory both at compile time and at run time. See Section 2.2.1. o Floating-point behaviors The default is /FLOAT=IEEE/IEEE_MODE=DENORM_RESULTS. Consistent use of qualifiers across compilations is required. See Section 2.2.5. o Simplified instantiation without repository. See Section 2.2.10. o No inline assembly language. See Section 2.2.6. o Removal of the CFRONT dialect (which will also be removed in the next release of the C++ Alpha compiler). o String literal type change. For standards-compliance and link compatiblity between compiler dialects, ordinary string literals now have the type "array of const char" in all compiler dialects on I64 systems and on Alpha systems when compiling in /MODEL=ANSI mode. 1 When compiling in /MODEL=ARM mode on Alpha systems, string literals are of type "array of char" in all compiler dialects. 2 Compiler Changes This section contains the release notes for the C++ V7.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 V7.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 headers defined in the C++ Standard: As required by the C++ standard, the 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 headers are located in the same TLB library that contains the C++ standard and class library headers: SYS$SHARE:CXXL$ANSI_DEF.TLB. 2 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 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. 3 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 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: o The /WARNINGS=ENABLE=ALL qualifier now enables all compiler messages including informational-level messages. o The /WARNINGS=INFORMATIONALS qualifier continues to enable most informationals, but we recommend that /WARNINGS=ENABLE=ALL be used instead o Using /WARNINGS=INFORMATIONALS= no longer enables all other informational messages. 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. 4 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: o Support for /STANDARD=CFRONT has been retired. o Some of the compiler dialects (options to the /STANDARD qualifier) have been updated to reflect the most recent behaviors of the compilers that the dialect is attempting to match. Other changes involve the removal of less significant or undesirable compatibility features. If a dialect has changed in a way that impacts you significantly, report it as described in Section 6. 5 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 encod- ings 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: o Comma lists are not supported. Their use provokes a fatal error. o The /INSTRUCTION_SET=[NO]FLOATING_POINT qualifier is not available on I64 systems. o /L_DOUBLE_SIZE=64 is not available on I64 systems. If it is specified, a warning message is issued, and /L_ DOUBLE_SIZE=128 is used. 6 o /POINTER_SIZE=(LONG,64) is ignored. 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: o Qualifiers that should not alter the behavior of a correct program so, if ignored, should have no visible effect. Qualifiers that enable optimizations typically have this characteristic. o Qualifiers that might affect program behavior but, if ignored, produce no significant change in the vast majority of programs. Examples of qualifiers in this category are /NORTTI (the run-time information is always generated) and /MODEL=ARM (the ANSI model is functionally superior, and binary compatibility with existing object code is not an issue for the OpenVMS I64 platform). Two optional compiler messages can be enabled to diagnose most of these cases: o The QUALNA message diagnoses uses of the first group. o The QUALCHANGE message diagnoses uses of the second group. 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: o /ARCHITECTURE=option An additional keyword has been added: ITANIUM2. If an Alpha keyword (EV4, EV5, EV56, PCA56, EV6, EV68, EV7) is specified for option, it is ignored. o /ASSUME 7 The following /ASSUME options are ignored on I64 systems and should not cause any behavior changes: NORTTI_CTORVTBLS NOPOINTERS_TO_GLOBALS TRUSTED_SHORT_ALIGNMENT WHOLE_PROGRAM o /CHECK=UNINITIALIZED_VARIABLES This qualifier has no effect in this version of the compiler. o /DISTINGUISH_NESTED_ENUMS This qualifier only modified the behavior of programs compiled with /MODEL=ARM. Since that model is not supported on the I64 platform, this qualifier is meaningless. o /EXCEPTIONS=NOCLEANUP The NOCLEANUP keyword for the /EXCEPTIONS qualifier is ignored. o /EXCEPTIONS=IMPLICIT The IMPLICIT keyword for the /EXCEPTIONS qualifier is ignored. o /FLOAT The default for /FLOAT on OpenVMS I64 systems is IEEE_ FLOAT. See Section 2.2.5 for more information about floating- point behavior on I64 systems. o /IEEE_MODE The default for /IEEE_MODE on I64 systems is DENORM_ RESULTS, which generates infinities, denorms, and NaNs without exceptions. On OpenVMS Alpha systems, the default for /IEEE_MODE when using /FLOAT=IEEE_FLOAT is FAST, which causes a FATAL error for exceptional conditions such as divide- by-zero and overflow. See Section 2.2.5 for more information. o /MACHINE_CODE 8 The /MACHINE_CODE qualifier output will appear in an .S file in the same directory as your listing file. o The /MODEL=ARM qualifier is treated the same as the default /MODEL=ANSI (except for the optional QUALCHANGE diagnostic). o /OPTIMIZE There are several changes to the /OPTIMIZE qualifier: - On I64 systems, for /OPTIMIZE=INLINE, the keywords AUTOMATIC and SPEED do the same thing. Also, the ALL keyword does not necessarily result in every possible call being inlined, as it does on Alpha systems. - The /OPTIMIZE=TUNE qualifier takes a new keyword: ITANIUM2, which is the default at this time. If you specify an Alpha keyword, it is ignored. - The /OPTIMIZE=UNROLL=n qualifier on I64 systems does not have the ability to control the specific number of times a loop is unrolled. The only accepted values are /OPTIMIZE=UNROLL=1 which disables loop unrolling, and /OPTIMIZE=UNROLL=0 which allows the compiler's optimizer to decide how the loop should be unrolled. The default is /OPTOMICE=UNROLL=0. - /OPTIMIZE=LIMIT_INLINE is ignored. o /PREFIX_LIBRARY_ENTRIES Note that /PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES prefixes all functions defined by the C99 standard including those that may not be supported in the current run- time library. So calling functions introduced in C99 that are not yet implemented in the OpenVMS C RTL will produce unresolved references to symbols prefixed by DECC$ when the program is linked. The compiler now issues a CC-W-NOTINCRTL message when it prefixes a name that is not in the current C RTL. o /TEMPLATE See Section 2.2.10 for information on template instantiation. 9 o /POINTER_SIZE=(SHORT,32) is ignored. Mixed pointer types are not supported at this time. o /SHOW=STATISTICS The /SHOW=STATISTICS qualifier is ignored at this time. o /STANDARD=CFRONT The /STANDARD=CFRONT qualifier is no longer available. If it is specified, the compiler issues a warning message and uses the default dialect, /STANDARD=ANSI. New Qualifiers The following command-line qualifier is new for C++ V7.1 for I64 systems: o /[NO]PURE_CNAME Affects insertion of the names into the global namespace by headers. In /PURE_CNAME mode, the headers insert the names into the std namespace only, as defined by the C++ Standard, and the __PURE_CNAME macro is predefined by the compiler. In /NOPURE_CNAME mode, the headers insert the name into the std namespace and also into the global namespace. The default depends on the standard mode: - In /STANDARD=STRICT_ANSI mode, the default is /PURE_ CNAME. - In all other standard modes, the default is /NOPURE_ CNAME. Inclusion of a header instead of its counterpart (for example, instead of ) results in inserting names defined in the header into both the std namespace and the global namespace. Effectively, this is the same as the inclusion of a header in the /NOPURE_CNAME mode. See Section 2.1.1 for more information. 10 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 11 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: o Values of numbers represented o Rounding rules o Exception behavior These differences might cause problems for applications that do any of the following: o Depend on exception behavior o Measure the limits of floating-point behaviors o Implement algorithms at maximal processor-specific accuracy 12 o Perform low-level emulations of other floating-point processors o Use direct equality comparisons between floating-point values, instead of appropriately ranged comparisons (a practice that is extremely vulnerable to changes in compiler version or compiler options, as well as architecture) 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 13 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 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 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. 14 ________________________Note ________________________ The comments in 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 to determine more accurately what functionality is effectively provided by including . For example, if a program explicitly declares one of the Alpha built-in functions and invokes it without having included , 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 , and BIFNOTAVAIL is issued, then either there is no support at all for the built-in function or a new version of is needed. _____________________________________________________ Here is a summary of these differences on I64 systems: o There is no support for the asm, fasm, and dasm intrinsics (declared in the header file). o The functionality provided by the special-case treatment of R26 in an Alpha system asm, as in asm("MOV R26,R0"), is provided by a new built-in function for I64 systems: __int64 __RETURN_ADDRESS(void); This built-in function produces the address to which the function containing the built-in call will return (the value of R26 on entry to the function on Alpha systems; the value of B0 on entry to the function on I64 systems). This built-in function cannot be used within a function specified to use nonstandard linkage. o The only PAL function calls implemented as built- in functions within the compiler are the 24 queue- manipulation builtins. The queue manipulation builtins generate calls to new OpenVMS system services SYS$, where is the name of the builtin with the leading underscores removed. 15 Any other OpenVMS PAL calls are supported through macros defined in the header file included in the header file. Typically, the macros in transform an invocation of an Alpha system builtin into a call to a system service that performs the equivalent function on an I64 system. Two notable exceptions are __PAL_GENTRAP and __PAL_BUGCHK, which instead invoke the I64 specific compiler builtin __break2. o There is no support for the various floating-point built-in functions used by the OpenVMS math library (for example, operations with chopped rounding and conversions). o Most built-in functions that take a retry count are not supported. This is necessary because the retry behavior allowed by Alpha load-locked/store-conditional sequences does not exist on I64 systems. There are two exceptions to this: __LOCK_LONG_RETRY and __ACQUIRE_ SEM_LONG_RETRY; in these cases, the retry behavior involves comparisons of data values, not just load- locked/store-conditional. o The __CMP_STORE_LONG and __CMP_STORE_QUAD built-in functions are not supported. Use the new __CMP_SWAP form instead. Built-in Functions Specific to I64 Systems The 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. 16 /* 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); 17 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); 18 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: o 64-bit pointers 64-bit pointers are not yet supported on I64 systems. If you need 64-bit support, see Section 6. 19 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 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): o Type STB_WEAK represents the UNIX-style weak symbol (formerly, the OpenVMS-style weak symbol definition for ABI Version 1 ELF format). 20 o Type STB_VMS_WEAK represents the OpenVMS-style of weak symbol definition. 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 instantiat- ing 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). 21 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 #include #include class C { public: C() { std::printf("Created\n"); } ~C() { std::printf("Destroyed\n"); } }; void announce1() { std::printf("In terminate\n"); exit(0); } 22 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: o From a throw expression, or o From a routine call that itself can throw an exception. 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 V7.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 23 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; 24 } catch (...) { printf("catch\n"); printf("----------\n"); } } return !(count == 0); } Debugger o Optimized debugging is not supported in HP C++ V7.1 for OpenVMS I64 systems. o Examining floating point values when compiling /FLOAT=(D_FLOAT,G_FLOAT) On OpenVMS I64 systems, the default floating point type is IEEE. If you compile your program with any of these qualifiers: /G_FLOAT, /FLOAT=(D_FLOAT) or /FLOAT=(G_FLOAT) your floating point numbers will be represented internally as integers. Therefore to examine them as floating point values, you must specify the appropriate data type (EXAMINE/D_FLOAT, EXAMINE/G_FLOAT or EXAMINE/F_FLOAT) when using the EXAMINE command in the OpenVMS I64 debugger. o Inherited Data Members You cannot specify multiple base names. For exam- ple, in the program below, to examine member f_ member, we can say: "examine j_object.f_member" or "examine j_object.I::f_member" but we cannot say "j_ object.I::G::f_member". struct A { int a_member; }; struct B : A { int b_member; }; struct C { int c_member; }; struct D : B, C { int d_member; }; struct E : D { int e_member; }; struct F { int f_member; }; struct G : F { int g_member; }; struct H : E, G { int h_member; }; struct I : H { int i_member; }; struct J : I { int j_member; }; 25 static J j_object; main(){ j_object.j_member = 1; } DBG> exam j_object.B::A::a_member %DEBUG-W-NOFIELD, 'B::A::a_member' is not a field in this record DBG> deposit j_object.I::a_member = 13 o Breakpoints on opening and closing braces of a function The OpenVMS I64 debugger may give unexpected results when examining values at the final brace (}) of a routine. On OpenVMS I64 systems, a workaround to set a break on the last source line of a routine. This is because destructors for the routine may run after the final source line and before the final (}). o Overloaded Functions If you attempt to set a break on an overloaded function without providing the argument list, debug may display the %DEBUG-E-NOSYMBOL message instead of displaying the overload list. To see the list of overloaded functions use the sho symbol command. Currently there is a problem with setting breakpoints on an operator. By using the %name feature of debug, it should be possible to set a breakpoint on an a user defined operator, just as one can set a breakpoint on a user defined destructor. However, this feature is not working at the present time. Please workaround this problem by setting a breakpoint on the appropriate line number. // using %name you can set a break on a destructor DBG> set break stack::%name'~stack' // however setting a break on an operator is not working yet DBG> set break stack::%name'operator++'() %DEBUG-I-NOTUNQOVR, symbol 'stack::operator++' is overloaded overloaded name stack::operator++ instance stack::operator++(int) instance stack::operator++() %DEBUG-E-REENTER, reenter the command using a more precise pathname o Pointer to member 26 On OpenVMS I64 systems, the compiler is not yet emitting full debug information for pointers to members. o Limited support for namespaces On OpenVMS I64 systems, the compiler is not yet emitting full debug information for namespaces. o Unused type and unused labels On OpenVMS I64 systems, the /debug qualifier means /DEBUG=(TRACEBACK,BRIEF) which causes the compiler to omit debug information for unused labels and unused types, even when /NOOPTIMIZE is specified. This feature results in much smaller object files. If unused labels and unused types are desired, please specify the SYMBOLS keyword explicitly (/DEBUG=(SYMBOLS). o source line numbers and listing line numbers on OpenVMS Alpha systems, the debugger will display listing line numbers. However, the HP C++ V7.1 compiler on OpenVMS I64 systems does not yet support debugging with listing line numbers. Instead you will see source line numbers when in the debugger. For Example: in the following program which contains two include files, on OpenVMS Alpha the debugger displays the same listing line numbers as in the listing file. However on OpenVMS I64, the generic DWARF 3 filename and line number system is used in the debugger, while a listing file will contain standard VMS style listing line numbers. #include void t2(); int main() { /* comment lines within executable code visible*/ printf("in main\n"); t2(); } /* last line in routine main */ /* This comment will not be visible */ #include "t2.c" 27 Notice that when we are in the debugger, we see source line numbers, and the location information on a show calls displays module name, source line number. DBG> go break at routine GEM_BUGS10682\main 4: int main() { %DEBUG-I-DYNLNGSET, setting language C++ DBG> type 1:20 module GEM_BUGS10682 1: #include 2: 3: void t2(); 4: int main() { 5: /* comment lines within executable code visible*/ 6: printf("in main\n"); 7: t2(); 8: } /* last line in routine main */ 9: extern "C" {int printf(const char *,...);} 10: void t2() { 11: printf("in t2\n"); 12: } /* last line in routine t2 */ DBG> sho calls module name routine name line rel PC abs PC *GEM_BUGS10682 main 4 0000000000000000 0000000000010000 *GEM_BUGS10682 MAIN 00000000000000F0 0000000000010170 FFFFFFFF80B1CC20 FFFFFFFF80B1CC20 DBG> set break t2 DBG> go in main break at routine GEM_BUGS10682\t2 10: void t2() { DBG> sho calls module name routine name line rel PC abs PC *GEM_BUGS10682 t2 10 0000000000000000 00000000000101C0 *GEM_BUGS10682 main 7 0000000000000050 0000000000010050 *GEM_BUGS10682 MAIN 00000000000000F0 0000000000010170 Below you see the listing file and all of the source lines from the main source file are shown. (The contents of the include would be visible too if /LIS/SHOW=INCLUDE were specified.) 28 1 #include 1552 1553 void t2(); 1554 int main() { 1555 /* comment lines within executable code visible*/ 1556 printf("in main\n"); 1557 t2(); 1558 } /* last line in routine main */ 1559 /* This comment will not be visible */ 1560 1561 #include "t2.c" 1568 1569 o Breakpoints on for loops On OpenVMS Alpha systems, if you set a breakpoint on a for loop that resides on a single source line, the debugger triggers only once; the for loop is considered a single statement. On OpenVMS I64 systems, the same situation causes the debugger to trigger on each iteration of the for loop. Consider the following for statements: for (i=0; i<10; i++) y_v10_int[i] = x_v10_int[i]; for (i=0; i<10; i++) {y_v10_int[i] = x_v10_int[i];} for (i=0; i<10; i++) { y_v10_int[i] = x_v10_int[i]; } On OpenVMS Alpha systems, the debugger treats the first two example loops above as single statements, even with delimiting braces. But if the loop is spread over several source lines, as in the third example, the OpenVMS Alpha debugger treats it as a loop. On OpenVMS I64 systems, all three of the above for statements are treated as loops. 29 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. 30 3.2 Language Run-Time Support Library The following language run-time support library change has been made: o The language run-time support library no longer validates if a negative value has been specified in a call to operator new. Instead, the value is treated as an unsigned value, and an attempt is made to dynamically allocate the specified memory. 3.3 Class Library The following class library changes have been made: o The tasks and complex packages have been removed. The recommended replacements are the pthreads routines and complex template class, respectively, from the C++ standard library. o In the String class, the char*() operator, which converts String to a pointer to char, has been removed. The String class has a const char*() operator, which can be used instead of the removed one. 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: o The C++ standard library has been upgraded from Version 2.0 of the Rogue Wave C++ Standard Library to Version 3.0. o The C++ standard library is delivered with the operating system as the installed system shareable image SYS$SHARE:CXXL$RWRTL.EXE, and also in STARLET.OLB in the object form for linking /NOSYSSHARE. On I64 systems, there is no LIBCXXSTD.OLB, which is the object library where the C++ standard library for OpenVMS Alpha resides. 31 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 header necessary for the std::cout object: #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include 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. 32 3.4.3 Internal Library Headers and Macros A program that includes internal RW stdlib V2.0 library headers, like or , 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++ V7.1 for OpenVMS I64 Field Test release T8.2 and are expected to be resolved in the final release of OpenVMS V8.2: o Some locale facets like money_get<>, money_put<>, moneypunct<>, num_get<>, num_put<> and codecvt_byname<> may not work correctly. 3.4.5 Differences Between Alpha and I64 Systems The following are differences between the I64 and Alpha standard libraries: o On OpenVMS Alpha systems, the following constructors for the C++ standard library classes strstream and ostrstream initialize ptr[count-1] with a null byte: strstream(char *ptr, streamsize count, ios_base::openmode mode = ios_base::in | ios_base::out); ostrstream(char *ptr, streamsize count, ios_base::openmode mode = ios_base::out); This initialization is not required by the C++ standard, and on I64 systems the C++ standard library does not do it. o On I64 systems, map and multimap containers require the standard-conformant form of allocator class: allocator >. For example, on Alpha systems, it is possible to declare an object of class multimap as the following, with the second template argument of allocator class omitted: multimap, allocator > x; 33 But for I64 systems, this must be changed to: multimap, allocator > > x; o On I64 systems, the exception.what() function reports the module name, and the message text might be different. For example, an output on Alpha systems: Got an exception: string index out of range in function: basic_string:::replace(size_t,size_t,size_t,char) position: 100 is greater than length: 0 An output on I64 systems: Got an exception: CSRC:[STDIPF_INCLUDE]STRING.CC;:416: basic_string::replace(size_type, size_type, size_type, value_type): argument value 100 out of range [0, 0) o On I64 systems, iostreams extraction operators truncate out-of-range integer values to the maximum possible value for a given type, and set the failbit for the stream. For example, consider the following program: #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include #include using namespace std; main() { istrstream is("32768"); // SHRT_MAX is 32767 short s; is >> s; cout << is.fail() << endl; cout << s << endl; } On Alpha systems, this program gives: 0 -32768 34 On I64 systems, it gives: 1 32767 Note that on I64 systems, the failbit for the stream is set. According to the C++ Standard, Section 22.2.2.1 - Template class num_get [lib.locale.num.get], an input that would have caused scanf to report an input failure should result in setting ios_base::failbit to err. Since on OpenVMS, scanf reports an input failure in this case (this is an undefined behavior from the point of view of the C standard), the behavior of the C++ standard library on I64 systems is standard-compliant. o On Alpha systems, the find template function is implemented using operator!=. On I64 systems, this function is implemented using operator==, which according to the C++ standard is the operator the find function should be using. Consequently, if no conversion from *InputIterator to T exists, on Alpha systems the following function can be instantiated only if operator!=(*InputIterator,T) exists: find(InputIterator first, InputIterator last, const T& value) On I64 systems, however, the function can be instanti- ated only if operator==(*InputIterator,T) exists. The following program illustrates the difference. If you comment out the line bool operator!=(S, int);, the program does not compile on Alpha systems. If you comment out the line bool operator==(S, int);, the program does not compile on I64 systems. The behavior on I64 systems is the standard-conformant behavior. include #include struct S { int i; }; bool operator!=(S, int); bool operator==(S, int); 35 void foo() { std::vector v; std::find(v.begin(), v.end(), 0); } o On I64 systems, an attempt to write into a stream opened for read (ios::in), causes the stream badbit bit to be set. On both Alpha and IPF systems, nothing is written into a stream opened for read. However, on Alpha systems, the stream badbit bit is not set. The C++ standard does not provide explicit guidance about what to do in this case. However, the behavior on I64 systems is more reasonable-at least there is an indication that something was wrong. o On I64 systems, reverse_iterator cannot be instantiated on vector::iterator type. For example, the following program, which compiles cleanly on Alpha systems, does not compile on I64 systems: #include typedef std::reverse_iterator::iterator> ri; main() { ri::pointer (ri::*foo)() const = &ri::operator->; } A recently adopted resolution for the library issue 120 has made this construct invalid. See http://std.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#120 for more details. o On I64 systems, for a random access iterator, operator- (const random_access_iterator&) returning difference_ type must be const. For example, the following program compiles cleanly on Alpha systems. However, on I64 systems it compiles only if // const is uncommented. 36 #include template class randomaccessiterator { public: typedef T value_type; typedef int difference_type; typedef T* pointer; typedef T& reference; typedef std::random_access_iterator_tag iterator_category; bool operator==(const randomaccessiterator&); bool operator!=(const randomaccessiterator&); T& operator*() const; T* operator->(); randomaccessiterator& operator++(); const randomaccessiterator& operator++(difference_type); randomaccessiterator& operator--(); const randomaccessiterator& operator--(difference_type); randomaccessiterator& operator+=(difference_type); randomaccessiterator& operator+(difference_type); randomaccessiterator& operator-=(difference_type); randomaccessiterator& operator-(difference_type); difference_type operator-(const randomaccessiterator&); // const; }; struct S {}; typedef randomaccessiterator Iterator; typedef bool (*Predicate)(Iterator::value_type); template Iterator std::stable_partition(Iterator, Iterator, Predicate); Table 76 in the C++ standard specifies the requirements for a random access iterator. It says the expression b - a must be valid, where a and b denote values of X, the random access iterator. It is not completely clear from the standard whether values of X also imply const values of X, but if the answer is yes, the behavior on I64 systems is correct. o On I64 systems, an attempt to call the strstream.seekg(0) function for an empty stream (the one whose 'next' pointer is NULL) causes the stream failbit to be set. 37 This is a standard-compliant behavior. Notice that after the failbit is set for the stream, the strstream.str() function returns a NULL pointer. o On I64 systems, after a call to string.resize(newsize), string.capacity() does not necessarily returns newsize. While on Alpha systems the string.capacity() function returns newsize, this is not required by the C++ standard. A program relying on Alpha behavior should be modified to call the string.size() function instead. o On I64 systems, there is no overload of basic_string class for type bool. Version v3.0 of the Rogue Wave C++ standard library does not have this problematic nonstandard overload. For OpenVMS Alpha, it has been recently removed from the library. o On I64 systems, class std::fpos does not have the nonstandard member function offset(). You can use fpos::operator streamoff() instead. For example: #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include using namespace std; void foo() { istringstream in("hello, world"); streamoff offset; offset = in.tellg().offset(); // Alpha only offset = streamoff(in.tellg()); // either Alpha or IPF } 38 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: o There is no LIBCXXSTD.OLB On I64 systems, there is no LIBCXXSTD.OLB, which is the object library where the C++ standard library for OpenVMS Alpha resides. See Section 3.4 for more information. o The library is reorganized The C++ libraries have been reorganized and incorpo- rated into the base system. CXXLINK no longer needs to specify any C++ libraries when invoking the system linker. See Section 3 for more information. o There are no templates in a repository With the new template instantiation model, objects are no longer placed in a repository. Therefore, CXXLINK no longer needs to look at the repositories for templates. See Section 2.2.10 for more information. 5 Installation To install HP C++ V7.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 39 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% 40 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. 41