HP_C++_Version_7.1-015________________________ Release Notes for OpenVMS Alpha October 5, 2005 This document contains information about new and changed features in this version of HP C++ for OpenVMS Alpha. Hewlett-Packard Company Palo Alto, California __________________________________________________________ © Copyright 2005 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. 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-2005 Rogue Wave Software, Inc. This document was prepared using DECdocument, Version 3.3-1n. ________________________________________________________________ Contents 1 Introduction................................. 1 2 Important Compatibility Information.......... 1 2.1 Standard Library Differences............. 2 2.2 Compiler Differences..................... 2 2.3 Differences Between HP C++ and the C++ International Standard................... 4 2.4 Retirement of CFRONT Language Dialect.... 4 3 New Debugger................................. 4 4 C++ Standard Library......................... 6 5 Release Notes for the V7.1 C++ Compiler...... 7 5.1 Enhancements, Changes, and Problems Corrected in Version 7.1................. 7 5.2 Restrictions in Version 7.1.............. 12 6 Release Notes for the V7.1 C++ Standard Library...................................... 14 6.1 Enhancements, Changes, and Problems Corrected in Version 7.1................. 14 6.2 The C++ Standard Library in the Form of a Shareable Image.......................... 25 6.2.1 How To Create Shareable Images......... 25 6.2.2 Linking Against the C++ Standard Library Shareable Image................ 26 6.2.2.1 Linking Without the C++ Standard Library Image in IMAGELIB.OLB......... 26 6.2.2.2 Linking With the C++ Standard Library Image in IMAGELIB.OLB................. 26 6.2.3 Restrictions........................... 28 6.2.3.1 Overriding Global Operators new and delete................................ 28 6.2.3.2 Mixing OLB and Shared C++ Library in the Same Process...................... 28 iii 6.3 Restrictions............................. 28 6.3.1 Using the C++ Libraries in Microsoft Standard Mode.......................... 28 7 Release Notes for the V6.5 C++ Compiler...... 29 7.1 Enhancements, Changes, and Problems Corrected in 6.6-???..................... 29 7.2 Enhancements, Changes, and Problems Corrected in 6.5-042..................... 35 7.3 Enhancements, Changes, and Problems Corrected in V6.5-041.................... 35 7.4 Enhancements, Changes, and Problems Corrected in V6.5-040.................... 35 7.5 Enhancements, Changes, and Problems Corrected in V6.5-039.................... 35 7.6 Enhancements, Changes, and Problems Corrected in V6.5-038.................... 35 7.7 Enhancements, Changes, and Problems Corrected in V6.5-036.................... 36 7.8 Enhancements, Changes, and Problems Corrected in V6.5-035.................... 36 7.9 Enhancements, Changes, and Problems Corrected in V6.5-034.................... 36 7.10 Enhancements, Changes, and Problems Corrected in V6.5-033.................... 37 7.11 Enhancements, Changes, and Problems Corrected in V6.5-032.................... 37 7.12 Enhancements, Changes, and Problems Corrected in V6.5-031.................... 37 7.13 Enhancements, Changes, and Problems Corrected in V6.5-030.................... 38 7.14 Enhancements, Changes, and Problems Corrected in V6.5-029.................... 38 7.15 Enhancements, Changes, and Problems Corrected in V6.5-028.................... 38 7.16 Enhancements, Changes, and Problems Corrected in V6.5-026.................... 38 7.17 Enhancements, Changes, and Problems Corrected in V6.5-024.................... 39 7.18 Enhancements, Changes, and Problems Corrected in V6.5-021.................... 39 7.19 Enhancements, Changes, and Problems Corrected in V6.5-020.................... 39 iv 7.20 Enhancements, Changes, and Problems Corrected in Version 6.5................. 40 7.21 Restrictions and Known Problems in Version 6.5.............................. 40 8 Release Notes for the V6.3 C++ Compiler...... 42 8.1 Enhancements, Changes, and Problems Corrected in Version 6.3................. 42 8.2 Restrictions and Known Problems in Version 6.3.............................. 51 9 Release Notes for the V6.2 C++ Compiler...... 51 9.1 Enhancements, Changes, and Problems Corrected in Version 6.2A................ 51 9.2 Enhancements and Changes in Version 6.2...................................... 53 9.3 Restrictions in Version 6.2.............. 63 10 Release Notes for the V6.0 C++ Compiler...... 75 10.1 Enhancements, Changes, and Restrictions in Version 6.0........................... 75 v 1 Introduction This document contains the release notes for HP C++ Version 7.1-015 for OpenVMS Alpha. The HP C++ product requires OpenVMS Alpha Version 7.3-2 or higher. The HP C++ media contains the following: o The Version 7.1-015 kit, which includes the HP C++ compiler and associated files, such as the Class Library and Standard Library header files. o The ADX072 kit, which contains an enhanced OpenVMS Debugger that provides better debugging of applications built with the HP C++ compiler. HTML files are provided for the release notes and some of the product manuals for use with a web browser. To view this documentation, point your browser to file:/sys$common/syshlp/cxx$help/index.htm 2 Important Compatibility Information HP strives to maintain a high degree of compatibility between successive versions of the compiler and its run- time environment. Because, however, each new version includes enhancements and changes, you should be aware of the following whenever you upgrade: o Differences between Standard Library versions o Differences between compiler versions o Differences between HP C++ and the C++ International Standard o Retirement of cfront language dialect The next sections discuss these differences. 1 2.1 Standard Library Differences Any code that references the C++ Standard Library (any of the STL containers or algorithms, standard iostreams or locales) that was compiled using version V6.2 or earlier of the HP C++ compiler must be recompiled and relinked in order to be used with the code compiled with HP C++ Version 6.3 or later. For example, if you have an object library, an object module, or a shareable image compiled with HP C++ Version 6.2, you must to recompile it (and relink in the case of a shareable image) before an application compiled with Version 6.3 or later can use it. As stated earlier, this restriction applies only to code that references the C++ Standard Library; it does not apply to code that references the pre-standard Class Library, because the stability of that library's interface guarantees link compatibility in future releases. Beginning with HP C++ Version 6.3, the Standard Library is guaranteed to be link-compatible in all subsequent releases. For applications that will relink on the end-user's system, see Deploying Your Application in HP C++ User's Guide for OpenVMS Systems for information about redistributing C++ Run-Time Library components. 2.2 Compiler Differences Starting with Version 6.0, the HP C++ compiler differs significantly from previous versions. There are several major differences that you should be aware of before using a Version 6.n or higher compiler for the first time. These differences are summarized here. For more detailed information, see Appendix E Compiler Compatibility in HP C++ User's Guide for OpenVMS Systems. o Language differences The compiler implements (with some differences, as described in Section 2.3), the C++ International Standard, which differs significantly from the language specified in the ARM (The Annotated C++ Reference Manual, 1991, by Ellis and Stroustrup) and implemented 2 by the Version 5.n compilers. When switching from a Version 5.n compiler, you might need to modify your source files, especially if you use the default language mode. In addition, language changes can affect the run-time behavior of your programs. If you want to compile existing source code with minimal source changes, compile using the /standard=arm option. See Appendix E Compiler Compatibility in HP C++ User's Guide for OpenVMS Systems. ________________________Note ________________________ The installation procedure checks whether a Version 5.3 to 5.6 compiler is installed on your system. If so, it asks whether you want to save it, and if so, where. The default save area for a Version 5.6 compiler is SYS$COMMON:[CXX056]. If you find that Version 6.n or higher requires excessive changes to your applications even when you use the /standard=arm option, or if you encounter problems using the Version 6.n or higher compiler, you can return to your previous C++ environment by invoking the command procedure SYS$COMMON:[CXX0nn]COMPILER_SETUP.COM where nn specifies the version of your previous compiler. _____________________________________________________ o Diagnostic differences The Version 6.n or higher compiler does more error checking than Version 5.6 and generates more diag- nostics. If you want the number of diagnostics issued by the Version 6.n or higher compiler to be similar to Version 5.6, compile with the /quiet option. See Message Control and Information Options in HP C++ User's Guide for OpenVMS Systems. o Implementation differences 3 The automatic template instantiation model has been redesigned for the current version. Although code compiled with a Version 5.n compiler and a Version 6.n or higher compiler can be combined, you must complete the Version V5.n instantiation process with a V5.n compiler before linking to code compiled with Version 6.n or higher. See the Using Templates section in the Compiler Compatibility Appendix of the HP C++ User's Guide for OpenVMS Systems. 2.3 Differences Between HP C++ and the C++ International Standard The following items, specified in the C++ International Standard, are not supported in Version 7.1-015 but may be supported in a future version. Details about each item are provided in the indicated sections of the C++ International Standard document and The C++ Programming Language, 3rd Edition by Bjarne Stroustrup. o The export keyword for templates (Standard §14, paragraph 6; Stroustrup §9.2.3) 2.4 Retirement of CFRONT Language Dialect The CFRONT dialect was provided for migrating code from the CFRONT compilers to the HP C++ compiler. Because it has been over five years since the last CFRONT compiler was released, we are retiring this dialect. It is removed from Version 7.1 of the compiler. 3 New Debugger A new OpenVMS Debugger (kit ADX072, dated 4-Mar-1999) is provided with this kit and must be installed to debug programs compiled with the compiler in this release. This debugger solves several problems with the previous debugger. ________________________Note ________________________ The version of the OpenVMS Alpha operating system running on your computer determines how the ADX072 kit links debugger images when you run VMSINSTAL. When linked with Version 6.n, the ADX072 debugger does not work correctly on Version 7.n systems. 4 For example, if you install ADX072 on a Version 6.2 system, and if you later upgrade that system to Version 7.2, the ADX072 debugger does not work correctly until you reinstall ADX072. OpenVMS Alpha releases after Version 6.2 include a debugger that supports the new C++ capabilities. If you are running OpenVMS Alpha Version 6.2 or later, consult the OpenVMS New Features Manual to determine whether you must install the debugger shipped with HP C++. _____________________________________________________ To install the special C++ debugger, invoke VMSINSTAL: @SYS$UPDATE:VMSINSTAL ADX072 device-name option-list See the HP C++ Installation Guide for OpenVMS Alpha for additional information. The C++ debugger GUI image is not installed automatically on OpenVMS systems that are not running DECwindows Motif or that run a version earlier than 1.2-4. If you decide to install Motif or upgrade to Version 1.2-4 or later, and if you then want to use the debugger GUI, you must perform these tasks: 1. Reinstall the ADX072 kit to create the debugger's GUI image 2. Execute a command procedure to install the debugger images and define the default system debugger Follow these steps: If you want the special C++ debugger to be the default debugger for the system: 1. Invoke the command procedure as follows: @SYS$STARTUP:DEBUG$STARTUP_V72X.COM V72X 2. Add this line to the system startup procedure: $ @SYS$STARTUP:DEBUG$STARTUP_V72X.COM V72X 5 3. On OpenVMS systems prior to Version 6.2A, copy the resource file: $ COPY DECW$SYSTEM_DEFAULTS:CXXVMSDEBUG.DAT - DECW$SYSTEM_DEFAULTS:VMSDEBUG.DAT Note that C++ Version 6.n and higher does not run on any OpenVMS versions prior to Version 6.2. If you do not want the special C++ debugger to be the default debugger for the system: 1. Invoke the command procedure as follows: @SYS$STARTUP:DEBUG$STARTUP_V72X.COM VMS 2. Add this line to the system startup procedure: $ @SYS$STARTUP:DEBUG$STARTUP_V72X.COM VMS 4 C++ Standard Library This Standard Library string class, known as the String Library, is not the same as the String Package, which is part of the Class Library implemented in earlier versions of HP C++. For information about the HP C++ Class Library, See Appendix D in in HP C++ User's Guide for OpenVMS Systems. Thread Safety The Standard Library provided with this release is thread safe but not thread reentrant. Thread safe means that all library internal and global data is protected from simultaneous access by multiple threads. In this way, internal buffers as well as global data like cin and cout are protected during each individual library operation. Users, however, are responsible for protecting their own objects. According to the C++ standard, results of recursive initialization are undefined. To guarantee thread safety, the compiler inserts code to implement a spinlock if another thread is initializing local static data. If recursive initialization occurs, the code deadlocks even if threads are not used. 6 5 Release Notes for the V7.1 C++ Compiler The following sections describe enhancements, changes, and restrictions for the C++ compiler environment. 5.1 Enhancements, Changes, and Problems Corrected in Version 7.1 o The /TEMPLATE_DEFINE qualifier now requires an option. o The compiler issues a CC-W-NOTINCRTL message when it prefixes a name not in the current C RTL. /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 #pragma module module-name [module-ident | "module- ident"] If the module-name is too long: o A warning is generated if /NAMES=TRUNCATED is specified. o There is no warning if /NAMES=SHORTEN is specified. A shortened external name incorporates all the characters in the original name. If two external names differ by as little as one character, their shortened external names will be different. If the optional module-ident or "module-ident" is too long, a warning is generated. The default module-name is the filename of the first source file. The default module-ident is "V1.0" They are treated as if they were specified by a #pragma module directive. If the module-name is longer than 31 characters and: 7 o /NAMES=TRUNCATE is specified, truncate the module- name to 31 characters, or less if the 31st character is within a Universal Character Name. o /NAMES=SHORTENED is specified, shorten the module- name to 31 characters using the same special encoding as other external names. Lowercase characters in the module-name are converted to uppercase only if /NAMES=UPPERCASE is specified. A module-ident that is longer than 31 characters is treated as if /NAMES=(TRUNCATED,AS_IS) were applied, truncating it to 31 characters, or less if the 31st character is within a Universal Character Name. The default module-name comes from the source file name which always appears in the listing header. The module- name (and ident) appear in the listing header only if they come from a #pragma module directive or differ from the default. o Certain OpenVMS conditions normally result in the delivery of signals that can be processed using a C-style signal-handler mechanism. The C++ condition-handling facility has been changed to invoke this C-style signal-handling mechanism only if a signal handler has been established. Before this change, unhandled signals would result in program termination. In addition, the following C signals are now recognized: SIGCHLD, SIGPIPE, SIGWINCH, and SIGSEGV. This now makes C++ for OpenVMS Alpha functionally equivalent to C++ for I64 systems. o Specifying a C++ headers library and a C headers library using "+" and the /LIB qualifier on the cxx command line, as in the following example, can cause the compiler to fetch a C header file from the C headers library instead of a template-definition file from the C++ headers library: cxx x.cxx+SYS$LIBRARY:CXXL$ANSI_DEF.TLB/LIB+SYS$LIBRARY:DECC$RTLDEF.TLB/LIB 8 This can happen if a C header file has the same filename as the C++ template-definition file: for example, the string.h header file in the C headers library and string.cc template-definition file in the C++ headers library. o The compiler was not correctly handling break statements out of loops which follow an identifier label within switch statements. This is now fixed. o A bug in the C++ compiler in the /STANDARD=STRICT mode of compilation, used to produce an error diagnostic when compiling code that used setjmp or c$$establish. This has been fixed. o In the /STANDARD=STRICT mode of compilation, the compiler used to issue a diagnostic with the severity of Error, for NULL reference expression within a sizeof expression. The severity of the diagnostic is now an informational. o Previously, the propagation of a C++ exception out of a thread's start routine did not result in cxxl$terminate() being called. A partial solution for the problem (a back-port of the solution on OpenVMS I64) is now available on OpenVMS Alpha Version 7.3-2 and higher. For the new behavior, you must link against the shareable image of the C++ Standard Library, available with Version 7.1 and higher of the C++ Compiler for OpenVMS Alpha (see Section 6.2), and must define the logical CXXL$LANGRTL to point to the appropriate shareable version of the C++ Standard Library. For example: $ define cxxl$langrtl libcxxstd $ cxx test $ cxxl test $ run test Work thread starting. Custom terminate function called. 9 Work thread starting. Custom terminate function called. %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC ... $ type test.cxx // Begin test.cxx #include // EXIT_SUCCESS #include #include // cout #include // set_terminate #include // std::bad_alloc void terminator() { cout << "Custom terminate function called." << endl; abort(); } void* work(void* param) { cout << "Work thread starting." << endl; set_terminate(terminator); throw std::bad_alloc(); return 0; } int main (int argc, const char ** argv) { set_terminate(terminator); pthread_t t; pthread_create(&t, NULL, &work, NULL); pthread_detach(t); sleep(2); throw std::bad_alloc(); return EXIT_SUCCESS; } // End test.cxx o __MEMxxx builtin functions treated length as signed. The builtin functions __MEMMOVE, __MEMCPY, and __MEMSET were erroneously generating code to sign- extend the length parameter before passing it to an OTS$ routine that interprets the length as a signed 64-bit value. The length parameter for the standard C library routines is of type size_t, which is unsigned 10 int on OpenVMS. But the sign extension done by these builtins made a length greater than or equal to 2147483648 be seen as negative by the underlying OTS$ routines, and those routines treat a negative length as a no-op. Although lengths so large are unusual, they are possible and need to be supported. It is possible that some source code exists that actually computes negative length values, and relies on these values being treated as no-ops. That behavior is not supported by the standard, although it is a convention used in similar VMS library routines. With this bug fixed, such code will most likely ACCVIO at run-time. Such code needs to be changed to test the length value explicitly to determine if it is in a range that should be ignored, and either bypass the call or use a length of zero - that is the only way to assure correct operation. Note that the header may (under __NONAMESPACE_ STD) define macros to replace invocations of the standard C functions memmove, memcpy, and memset by invocations of these builtins. And these functions are also recognized as intrinsics, so even without the macros the compiler will treat them as builtin functions. Therefore, just recompiling a module will introduce the effect of this fix, even if linking against the same version of the CRTL. The only reliable way to ensure that a negative length value will be treated as a no-op instead of a large positive value when using these standard C functions is to modify the source to test the value explicitly - that's what the standard-conforming behavior requires. Finally, note that this bug is not present in either the builtin or CRTL implementions of these functions on OpenVMS I64, so this fix makes the Alpha behavior match the I64 behavior. 11 o Previously, the compiler was incorrectly deducing the template argument type as a const-qualifed (or volatile-qualified) type, instead of as an unqualified type, when deducing from a const- (or volatile- )qualified array type. template void foo(const T &value) { } void f(void) { const int i[3] = { 1, 2, 3 }; foo(i); } The compiler previously deduced T to be of type "const int[3]" while it now deduces it to be of type "int [3]". This affects -model ansi compilations only, since -model arm compilations do not mangle in the template argument type. o A problem has been corrected in the implicit include processing. The implicit inclusion will no longer select files such as ".C" or ".CXX" (where these files have no file name portion). 5.2 Restrictions in Version 7.1 o Debug is not able to break on a non-local constructor in a shareable image because of the order in which images start up on OpenVMS. Specifically, the debugger is loaded and begins to run only after the initialization of all the shareable images but before the initialization of the main image. For example, in the following program where the constructor foo::foo() has been built into a shareable image, the constructor runs before the debugger has been activated. As a result, there is no way to break on this constructor, even if you attempt to signal the debugger. $ cxx/debug/noopt static_ctor_main.cxx $ cxx/debug/noopt static_ctor.cxx $ cxx_link/share/debug static_ctor/opt $ cxx_link/debug static_ctor_main/opt $ define STATIC_CTOR DISK$:[DIR]STATIC_CTOR.exe $ run static_ctor_main foo::foo() <----- ctor has already been executed 12 OpenVMS Debug Version VX.X-xxx %DEBUG-I-INITIAL, Language: C++, Module: STATIC_CTOR_MAIN %DEBUG-I-NOTATMAIN, Type GO to reach MAIN program --------- static_ctor_main.cxx ----------- main() { } ---------- static_ctor.cxx ------------- extern "C" int printf(const char *,...); #define SS$_DEBUG 1132 extern "C" int lib$signal(unsigned int cond); class foo { public: foo() { printf("foo::foo()\n"); #if SIG lib$signal(SS$_DEBUG); #endif } ~foo() { } }; foo x; -------- static_ctor_main.opt---------- NAME = main IDENTIFICATION = "V1.001" GSMATCH = LEQUAL, 1, 001 static_ctor_main.obj static_ctor/share -------- static_ctor.opt ------------ NAME = static_ctor IDENTIFICATION = "V1.001" GSMATCH = LEQUAL, 1, 001 static_ctor.obj o The C++ compiler incorrectly mangles top-level cv- qualifiers into function signatures in the default object model (/MODEL=ARM on OpenVMS, -model arm on Tru64 UNIX). For example: 13 file.cxx ----- void f(const int); void f(int) {} > cxx/noobj file.cxx void f(int) {} .....^ %CXX-W-NOTQUACOMPREDEC, declaration is not qualifier compatible with "void f(const int)" (declared at line 1) at line number 2 in file DEVICE$:[DISK]FILE.CXX;15 > cxx/noobj/model=ansi file.cxx > o The compiler might generate a bogus CXX-W-MAYLOSEDATA diagnostic when in the strict ANSI compilation mode and when using the model ansi object model when handling expressions from class templates that involve (pointer to) member functions or data members that are pointers in a non-template indirect base class. 6 Release Notes for the V7.1 C++ Standard Library The following sections describe enhancements, changes, and restrictions for the C++ Standard Library. 6.1 Enhancements, Changes, and Problems Corrected in Version 7.1 o This version of the C++ compiler implements C++ headers for C Library Facilities. The headers avoid pollution of the global namespace by defining all C names only in namespace std. (See Stroustrup, §9.2.2 and §16.1.2.) The headers are located in the same text library as the C++ Standard Library headers and template definition files: SYS$LIBRARY:CXXL$ANSI_ DEF.TLB. If you include a header and use the /PURE_CNAME option, all C functions and types found in that header file are declared only in namespace std, as specifed by the C++ International Standard. 14 Specifying the /NOPURE_CNAME option causes headers to be handled as if the corresponding version had been included. That is, names are available both in namespace std and global scope. Otherwise, the default is /PURE_CNAME when compiling with /STANDARD=STRICT_ANSI and /NOPURE_CNAME. Including after including the corresponding header brings all names declared in that header into global namespace with using std::name declarations. New overloaded function signatures have been added to several headers (see Standard §21.4, 25.4, and 26.5). These overloaded signatures have been made available when including the header in PURE_ CNAME mode. If the __CNAME_OVERLOADS macro is defined, the new signatures are available in both PURE_CNAME and NOPURE_CNAME modes. Defining the __CNAME_OVERLOADS macro in NOPURE_CNAME mode in combination with other macros and options (for example, /STANDARD=MS, /DEFINE=_XOPEN_SOURCE) can cause compile errors. cmath (Standard §26.5) now provides float and long double overloaded signatures for math functions in PURE_CNAME mode, or in NOPURE_CNAME mode with the __CNAME_OVERLOADS macro defined. These added signatures could cause type ambiguity problems or different runtime behavior in existing code. Consider these examples: o sin(1) is now ambiguous because overloads are provided for float, double, and long double. A user sees the following differences, because the argument of sin(1) is assumed to be of type int: cout << "sin(1) = " << sin(1) << endl; // generates an error: %CXX-E-AMBOVLFUN, more than one instance of overloaded function "std::sin" matches the argument list: function "std::sin(double) C" function "std::sin(float)" function "std::sin(long double)" argument types are: (int) 15 o The type of the argument to an overloaded math function determines the type of its return value and associated precision. Calls to math functions using float or long double arguments may return less precise or more precise values than previously. Compare the following: - Previous compiler release: long double ldout = sin(1.0); ldout = 0.84147098480789650000 - Current compiler release: long double ldout = sin(1); // type int argument - ambiguous long double ldout = sin(1.0l); // type long double argument ldout = 0.84147098480789650000 long double ldout = sin(1.0f); // type float argument ldout = 0.84147095680236816000 Signatures have been added in the cstring, cwchar, and cstdlib header files for the following functions: o cstring: (Standard §21.4) strchr, strpbrk, strrchr, strstr, memchr o cwchar: (Standard §21.4) wcschr, wcspbrk, wcsrchr, wcsstr, wmemchr o cstdlib: (Standard §25.4) bsearch, qsort, (§26.5) abs, div The added signatures could cause problems in exist- ing code. For example, because char* strchr(const char*, int) now has overloads const char* strchr(const char*, int) and char* strchr(char*, int), the following code does not work: #include void f(char*) {;} int main() { f(strchr("abc",1)); // strchr returns a const char* return 0; } 16 o A problem with vector container created by a construc- tor accepting two input iterators has been corrected. After the fix, the constructor populates the container with all the contents of the stream associated with the iterator, as it should. Before the fix, the constructor would put only the first stream record into the container. A program like the program example in Section 3.8.3 "Iterators and I/O" in Stroustrup's C++ Programming Language, 3rd edition, now generates the correct result. o A bug in codecvt::encoding() specialization of the codecvt::encoding() member function has been fixed. The function used to return 0 regardless of the encoding established by the facet while, according to section 22.2.1.5.2, p7 of the C++ standard, it should return -1 if the encoding is state- dependent, a constant number of characters needed to produce a wide character (as for a single-byte character set), and 0 otherwise (as for a multibyte character set). For example, after the fix, the program below generates the following output: 1 1 0 Before the fix, it would generate the following output: x.cxx ----- #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include #include using namespace std; int main() { codecvt_byname* p; 17 // C locale p = new codecvt_byname(""); cout << p->encoding() << endl; // single-byte locale p = new codecvt_byname("en_US.ISO8859-1"); cout << p->encoding() << endl; // multibyte locale p = new codecvt_byname("ja_JP.SJIS"); cout << p->encoding() << endl; } o codecvt::max_length() specialization of the codecvt::max_length() member function has been modified to return MB_CUR_MAX for the encoding established by the facet instead of MB_ LEN_MAX. While not a bug, MB_CUR_MAX is a more accurate return value for the max_length() function, and this is what the function returns in other implementations of the C++ Standard Library, including recent versions of Rogue Wave library. o To synchronize access to the reference count in the reference counting implementation of std::string class, the C++ Standard Library uses atomic instructions. Version 7.1 of the compiler introduces an alternate synchronization mechanism based on the pthread mutex embedded in _RWstring_ref_rep class and using the TIS interface. A mutex-based synchronization can provide better performance in configurations with slow memory access, especially, when an application is not threaded and TIS mutex blocking becomes a no-op. Also, a mutex-based synchronization is more robust in some situations. For example, when an application fails to provide proper high-level synchronization when operating on objects of std::string class in different threads, a mutex- based synchronization might allow the application to "survive". However, HP does not recommend relying on this feature. 18 To enable mutex-based synchronization in std::string class, a program should be compiled with the __USE_ EMBEDDED_PTHREAD_MUTEX macro defined. Additionally, a program should be using a nopreinstantiation version of the C++ Standard Library, which assumes compiling with the __FORCE_INSTANTIATIONS macro defined and linking /NOPREINST. Objects generated by compiling with the __USE_ EMBEDDED_PTHREAD_MUTEX macro defined are not binary- compatible with objects generated by compiling without the macro defined, and should not be linked in the same application. This is also true for dynamically loaded C++ libraries. That is, with respect to the __USE_ EMBEDDED_PTHREAD_MUTEX macro, all dynamically loaded libraries and the main executable should be compiled the same way. A vendor whose library is built with the macro defined should notify their users to also compile with the macro defined (and use nopreinstantiation C++ Standard Library). o A bug in codecvt::encoding() specialization of the codecvt::encoding() member function has been fixed. The function used to return -1 while, according to section 22.2.1.5.2, p7 of the C++ standard, it should return 1. The fix makes sure that the specialized function returns 1. o A bug in codecvt::in(), out(), and unshift() specialization of the codecvt member functions has been fixed. These functions used to return codecvt_base::error while, according to section 22.2.1.5.2 of the C++ standard, they should return codecvt_base::noconv. The fix makes sure that the specialized functions return codecvt_base::noconv. o The codecvt::always_noconv() function has been modified to return true to comply with section 22.2.1.5.2, p8 of the C++ standard. In previous complier releases, this function used to return false. o To be consistent with Library Issue 103, the reverse_ iterator typedef in set and multiset has been changed to _RWrep_type::const_reverse_iterator. 19 o Because of a bug in the C++ standard library, it was impossible to define and use a user-defined facet. For example, the following program would not compile. This has been fixed. #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include struct foo : std::locale::facet { static std::locale::id id; }; std::locale::id foo::id; int main() { std::use_facet(std::locale()); return 0; } o A problem with formatting a hexadecimal number using the ios_base::internal adjustfield manipulator has been corrected. For example, after the fix, the program below outputs the correct string: "0x0021". Before the fix, it would output: "000x21". #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include #include int main() { std::cout << std::hex << std::showbase << std::setfill('0') << std::setw(6) << std::internal << 33 << '\n'; } o The library previously used the same storage for iarray (an array of long integers) and parray (an array of pointers to void), manipulated by the iword() and pword() member functions, respectively, of class std::ios_base. This has been corrected so that iarray 20 and parray now use separate storage. For example, after the fix, the following program outputs the correct result: #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include int main() { int const index = std::ios_base::xalloc(); std::cout.iword(index) = 42L; std::cout << "iword=" << std::cout.iword(index) << std::endl; std::cout.pword(index) = 0; std::cout << "iword=" << std::cout.iword(index) << std::endl; } Correct result: iword=42 iword=42 Before the fix, it would output: iword=42 iword=0 o To comply with 21.2 - String classes [lib.string.classes] - in the C++ standard, declarations of the std::getline() function operating on basic_istream have been moved from to . Accordingly, the definition of the std::getline() function operating on basic_ istream and accepting the delim parameter has been moved from to . This change is visible only when using the standard iostreams. o A problem has been corrected with the assignment operator of the tree container not storing the comparison object of the container being copied into the target container. The tree container is the underlying container for the map and set STL containers. Because of this problem, after assigning one STL container object to another, the target container would continue to use the comparison object it was using before the assignment. 21 It violates section 23.1.2 - Associative containers [lib.associative.reqmts] of the C++ standard which states: When an associative container is constructed by passing a comparison object the container shall not store a pointer or reference to the passed object, even if that object is passed by reference. When an associative container is copied, either through a copy constructor or an assignment operator, the target container shall then use the comparison object from the container being copied, as if that comparison object had been passed to the target container in its constructor. o The HP C++ library defines std::ostream_iterator as the following: template > class _RWSTDExportTemplate ostream_iterator : public iterator However, section 24.5.2 - Template class ostream_ iterator [lib.ostream.iterator] of the C++ standard defines std::ostream_iterator as the following: template > class ostream_iterator: public iterator HP C++ Version 7.1 introduces the macro __COMPLY_WITH_ 24_5_2. When compiled with this macro defined, the library provides the standard-compliant definition of std::ostream_iterator. Note that defining the __COMPLY_WITH_24_5_2 macro changes the types defined by std::ostream_iterator, namely: value_type, difference_type, pointer, and reference. Because of changing types, it is a good idea to make sure that if the macro is defined, it is defined consistently in your application and in the libraries the application is using. 22 For example, consider the following program: x.cxx ----- #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include #include #include using namespace std; int main() { cout << typeid(ostream_iterator::value_type).name() << endl; cout << typeid(ostream_iterator::difference_type).name() << endl; cout << typeid(ostream_iterator::pointer).name() << endl; cout << typeid(ostream_iterator::reference).name() << endl; } When compiled without the __COMPLY_WITH_24_5_2 macro defined, x.cxx gives: char long char * char When compiled with the __COMPLY_WITH_24_5_2 macro defined, it gives: void void void void o The default constructor of class template std::istream_ iterator used to initialize stream data members with the address of std::cin regardless of the charT template argument. As a result, this class template could not be instantiated on charT template arguments other than 'char'. For example, compilation of the following program would result in a BADINITTYP error. This has been corrected. 23 #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include #include std::istream_iterator x; o The min() and max() functions in the specialization of the std::numeric_limits class template used to return the wrong values. Specifically, they returned the same (32-bit) values that the min() and max() functions in the specialization are returning. This has been corrected. Consider the following sample program x.cxx: x.cxx ----- #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include #include using namespace std; main() { cout << "max() = " << numeric_limits::max() << endl; cout << "min() = " << numeric_limits::min() << endl; cout << "max() = " << numeric_limits::max() << endl; } Without the fix, x.cxx gives: max() = 2147483647 min() = -2147483648 max() = 4294967295 After the fix, it gives: max() = 9223372036854775807 min() = -9223372036854775808 max() = 18446744073709551615 24 6.2 The C++ Standard Library in the Form of a Shareable Image Starting with C++ Version 7.1, the compiler kit provides linker options files and a CXXL$BUILD_SHARED_LIBCXXSTD_ IMAGES.COM DCL procedure for building the following shareable images: o LIBCXXSTD.EXE - model ARM preinstantiation library o LIBCXXSTD_NOINST.EXE - model ARM noinstantiation library o LIBCXXSTD_MA.EXE - model ANSI preinstantiation library o LIBCXXSTD_MA_NOINST.EXE - model ANSI noinstantiation library Notice that the filenames of the shareable images are the same as the filenames of their OLB counterparts in SYS$LIBRARY. 6.2.1 How To Create Shareable Images The compiler installation procedure places CXXL$BUILD_ SHARED_LIBCXXSTD_IMAGES.COM into the SYS$SYSTEM directory and places the linker options files into SYS$LIBRARY. The filenames of the options files are the same as the filenames of the images they create, but with a CXXL$ prefix. For example, the options file for the model ARM preinstantiation library image LIBCXXSTD.EXE is CXXL$LIBCXXSTD.OPT. The compiler installation procedure does not invoke CXXL$BUILD_SHARED_LIBCXXSTD_IMAGES.COM. To build shareable images, invoke CXXL$BUILD_SHARED_ LIBCXXSTD_IMAGES.COM as follows: @SYS$SYSTEM:CXXL$BUILD_SHARED_LIBCXXSTD_IMAGES.COM The procedure creates four shareable images from their respective OLB counterparts. It accesses the OLB libraries using the SYS$LIBRARY logical name and places the images into the same directory on the SYS$LIBRARY search list where the OLB libraries are located. The procedure does not insert images into IMAGELIB.OLB. 25 6.2.2 Linking Against the C++ Standard Library Shareable Image There are two ways of using the C++ Standard Library in the form of a shareable image: with and without inserting the library image into SYS$LIBRARY:IMAGELIB.OLB. Note that the following procedures are the same for object models ANSI and ARM, and for linking against the preinstantiation and noinstantiation libraries. Only name of the C++ Standard Library image is different. When linking against the OLB library, the CXXLINK utility automatically chooses the library based on the /MODEL and /NOPREINST qualifiers, so that the selection of OLB library is transparent. When linking against the shared C++ Standard Library, you must specify the correct Standard Library image yourself. The following examples use the model ARM preinstantiation library LIBCXXSTD.EXE. This is the default library; it is used when a program is compiled without any /MODEL qualifier and without the __FORCE_INSTANTATIONS macro defined. 6.2.2.1 Linking Without the C++ Standard Library Image in IMAGELIB.OLB The following example shows how to link without the C++ Standard Library image in IMAGELIB.OLB: cxx foo.cxx cxxl foo.obj, sys$input:/opt LIBCXXSTD.EXE/share ^Z define LIBCXXSTD disk:[directory]LIBCXXSTD.EXE; run foo 6.2.2.2 Linking With the C++ Standard Library Image in IMAGELIB.OLB This is probably the most convenient way of linking against shared C++ Standard Library. However, there are several restrictions: o Model ARM and model ANSI images cannot both be inserted into IMAGELIB.OLB because there are some symbols with the same names in the two libraries. 26 o Preinstantiation and noinstantiation images cannot both be inserted into IMAGELIB.OLB. This is because the noinstantiation library is a subset of the preinstantiation library. Therefore, inserting a preinstantiation library image into IMAGELIB.OLB will break linking /NOPREINST because library instantiation symbols will be resolved from IMAGELIB.OLB instead of from the user instantiations in the repository. So inserting a C++ Standard Library image into IMAGELIB.OLB is suitable for a site where only a single object model is used and where linking is consistently done against either preinstantiation or noinstantiation library. In order to link against the C++ library shareable image in IMAGELIB.OLB, create an empty LIBCXXSTD*.OLB library and make CXXLINK use it instead of the OLB library in SYS$LIBRARY. You can do this by defining a logical name CXX$LINK_LIBCXXSTD_DIR pointing to the location where the empty OLB library resides. For example, for the model ARM preinstantiation library: libr/create disk:[directory]LIBCXXSTD.OLB define CXX$LINK_LIBCXXSTD_DIR disk:[directory] Note that while the name of the logical remains the same, the name of the OLB library it points to depends on the object model and the preinstantiation/noinstantiation library. For example, for model ANSI it would be LIBCXXSTD_MA.OLB; for the model ARM noinstantiation library, it would be LIBCXXSTD_NOINST.OLB, and so on. With the C++ library shareable image in IMAGELIB.OLB, you can link against it without having to explicitly specify it on the CXXLINK command. For example: cxx foo.cxx cxxl foo.obj run foo 27 6.2.3 Restrictions 6.2.3.1 Overriding Global Operators new and delete As the C++ User's Guide indicates, programs overriding global new and delete must be linked /NOSYSSHARE. Such programs will have to continue linking /NOSYSSHARE against the OLB libraries. 6.2.3.2 Mixing OLB and Shared C++ Library in the Same Process Mixing dynamically loaded libraries linked against OLB and the shared C++ Standard Library in the same process is not supported. Also, a main executable must be linked against the same flavor (either .OLB or .EXE) of the C++ Standard Library against which the libraries it dynamically loads are linked. Violating this restriction can result in unpredictable behavior. 6.3 Restrictions This section describes problems you might encounter when using the current release of the C++ Standard Library with the HP C++ compiler. Where appropriate, workarounds are suggested. 6.3.1 Using the C++ Libraries in Microsoft Standard Mode When compiled /STANDARD=MS, the following restrictions apply: o typeid(__int64).name() returns __int64 instead of long long. o Header does not declare operator delete[](void*, void*). o Header does not declare type new_handler. o mem_fun function objects from cannot be used with a void first template argument. For example, the following program does not compile in Microsoft mode: template struct mem_fun_t { S (T::*pmf)(); S operator()(T* p) { return (p->*pmf)(); } }; 28 struct X {}; void (mem_fun_t::*pf) (X*) = &(mem_fun_t::operator()); o It is impossible to create a list container of elements of type size_t using the list(size_type) constructor. For example, the following program does not compile in Microsoft mode: #include #include std::list x(1); o Using ostream<< and istream>> operators with variables of type [unsigned] __int64 results in undefined linker symbols. o Using vector iterators results in compilation errors. For example, the following program does not compile in Microsoft mode: #include void f() { std::vector x; x.insert(x.begin(), true); } 7 Release Notes for the V6.5 C++ Compiler The following sections describe enhancements, changes, and restrictions for the C++ compiler environment. 7.1 Enhancements, Changes, and Problems Corrected in 6.6-??? o The compiler was not correctly handling certain unusual loops within a switch statement. (11108) o For a template specialization, the compiler mangles names differently depending on whether specialization is used. For example, if a function having parameter of vector type is the only entity in compilation unit referencing vector, function name will be mangled differently depending on whether the function actually uses its vector argument in the function body. 29 In order to eliminate this dependency, a dummy function was added to the C++ standard library header , as the following: #ifndef _RWSTD_NO_CLASS_PARTIAL_SPEC #if defined(__DECCXX) && !defined(__DECFIXCXXL1760) inline void __function_to_use_vector_bool() { vector x; } #endif #endif This function ensures, that vector specialization of vector<> is always treated as "used" in any program that #includes the header. (L1760) o Changes to and This kit supplies updated versions of DECC$RTLDEF.TLB (C library files) and CXXL$ANSI_DEF.TLB (C++ standard library header files) that address various issues in an upward-compatible fashion. However, there are changes to the conditionalization of the layout and member names for the type "struct tm" (from ), as well as conditionalization of the implementation of the gmtime() and localtime() functions [and their reentrant variants gemtime_r() and localtime_r()] to be used, that might affect some programs. As a general precaution to minimize possible problems, it is recommended that if any source module that #includes either or