HP OpenVMS Systems

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 2006 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 contains the release notes for HP C++ Version 7.3 for OpenVMS Alpha. The HP C++ product requires OpenVMS Alpha Version 7.3-2 or higher.

The HP C++ media contains the following:

• The Version 7.3 kit, which includes the HP C++ compiler and associated files, such as the Class Library and Standard Library header files.

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 

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:

• Differences between Standard Library versions
• Differences between compiler versions
• Differences between HP C++ and the C++ International Standard
• Retirement of cfront language dialect

The next sections discuss these differences.

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 a Appendix E Compiler Compatibility in HP C++ User's Guide for OpenVMS Systems .

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

• Diagnostic differences
  The Version 6.n or higher compiler does more error checking than Version 5.6 and generates more diagnostics. 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 .
• Implementation differences
  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, Using Templates section in the Compiler Compatibility Appendix of the HP C++ User's Guide for OpenVMS Systems .

The following items, specified in the C++ International Standard, are not supported in Version 7.3 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.

• The export keyword for templates (Standard §14, paragraph 6; Stroustrup §9.2.3)

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

4 Release Notes for the V7.3 C++ Compiler

The following are enhancements, changes, and restrictions for the C++ compiler environment in this version:

• A problem has fixed which could sometimes cause the compiler to crash when using the _MB builtin functions with /OPT=LEVEL=2 and higher.
• The compiler previously asserted when processing a function that belonged in a overload set, but which had not yet resolved to the specific function selected by the overload, and its parameters were not pointers or references. This has been fixed.
  
• A recent fix exposed another bug where the compiler failed to appropriately mark a pointer-to-member function call which returns a class with a non-trivial copy constructor by value, so the 'this' pointer and the pointer to the temporary created for the class object, were passed in an inverted order. This too has been fixed.
  
• The compiler bug where pointers of the correct size were not created in 64-bit modes, has been fixed. This bug typically manifested in the ?: conditional operator expressions, when either the second or the third operand of the expression dereferenced a pointer expression.
  
• When creating a pointer-to-member call, and the pointed member function was a function that returned a value via a copy constructor, the synthesized call would generate an ACCVIO when run, because the compiler did not correctly handle the transformed argument (for the value returned by the copy constructor). This has been fixed.
  
• Two other problems where the compiler was not generating pointers of the correct size in 64-bit modes have been fixed.
  
• Known Problem: In some situations, the compiler's loop unrolling optimization might generate memory accesses in the code stream that never actually execute at run-time, but which would violate the ANSI Aliasing rules if they were to execute. In such a situation, the compiler might emit an erroneous BADANSIALIASn message, where n is a number or is omitted.
  If the violations take place only in machine instructions that will not execute at run-time, these messages can be safely ignored.
  To determine whether or not particular instances of a BADANSIALIASn message are erroneous, recompile the module with the /OPT=UNROLL=1 qualifier. Any BADANSIALIASn messages that disappear under that qualifier can be safely ignored, so you may want to add appropriate "#pragma message" directives to the source, localized to the specific source lines known to be safe. This is preferable to disabling the message for the whole compilation, since in all other cases the message indicates a real potential for code generation that will not work as intended. And this is generally preferable to disabling the ANSI_ALIAS or loop unrolling optimizations, since that would likely degrade performance, although the amount of degradation is not predictable, and in unusual cases it might even improve performance. As always, when making changes to performance-critical code, it's best to measure the impact.
  
• In previous versions of the compiler, specifying /STAN=STRICT on the command-line disabled the /NOWARNINGS qualifier. This is no longer done.
  
• The compiler now emits a warning when encountering __declspec specifiers, which were never supported, but were silently ignored.
  
• The compiler incorrectly failed to compile code constructs with __builtin_va_start when in the /STANDARD=GNU mode. This has been fixed.
  
• In 64-bit compilations only, the compiler would produce incorrect code if a pointer to a const object was deferenced, its constness cast away with a const_cast to a non-const reference of the same object type, and an attempt was made to bind a value to this reference object. This has been fixed.
  
• The compiler now diagnoses some cases where long pointers were converted to short pointers, where previously these were not diagnosed.
  
• The compiler no longer emits incorrect MAYLOSEDATA diagnostics for some simple expressions, such as assigning the address of a local variable to a short pointer.
  
• Previously, the compiler incorrectly created short pointers when arrays were decayed in certain expressions. This has been fixed.
  
• The compiler now implements the partial ordering specification resolved by Core Issue 214 of the C++ Standard.
  This is demonstrated by the following program:

  extern "C" int printf(const char *, ...); typedef unsigned int size_t; template <typename T> void func1(const T&) { printf("T\n"); } template <typename charT, size_t N> void func1(charT(&)[N]) { printf("charT[N]\n"); } template <typename X, typename T> void func3(const T&) { printf("T\n"); } int main() { func1("hello"); func3<int>("hello"); // error before }

  
  
• The compiler previously generated incorrect source location information, which made the debugger behave as if the user said "step/into" when using the command "step". This made stepping over inlined constructors and thunks particularly difficult. This has been fixed.
  
• When using the /MODEL=ANSI object model, the compiler sometimes passed to member functions the "this" pointer and the "pointer to struct" returned by value, in an incorrect order. This has been fixed.
  
• The compiler incorrectly produced an OPNDNOTCLS diagnostic for certain code constructs when compiling in the /STANDARD=GNU dialect. This has been fixed.

  enum ia64_instruction_constants { instruction0_shift = 5 }; class uint128_t { unsigned lo; public: uint128_t(unsigned l) : lo(l) { } unsigned low() { return lo; } operator unsigned() const { return lo; } uint128_t operator <<(int sa); }; void insert_break() { uint128_t break_raw(167); (break_raw << instruction0_shift).low(); }

  
  
• The compiler in the /MODEL=ANSI object model, sometimes created the "this" pointer of the incorrect size for base classes that are templatized. This has been fixed.
  
• When a predefined macro is undefined using an #undef directive, the compiler now issues the NOUNDEFPREMAC diagnostic with Warning severity in all modes except /STANDARD=STRICT. Previously, this diagnostic had Error severity.
  
• The compiler now issues a NEVERDEF diagnostic with the severity of a discretionary error when compiling with /STANDARD=STRICT, and with Warning severity in all other /STANDARD dialects:

  struct S { inline void foo(); void bar(); } void S::bar() { foo(); } // bar is not called, but foo is "used"

  
  
• The compiler now issues the BLTINCLNK diagnostic only if the routine would have been treated as an intrinsic function had it had "C" linkage. Previously, the diagnostic was emitted for a broader set of routines.
  
• The compiler now has a fix for a buffer overflow problem that previously was exposed when using the /XREF qualifier.
  
• The compiler no longer allows specifying the /PREPROCESS_ONLY and the /OBJECT qualifiers together on the command line. Previously, the compiler accepted both qualifiers but did not produce an object file.
  
• The compiler would previously ignore the specification of the /ASSUME=NOHEADER_TYPE command-line qualifier when using the CXX$USER_INCLUDE logical. This has been fixed.
  
• The compiler would sometimes produce an assertion if union objects were passed by reference. This has been fixed.
  
• When compiling /OPT/DEBUG, the compiler could accvio when processing some compiler-generated code for interludes. This has been fixed.
  
• When compiling and linking /DEBUG, sometimes a static data member was not instantiated, resulting in a undefined message from the linker. This has been fixed.
  
• In rare cases, a compilation that used a comma list to specify more than one source file could cause a compiler crash. This has been fixed.
  
• When /STANDARD=STRICT (or LATEST) was specified, if a type was a dependent type, it would not accept more than one string literal initializer in an aggregate initializer context. This has been corrected.

  template <typename T> void test() { const T *s[] = { "foo", "bar" }; // previously an error const char *t[] = { "foo", "bar" }; } int main() { const char *s[] = { "foo", "bar" }; test<char>(); }

  
  
• It is now possible to #undef a predfined macro (such as __LINE__ ) in all modes except /STANDARD=STRICT or LATEST. A warning diagnostic is issued, but the macro will be undefined. This matches the behavior of C++ on OpenVMS Integrity.
  
• The V7.1 compiler would emit a BLTINCLNK diagnostic if a C++ linkage function declared a name that would normally be an intrinsic function, even if the paramters and/or return type did not match those expected by the intrinsic. With this update kit, the diagnostic will only be output if the parameter and return type matches the intrinsic.
  
• The V7.1 compiler would allow a command line to specify both /PREPROCESS_ONLY and /OBJECT. In this case, the compiler would silently ignore the /OBJECT qualifier, and no .OBJ file would be produced. With this release, a %DCL-W-CONFLICT diagnostic is output for this case.
  
• With this update kit, the compiler now supports variadic macros. This feature allows macros to take a variable number of arguments. This feature was added to the HP C Compiler in the V6.4 release and is supported by a number other C and C++ compilers. The feature is available only when the value of the /STANDARD qualifier is RELAXED (the default), MS, or GNU.
  
• Certain bad uses of the va_start macro could crash the compiler. This has been corrected.
  
• The PRAGIGNORE diagnostic is no longer output for the #pragma define_template directive when the /TEMPLATE=NOPRAGMA qualifier is specified on the command line.
  
• Use of certain expressions that used the array index operator on a string constant such as (long)&"str"[1] could crash the compiler. This has been corrected.
  
• The compiler now accepts the __inline language extension keyword in all language modes except /STANDARD=STRICT (or LATEST). The __inline__ keyword is also accepted, except in the strict or MS modes.
  
• There were two very minor flaws in the 64-bit pointer support. Both involved creating 64-bit pointers using constant values. An example is:

  void *n3 = (void *) 0x80000010ULL;

  
  In these cases, the V7.1 compiler could sometimes generate incorrect code when the pointers were used. This has been corrected.
  
• In certain cases, the compiler would emit a MAYLOSEDATA diagnostic when it should not have. This could only happen when mixed pointer-size support was enabled. The compiler would sometimes create a 64-bit pointer when it should have created a 32-bit pointer. This problem has been corrected.
  
• The DEFAULTTMPLARG is now a warning in all modes but the strict modes. This matches the behavior of C++ on OpenVMS Integrity.

The following are enhancements, changes, and restrictions for the C++ Standard Library in this version:

• When compiled in standard GNU mode, the library now defines the _RWSTD_NO_IMPLICIT_INCLUSION macro which causes library headers to #include their respective template definition files. This is necessary because in standard GNU mode, implicit inclusion is disabled.
  Before this change, the program below would link with undefined symbol when compiled in standard GNU mode:

  #include <vector> int main() { std::vector<int> v; v.push_back(0); }

The following sections describe enhancements, changes, and restrictions for the C++ compiler environment.

6.1 Enhancements, Changes, and Problems Corrected in Version 7.1

• The /TEMPLATE_DEFINE qualifier now requires an option.
• 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.
• #pragma module module-name [module-ident | "module-ident"]
  If the module-name is too long:
  • A warning is generated if /NAMES=TRUNCATED is specified.
  • 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:
  • /NAMES=TRUNCATE is specified, truncate the module-name to 31 characters, or less if the 31st character is within a Universal Character Name.
  • /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.
• 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.
• 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

  
  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.
• The compiler was not correctly handling break statements out of loops which follow an identifier label within switch statements. This is now fixed.
• 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.
• 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.
• A command procedure CXX$PRODUCT_REMOVE has been added to the HP C++ V7.1 kit for OpenVMS Alpha. This procedure allows you to remove the HP C++ compiler product. It performs the equivalent of a PCSI PRODUCT REMOVE command.
  You are required to disable the product license before issuing the command procedure to prevent a compilation from interfering with the delete process.
  If the compiler has been installed as a shared image, the command procedure will uninstall the image.
  The command procedure takes no parameters and can be run as follows:

  $ @SYS$SYSTEM:CXX$PRODUCT_REMOVE Do you wish to proceed with removing HP C++ <No>? Yes [Ret]

  
  Enter "Yes" to remove the compiler from your system.
• 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 available on OpenVMS Alpha Version V8.3 and higher. It requires pthreads library patch VMS83A_PTHREAD-V0100.
  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 7.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. 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 <stdlib.h> // EXIT_SUCCESS #include <pthread.h> #include <iostream> // cout #include <exception> // set_terminate #include <new> // 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

• __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 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 <string.h> 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.
• 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 <class T> 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.
• 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).

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

• 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:

  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 >

• The function _RWdestroy(ForwardIterator first, ForwardIterator last) has been modified to destroy the objects pointed to by iterators in the range [first, last]. Before the fix, the function was just looping through iterators without destroying the objects.
  The functions std::uninitialized_copy(), std::uninitialized_fill() and std::uninitialized_fill_n() have been modified to increment iterator(s) after the call to the _RWconstruct() function. This is to make sure that if an exception is thrown during constructing the object, only objects that were fully constructed by the std::uninitialized_*() function are destroyed.

The following sections describe enhancements, changes, and restrictions for the C++ Standard Library.

7.1 Enhancements, Changes, and Problems Corrected in Version 7.1

• While applications using the C++ library iostreams can be compiled with the _LARGEFILE macro defined, the C++ library iostreams do not support seeking to 64-bit file offsets. For more information on _LARGEFILE macro see the HP C Run-Time Library Reference Manual for OpenVMS Systems.
• This version of the C++ compiler implements C++ headers for C Library Facilities. The <cname> 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 <cname> 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 <cname> 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.
  Specifying the /NOPURE_CNAME option causes <cname> headers to be handled as if the corresponding <name.h> 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 <name.h> after including the corresponding <cname> header brings all names declared in that <cname> header into global namespace with using std::name declarations.
  New overloaded function signatures have been added to several <cname> headers (see Standard §21.4, 25.4, and 26.5). These overloaded signatures have been made available when including the <cname> 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:
  • 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)

  • 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:
  • cstring: (Standard §21.4) strchr, strpbrk, strrchr, strstr, memchr
  • cwchar: (Standard §21.4) wcschr, wcspbrk, wcsrchr, wcsstr, wmemchr
  • cstdlib: (Standard §25.4) bsearch, qsort, (§26.5) abs, div
    The added signatures could cause problems in existing 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 <cstring> void f(char*) {;} int main() { f(strchr("abc",1)); // strchr returns a const char* return 0; }

• A problem with vector container created by a constructor 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.
• A bug in codecvt<wchar_t,char,mbstate_t>::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 <locale> #include <iostream> using namespace std; int main() { codecvt_byname<wchar_t,char,mbstate_t>* p; // C locale p = new codecvt_byname<wchar_t,char,mbstate_t>(""); cout << p->encoding() << endl; // single-byte locale p = new codecvt_byname<wchar_t,char,mbstate_t>("en_US.ISO8859-1"); cout << p->encoding() << endl; // multibyte locale p = new codecvt_byname<wchar_t,char,mbstate_t>("ja_JP.SJIS"); cout << p->encoding() << endl; }

• codecvt<wchar_t,char,mbstate_t>::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.
• 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.
  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).
• A bug in codecvt<char,char,mbstate_t>::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.
• A bug in codecvt<char,char,mbstate_t>::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.
• The codecvt<char,char,mbstate_t>::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 .
• To be consistent with Library Issue 103, the reverse_iterator typedef in set and multiset has been changed to _RWrep_type::const_reverse_iterator.
• 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 <locale> struct foo : std::locale::facet { static std::locale::id id; }; std::locale::id foo::id; int main() { std::use_facet<foo>(std::locale()); return 0; }

• 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 <iostream> #include <iomanip> int main() { std::cout << std::hex << std::showbase << std::setfill('0') << std::setw(6) << std::internal << 33 << '\n'; }

• 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 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 <iostream> 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

• 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 <istream> to <string>. Accordingly, the definition of the std::getline() function operating on basic_istream and accepting the delim parameter has been moved from <istream.cc> to <string.cc>. This change is visible only when using the standard iostreams.
• 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. 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.

• The HP C++ library defines std::ostream_iterator as the following:

  template <class T, class charT = char, class traits = char_traits<charT> > class _RWSTDExportTemplate ostream_iterator : public iterator<output_iterator_tag,T,_TYPENAME traits::off_type,T*,T&>

  
  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 T, class charT = char, class traits = char_traits<charT> > class ostream_iterator: public iterator<output_iterator_tag, void, void, void, void>

  
  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.
  For example, consider the following program:

  x.cxx ----- #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include <iterator> #include <iostream> #include <typeinfo> using namespace std; int main() { cout << typeid(ostream_iterator<char>::value_type).name() << endl; cout << typeid(ostream_iterator<char>::difference_type).name() << endl; cout << typeid(ostream_iterator<char>::pointer).name() << endl; cout << typeid(ostream_iterator<char>::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

• The default constructor of class template std::istream_iterator<class T, class charT, class traits, class Distance> 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.

  #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include <iterator> #include <istream> std::istream_iterator<int, wchar_t> x;

• The min() and max() functions in the <long long> 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 <long> 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 <limits> #include <iostream> using namespace std; main() { cout << "max() = " << numeric_limits<long long>::max() << endl; cout << "min() = " << numeric_limits<long long>::min() << endl; cout << "max() = " << numeric_limits<unsigned long long>::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

• The C++ Standard Library header <vector> was modified to expose std::vector<bool> overloads of relational operators only when compiling with the __DECFIXCXXL1941 macro defined. These overloads make it impossible to use relational operators on vector<bool>::iterator types; see the code example below. That the current C++ standard lists these overloads (section 23.2.5 - Class vector<bool> [lib.vector.bool]) is considered to be a defect in the standard. Some other implementations of STL do not provide these overloads.
  With std::vector<bool> overloads of all the relational operators removed, the following program compiles. Before the change, it would not compile.

  #include <iterator> #include <vector> class D : public std::reverse_iterator<std::vector<bool>::iterator> { }; int main(void) { D x, y; if ( std::operator== <std::vector<bool>::iterator>(x,y) ) return 0; if ( std::operator!= <std::vector<bool>::iterator>(x,y) ) return 0; if ( std::operator< <std::vector<bool>::iterator>(x,y) ) return 0; if ( std::operator<= <std::vector<bool>::iterator>(x,y) ) return 0; if ( std::operator> <std::vector<bool>::iterator>(x,y) ) return 0; if ( std::operator>= <std::vector<bool>::iterator>(x,y) ) return 0; return 1; }

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:

• LIBCXXSTD.EXE - model ARM preinstantiation library
• LIBCXXSTD_NOINST.EXE - model ARM noinstantiation library
• LIBCXXSTD_MA.EXE - model ANSI preinstantiation library
• 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.

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

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

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

This is probably the most convenient way of linking against shared C++ Standard Library. However, there are several restrictions:

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

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.

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

7.3 Restrictions in Version 7.1

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.

7.3.1 Using the C++ Libraries in Microsoft Standard Mode

When compiled /STANDARD=MS, the following restrictions apply:

• typeid(__int64).name() returns __int64 instead of long long .
• Header <new> does not declare operator delete[](void*, void*) .
• Header <new> does not declare type new_handler .
• mem_fun function objects from <functional> cannot be used with a void first template argument. For example, the following program does not compile in Microsoft mode:

  template <class S, class T> struct mem_fun_t { S (T::*pmf)(); S operator()(T* p) { return (p->*pmf)(); } }; struct X {}; void (mem_fun_t<void, X>::*pf) (X*) = &(mem_fun_t<void, X>::operator());

• 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 <stddef.h> #include <list> std::list<size_t> x(1);

• Using ostream<< and istream>> operators with variables of type [unsigned] __int64 results in undefined linker symbols.
• Using vector<bool> iterators results in compilation errors. For example, the following program does not compile in Microsoft mode:

  #include <vector> void f() { std::vector<bool> x; x.insert(x.begin(), true); }

Other Standard Library restrictions in this release are:

• The std::use_facet<FACET> function template can be instantiated only on facets having a default constructor.

The following sections describe enhancements, changes, and restrictions for the C++ compiler environment.

8.1 Enhancements, Changes, and Problems Corrected in 6.6-???

• The compiler was not correctly handling certain unusual loops within a switch statement. (11108)
• For a template specialization, the compiler mangles names differently depending on whether specialization is used. For example, if a function having parameter of vector<bool> type is the only entity in compilation unit referencing vector<bool> , function name will be mangled differently depending on whether the function actually uses its vector<bool> argument in the function body.
  In order to eliminate this dependency, a dummy function was added to the C++ standard library header <vector> , as the following:
  

  #ifndef _RWSTD_NO_CLASS_PARTIAL_SPEC #if defined(__DECCXX) && !defined(__DECFIXCXXL1760) inline void __function_to_use_vector_bool() { vector<bool> x; } #endif #endif

  
  This function ensures, that vector<bool> specialization of vector<> is always treated as "used" in any program that #include s the <vector> header. (L1760)
• Changes to <time.h> and <time.cc>
  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 <time.h> ), 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 <time.h> or <time> is recompiled, all modules in the application that #include either of those headers should also be recompiled. Note that the C++ header <time> #includes <time.cc> (when /NOIMPLICIT_INCLUDE is in effect). The C++ header <time> in itself is not affected.
  The purpose of the changes is to address an interrelated set of functionality, user-namespace, and binary compatibility issues in a way that will be consistent between C and C++ going forward with new versions of the compilers and run-time libraries.
  
  • Functionality:
    The C++ standard library's "time_put" time formatting facet supports timezone formatting from a value of type "struct tm". Therefore, C++ compilations need to ensure that the implementations of localtime() and gmtime() selected [and their reentrant _r variants] are the ones that support timezone information. One specific functionality bug addressed by the changes is that some versions of the header provided two additional members for timezone information in the declaration of struct tm for use by C++, but did not cause the timezone-aware implementations of the time functions to be selected under those same conditions. This could lead to use of uninitialized data, or an access violation when the user code then tried to access the additional members of struct tm.
    
  • User-namespace:
    The members of struct tm that support timezone information are not part of the C standard. They are actually a common extension from BSD Unix, with conventional names of tm_gmtoff and tm_zone. Although the C standard allows an implementation to define additional members in struct tm, it does not reserve the prefix "tm_" for that purpose. So a strictly-conforming C program could #define tm_zone as a macro expanding into something that would cause a syntax error when encountering tm_zone as the name of a member in a struct type. Or conversely, a program compiled with the strict C namespace in effect could refer to the members by their BSD names, without getting a diagnostic, and infer that the names were defined under the C standard.
    Previous versions of <time.h> handled this issue by suppressing the declaration of these two members entirely under the strict C namespace (_ANSI_C_SOURCE). This new version (when used with C++ versions *newer* than V6.5-042) defines struct tm such that the timezone members have names in the namespace reserved to the implementation when the strict C namespace is in effect: instead of tm_gmtoff and tm_zone it uses __tm_gmtoff and __tm_zone (which is the convention on Tru64 and Linux systems). Because the <time.cc> header contains source code that refers to the "tm_zone" member of struct tm, that code had to be conditionalized to use "__tm_zone" when the strict C namespace is in effect (and continue to use the BSD names when it is not in effect).
    
  • Binary compatibility:
    Previous versions of <time.h> that suppressed the two non-standard members in struct tm under the strict C namespace resulted in potential binary incompatibility between modules compiled with/without the strict C namespace. The practice in the new <time.h> of just changing the names of the members to meet the requirements of the strict namespace makes modules compiled with either setting binary compatible, but it introduces potential for binary incompatibility with pre-existing object modules that cannot be recompiled from source.
    Note that modules compiled with different sizes for struct tm only have potential for encountering a problem; in typical usage no problem will occur because struct tm is not often embedded within a struct or used as an element of an array, with that struct or array then shared beteen compilation units. Typical code using struct tm only accesses it locally through the pointer returned by the library functions, or contructs a local instance that is then passed by address to library functions. Those kinds of uses are not affected by a size difference that occurs between different compilations.
    But to help deal with possible situations where a real binary compatibility problem is encountered, and it is not feasible to recompile all of the modules involved, the struct declaration in <time.h> can be forced to the short version (without the timezone members) by defining the macro "_TM_SHORT" before the header is included. Similarly, the declaration can be forced to the long version by defining "_TM_LONG". These macros will override any other conditionalization based on the version of the CRTL and the compiler, and produce a struct tm declaration that is of the specified size.
  
  As described above, the use of implementation-reserved identifiers to make the size of struct tm uniform regardless of whether or not the strict C namespace is in effect is conditionalized to the new C++ compiler. These headers are shared between C and C++ compilers, and that change will not affect existing versions of the C compiler. Unlike C++, the C compiler enables the strict C namespace under its /stand=ansi89 or /stand=c99 qualifiers as well as when any of the _XOPEN, _POSIX, or _ANSI_C standard-conformance macros are specified (see section 1.5 Feature-Test Macros for Header-File Control in the C Run-Time Library Reference Manual). It was felt that the risk of binary compatibility problems would be slightly greater for C than for C++ because these options are more commonly used with C compilations than they are with C++. However, the _TM_LONG (and _TM_SHORT) macros will affect both compilers. If your application contains C modules that #include <time.h> (as well as C++ modules that do), it is advisable to recompile those C modules with /define=_TM_LONG to avoid possible binary incompatibility between the C and C++ modules.
• A problem with catching a VMS exception when compiled /names=as_is and/or with the __NEW_STARLET macro defined, has been fixed. In this compiler release, however, the fix is available for object model ARM only. The fix for object model ANSI is planned to be released in the next major compiler release for OpenVMS Alpha.
  For example, the following program now outputs "caught signal". Before the fix, if compiled /names=as_is or with the __NEW_STARLET macro defined, it would output "missed VMS signal". (10655)
  

  #include <chfdef.h> #include <lib$routines.h> #if __DECCXX_VER <= 60590042 #define cxxl$set_condition CXXL$SET_CONDITION #endif #include <cxx_exception.h> #include <stdio.h> main() { try { cxxl$set_condition(cxx_exception); lib$signal(99628); } catch (chf$signal_array&) { puts("caught signal"); } catch (...) { puts("missed VMS signal"); } }

• Exception handler now preallocates some memory so exceptions can be thrown even if no memory is available. (7881)
• The compiler was incorrectly computing the element size as zero when the array was a typedef-ed type. This caused problems, for instance, when whole array destruction was invloved. (10865)
• When compiled with full IEEE support (-ieee option on Tru64 and /FLOAT=IEEE/IEEE=DENORM qualifiers on AlphaVMS), denorm_min() function of the specialization of class template std::numeric_limits for long double would return garbage. It has been corrected. For example, the program below now returns the correct value: 6.47518e-4966. (L1880)

• Compiler assertion compiling very large programs with debug has been eliminated. (10828)
• Compiler crash in pipeline optimization has been eliminated. (10216)

• A program using standard iostreams for non-standard __int64 and long long datatypes could not be compiled in strict ansi mode. This restriction has been eliminated. (L1823)
• Eliminate buffer overrun in CXXLINK. (10633)
• Eliminate incorrect diagnostic on using declaration of template base class. (10513)
• Eliminate compiler assertion when using a complex expression in the condition of a for loop. (10678)

• Problem looking up non-dependent names that are static has been corrected. (10458)
• Compiler crash when compiling in strict ANSI mode has been eliminate. (10460)

• Eliminated incorrect unreachable diagnostic introduced in the V6.5-034 compiler. (10307)
• Corrected template argument deduction bug. (10352)
• Corrected bad debug information generated for importing typedef into namespace. (10280)

• Improve compilation speed by eliminating the opening and closing of header files that have include once preprocessor guards. (8786)

• Inappropriate inaccessible member diagnostic has been eliminated. (10215)
• Inappropriate diagnostic when initializing data members of a class template has been eliminated. (10238)
• Compiler assertion when processing memcpy has been eliminated. (10137)
• Bad runtime typeinfo (RTTI) has been corrected. (10156)

• Implemented "/first_include" which includes the specified file before processing sources. (5434,10064)
• Eliminate compiler assertion for catch blocks with control flow that will not reach the end of the block. (9946,10046)
• Do not issue a warning if a template parameter is not used in signature of template if it is possible to use the template. (9909)

• Implemented "/main=posix_exit" which causes main to call __posix_exit instead of exit when returning. (9724)
• Eliminate compiler assertion for catch blocks with control flow that will not reach the end of the block. (9946)
• Eliminate compiler assertion for code with embedded newlines. (9962)

• Compiler crash when compiling member function "-g" has been eliminated. (9769)
• Incorrect handling of memmove of overlapping strings with "/arch=ev56" or later has been corrected. (9791)

• Compiler crash in exception support has been eliminated. (9743)
• Incorrect this pointer when calling a virtual function from a constructor has been corrected. (9751)
• Compiler crash in exception support has been eliminated. (9756)

• Compiler crash when using goto statements has been eliminated. (9666)
• Compiler crash when using multi-dimensional arrays has been eliminated. (9675)
• Implemented prototype for pragma include_directory . (9677)
• Undefined symbols when using RTTI information for long long types in model ANSI has been corrected. (9687)
• Incorrect error about using declaration has been eliminated. (9693)
• Runtime crash when using exceptions and optimization has been eliminated. (9697)

• Incorrect informational about partially overridden virtual function has been eliminated. (9343)
• Compiler hang when generating XREF cross reference information has been eliminated. (9561)

• std::deque<>::erase(iterator position) function has been corrected to return end() if after erasing the element the container is empty. (L1686)
• Compilation errors when compiling builtins.h in ms mode have been eliminated. (9588)
• Problem with dynamic_cast using class defined in shared images has been corrected. (9603)
• Error message for utimes function prototype when including time.h has been eliminated. (9609)

• Code generation problem resulting in failure of virtual function override when using -nortti has been corrected. (9575)
• Fix buffer overrun in ostrstream and strstream. (L1684)
• Incorrect "extern inline function was referenced but not defined" diagnostic has been eliminated. (8862)

• Code generation problem resulting in virtual function call to member function from class of same name, but in a different namespace, has been corrected. (9566)

• Release notes updated to clarify version compatibility.

• Compiler crash in optimizer has been eliminated. (9532)
• Missing initialization of static variables corrected. (9530)
• Compiler crash when using listing files with macro expansion and very long lines has been eliminated. (9518)
• Optimization problem with memcpy intrinsic has been corrected. (9512)
• When called with a null string, the basic_stringbuf::str(const string_type& str) method was not setting the underlying character buffer to zero length. It has been fixed. [10.1674]
• <new> and <new.hxx> library headers have been modified to suppress "support for placement delete is disabled" informational message at the point of declaration of nothrow version of operator delete and nothrow version of array delete. [10.1675]

• Improved compiler optimization resulted in reduced abstraction penalty in Stepanov benchmark.
• When called with a null string, the basic_stringbuf::str(const string_type& str) method was not setting the underlying character buffer to zero length. It has been fixed. [10.1674]
• <new> and <new.hxx> library headers have been modified to suppress "support for placement delete is disabled" informational message at the point of declaration of nothrow version of operator delete and nothrow version of array delete. [10.1675]

• Improved conformance to the C++ International Standard
• Improved code optimization
• Retirement of CFRONT dialect announced
• The library header and template definition files have been modified to compile in STRICT_ANSI mode with the Version 6.5 compiler. Modification was necessary because Version 6.5 enforces more stringent language rules in some cases than previous versions. [10.1649]
• The deallocate() member function of the allocator class in the <memory> header has been modified so that operator delete is not called with the null pointer. Although calling delete with the null pointer is legal in HP C++, the Third Degree tool on Tru64 UNIX issues a warning when such a call is made. The modification was made to avoid the warning. [10.1657]

• If you compile and link with /MODEL=ANSI and then try to use the VMS debugger to access members of a virtual base class, you might see this error:

  %DEBUG-E-INTERR, debugger error in DBG$GET_BASE_CLASS_OFFSET: can't find __bptr or session corruption

  
  The error is displayed because the debugger has not yet been updated to understand the new internals of the ANSI object model.
• Comparing an object of the Standard or Class Library fstream class with the null pointer causes an ambiguity compilation error.
  For example, the following program produces compilation error:

  #include <fstream.h> int foo() { fstream fs; if (fs == NULL ) return 0; return 1; } $ cxx/noobj x.cxx if (fs == NULL ) return 0; .........^ %CXX-E-AMBIGUOUSOPRFUN, more than one operator "==" matches these operands: built-in operator "pointer == pointer" built-in operator "pointer == pointer" operand types are: fstream == int

  The workaround is instead of comparison with the null pointer which is based on operator void * () use operator! (). For example, if the program is modified as following:

  if ( !fs ) return 0;

  it compiles cleanly. [L1710]
• Tight coupling of any of std::cout, std::cerr and std::clog by making them use the same strstreambuf object may cause a deadlock in a multithreaded application. For example, the following program may deadlock:

  ofstream log("test.log"); cout.rdbuf(log.rdbuf()); cerr.rdbuf(log.rdbuf()); ... writing to cerr from different threads ...

  The workaround is to untie the streams before tight coupling them, as the following:

  ofstream log("test.log"); cerr.tie(0); cout.rdbuf(log.rdbuf()); cerr.rdbuf(log.rdbuf());

  Note, that the current implementation of the C++ Standard Library ties all four standard streams (the C++ standard only requires, that cin is tied to cout). [L1707]

• In strict_ansi mode, the name of a class is now entered as a member of itself, as required by clause 9 (para 2) of the Standard; this behavior is implemented more or less as an implicitly declared member typedef and might cause some existing programs to fail. For example:

  namespace std { class iterator {}; } struct tree { struct iterator {}; struct nested : public std::iterator { // HP C++ 6.2 and below thinks this is tree::iterator // HP C++ ?? in strict_ansi mode thinks this is std::iterator nested(const iterator&); }; };

  
  [6613]
• The error "incompatible parameter", issued when there is a difference in sign between pointers, has been made discretionary. As a result you can now reduce/increase the severity of this message or enable/disable it using its error tag incompatibleprm or its error number. The same can also be done by enclosing the offending code in #pragma. For Example, the error message for the following program can now be controlled.

  void f(unsigned int *i) { } void main() { f((int *)0x05); }

  
  In addition, specifying -std gnu reduces the message severity to warning.
• The undocumented operator char*() , which converts a String to a pointer to char in the non-standard String class has been conditionalized with the macro __DEC_STRING_COMPATIBILITY so that it is available only when the program is compiled with the macro defined.
  This operator has been conditionalized beccause it allows passing a String object to functions like istream::get() or istream::getline() that expect a pointer to char .
  The String::operator char*() returns a pointer to the "data component" of the String , which is a private data member inside the String class. When a String object is passed to a function expecting a pointer to char , the function cannot determine how much memory has been allocated by the String , and the String cannot determine the status of the exposed pointer and the memory to which it points.
  This design flaw in the non-standard String class has been fixed in a way that leaves the legacy functionality available as an option. The standard ANSI C++ String class, for example, lets users retrieve only a const char* , not a char* , to the pointer owned by the String . [10.1563]
• In response to user requests, CXXLINK by default now deletes the option file SYS$DISK[]CXX_REPOSITORY.OPT that previously remained in the user's current directory on completion of CXXLINK.
  To support this change, CXXLINK creates a unique prefix for the repository .OPT filename in the following format:

  <nodename><PID>.OPT

  
  For example, if the node name is MYNODE and the PID is 020204AEA, the file name would be MYNODE020204AEA.OPT. This option file is created in the [.CXX_REPOSITORY] directory, if one exists. If the [.CXX_REPOSITORY] directory does not exist, the CXXLINK . [7135]
• In Version 6.2, signaling of VMS exceptions or a C signal might cause a program to terminate with %CXXL-F-TERMINATE status regardless of which VMS exception or C signal has been raised and regardless of whether a VMS exception handler or C signal handler has been established.
  For example, the following test1.cxx program calling lib$stop(SS$_MCNOTVALID) terminates with %CXXL-F-TERMINATE :

  #include <lib$routines.h> #include <ssdef.h> main() { lib$stop(SS$_MCNOTVALID); } $ run test1 %CXXL-F-TERMINATE, terminate() or unexpected() called %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC ...

  
  Similarly, the following test2.cxx program, establishing a C signal handler to catch a SIGILL signal, also terminates with %CXXL-F-TERMINATE without a signal handler being invoked:

  #include <signal.h> #include <stdio.h> static void signal_handler(int x) { puts("signal arrived"); } void main() { signal(SIGILL, signal_handler); raise(SIGILL); }

  
  Version 6.3 corrects this behavior: the C++ run-time environment no longer issues a call to terminate() if a VMS exception (possibly, generated by a raise() or gsignal() function arrives. Instead, the exceptions is resignaled to the next exception handler, and the exception is handled properly.
  For example, the test1.cxx program now correctly terminates with the OpenVMS condition value specified in the call to lib$stop() as follows:

  $ run test1 %SYSTEM-F-MCNOTVALID, device microcode is not valid %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC ...

  
  And test2.cxx now catches the signal and terminates correctly as follows:

  $ run test2 signal arrived $

  [7550, 8234]
• The compiler can no longer generate machine code listing when requested to not produce object files. [8448]
• CXXLINK no longer incorrectly concatenates arguments passed to it if such arguments are defined as logical names. [8467]
• CXXLINK now correctly handles filenames when using extended ODS-5 file parsing. [8626]
• In the ANSI object model (/model=ansi), string literals are treated as pointers to const char (const char *). In the ARM object model (/model=arm, the default), string literals continue to be treated as pointers to char (char *). [8659]
• To generate the correct code to make calls to virtual functions that return a structure, class, or union, the compiler needs the full definition of the type returned, which is missing in the following code fragment:

  struct Cities; struct Storage { int x; virtual Cities visit() = 0; }; struct Reader : virtual Storage { Cities visit(); }; struct T2 : Reader { }; extern void ggg(Storage *); void fff(void) { Storage *s = new T2(); s-x = 23; ggg(s); }

  
  Because the complete definition for the type Cities is missing, the compiler cannot correctly generate the code that allows ggg() to call s-visit() for all possible definitions of the type Cities. Previous compiler versions generated code that worked for some definitions of Cities but not for others.
  The current version of generates a diagnostic when it encounters a situation:

  virtual Cities visit() = 0; ...................^ %CXX-E-INCTYPPREVIRTAB, The incomplete type Cities precludes correct generation of the virtual table for the type Reader. Supply the complete type definition for Cities or use /MODEL=ANSI. at line number ... in file ...

  
  If you provide the definition of the type Cities in the module that generates this diagnostic, the compiler can generate the correct code. This code generation problem has been corrected in the ANSI object model. It could not be corrected in the ARM object model because an model incompatibility would have resulted. [8668]
• In basic_istream and basic_ostream , sentry constructor has been modified to not create the guard object if the stream is tie() 'ed to a stream using the same streambuf object. This eliminates the mutex deadlock which can occur in a multithreaded application. [10.1641]
  With this modification, the following program no longer hangs when compiled with /define=DEADLOCK and linked against the PTHREAD library.

  #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include <iostream> int main() { ostream x(std::cout.rdbuf()); ostream y(std::cout.rdbuf()); #ifdef DEADLOCK y.tie(&x); #endif y << "Hello, world" << std::endl; return 0; }

• To ensure thread safety, the basic_string reference count used to be protected by a mutex, which called thread locking and unlocking routines. Performance of this class in multithreaded applications has been improved by changing the implementation to use instead atomic builtins (see Appendix C in the HP C++ User's Guide for OpenVMS Systems ).
  [10.1138]
• Undefined symbols from the Standard Library no longer occur when using the /names=as_is qualifier. [10.1158]
• On OpenVMS Alpha Version 7.0 and above, the Standard Library headers now include pthread.h to implement multithread safety. Currently this has the side effect of polluting the global namespace with non-reserved macro and typedef names such as EXCEPTION, THROW, CATCH, and so on from <pthread_exception.h> . This problem has been acknowledged as a defect and is being investigated In the meantime, if you are using any of these names you must change them or devise a workaround.
  For example, if you have:

  #include <vector> #define CATCH 42 // trying to define your own macro, but get redefinition error

  
  you would need to make the following change:

  #include <pthread.h> #undef CATCH // undef the pthread macro #include <vector> #define CATCH 42 // define your own macro

  [10.1205]
• The string extraction operator no longer removes the extra space at the end of the string, as in the following example

  ifstream inFile("input.dat"); // input.dat contains "abc de" inFile >> word; // read "abc" inFile.get(ch1); // ch1 should be space, was 'd'

  
  [10.1300]
• The basic_string::find_first_not_of(charT, size_type) function now works correctly if the string contained embedded nulls. [10.1316]
• In Version 6.2, basic_ostream::flush() did not always flush the buffer if the type of the stream was an fstream . The buffer is now always flushed. [10.1348]
• Compiling a program in -std strict_ansi mode using the basic_fstream class no longer causes run-time seg faults or core dumps. [10.1357]
• When using the Standard Library iostreams for interactive input to cin from a terminal, a user may have to type more than one Ctrl D to indicate end-of-file. [10.1413]
• The iostreams and locales are now multi-thread safe. [10.1429]
• Currently you might encounter compilation errors if you try to use a user-defined allocator and pointer class with the STL containers. This problem will be fixed in a future release. [10.1430]
• The Standard Library vector class now allocates space correctly for elements greater than 1024 bytes; runtime core dumps caused by incorrect allocation in previous versions no longer occur. [10.1459]
• The tree data structure, which sets and maps usage, has been refined to decrease the amount of space allocated for small element size containers. [10.1475]
• The standard library headers no longer include pthread.h or tis.h . They can therefore be used in conjunction with the macro _PTHREAD_USE_D4 (DECthreads POSIX 1003.4a/Draft 4 (or d4) interface). [10.1540]
• The following functions have been added to basic_filebuf class:

  bool __sync_with_device() const; // Returns the value of _RWsync_with_device flag.

  bool __sync_with_device(bool state); // Sets the value of _RWsync_with_device flag and returns // the previous value of the flag.

  
  These functions are not described in the C++ standard, and are provided as an extension in order to control the behaviour of basic_ostream::flush() method and std::endl and std::flush manipulators. The functions are available only on OpenVMS systems.
  If _RWsync_with_device flag is true, and if the type of the stream is an fstream , the basic_ostream::flush() function transfers all buffered data to the device as if the C Run-Time Library fsync() function were called.
  If _RWsync_with_device flag is false, it is not guaranteed that basic_ostream::flush() function or std::endl or std::flush manipulators will flush the data all the way to the device.
  To maintain compatibility with the behaviour of the Standard Library shipped with the HP C++ Version 6.2 compiler, the default value of _RWsync_with_device flag is false. The following example shows how the new functions are used.

  #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include <fstream> #include <stat.h> int main(void) { const char * filename = "file.dat"; std::ofstream testfile(filename); struct stat buf; // display file synchronization state cout << "1? file synchronization state is: " << testfile.rdbuf()->__sync_with_device() << std::endl; // write a record to the file testfile << "x" << std::endl; // check file size. Expected zero because by default endl // manipulator does not force data to be transferred to // the device. stat(filename, &buf); cout << "file size is: " << buf.st_size << std::endl; // set _RWsync_with_device flag to TRUE and display // previous file synchronization state cout << "file synchronization state is: " << testfile.rdbuf()->__sync_with_device(1) << std::endl; // write another record to the file testfile << "y" << std::endl; // check file size. Expected four because now std::endl // will cause data to be transferred to the device. stat(filename, &buf); cout << "file size is: " << buf.st_size << std::endl; return 0; }

  [10.1574]

If you compile and link with /MODEL=ANSI and then try to use the VMS debugger to access members of a virtual base class, you might see this error:

%DEBUG-E-INTERR, debugger error in DBG$GET_BASE_CLASS_OFFSET: can't find __bptr 
or session corruption 

The error is displayed because the debugger has not yet been updated to understand the new internals of the ANSI object model.

10 Release Notes for the V6.2 C++ Compiler

Enhancements, changes, and problems corrected are as follows:

• The compiler now generates code that reports a static data member as an undefined symbol at link time if the data member is referenced but not defined. [CXXC_BUGS 6826]
• The new cxxlink design implemented in Version 6.2 to use .olbs instead of objects is not a general solution. The default behavior of cxxlink was changed back to using objects ( /prelink=use_object_files ) and the switch /prelink=use_olb was added to obtain the new mechanism. The new mechanism was simplified for better performance. No attempt is made to try alternative link methods if the link fails; the default link must be used. [6804, 6795, 6583, 5997]
• In the C++ Version 6.1 compiler, some objects might have their exception unwinding information set to a negative index in the cleanup table. This condition generates the following message:

  Unexpected dtor_block_tag in do_dtor_cleanup

  
  [7091]
• Fix for raw_storage_iterator assignment operator
  In versions 6.2 and earlier, a problem in the assignment operator for the class raw_storage_iterator could cause a run-time seg fault if, for example, you called the algorithm stable_sort() more than once with the same container. The problem has been corrected. [10.1284]
• Fix for basic_string::compare() member functions
  In version 6.2, two of the basic_string::compare() member funrtions were throwing an exception if the length of the second string was longer than the length of the current string. This has been fixed so that they throw an exception only if the position the user specifies within the second string is greater than the length of the second string. [10.1298]
• Fix for basic_string::resize()
  A problem in the basic_string::resize() member function in Version 6.2 has been corrected. The incorrect behaveior was that if two strings pointed at the same underlying char* , and the resize() function was called on one of them, and if you then you changed the underlying string for one string, the value for the other strings value would also be changed. [10.1287]
• Fix to string assignment operator when assigning string with embedded nulls
  A problem in the basic_string assignment operator prevented strings containing embedded nulls from being copied correctly. The problem has been corrected. [10.1238]

This release solves several problems in earlier versions of the compiler and includes an updated OpenVMS debugger (dated 4-Mar-1999) that solves problems with the previous debugger.

Enhancements and changes are as follows:

• Support for explicit template function arguments.
• Improved EV6 support.
• CXXLINK creates an object library.
  CXXLINK now creates an object library (CXX$LINK.OLB) in the writeable repository directory. The object library is populated with all object files found in the repository.
  CXXLINK also checks any other repository directory listed on the command line (by use of /REPOSITORY= qualifier ) for CXX$LINK.OLB object libraries.
  Each object library is then used as input to the OpenVMS Linker through LNK$LIBRARY logical names.
  In most cases, the OpenVMS Linker can resolve any missing instantions by searching the object libraries. CXXLINK can then proceed directly to the final link, without having to parse the linker output looking for unresolved symbols and their matching object files.
  Note the following restrictions:
  • CXXLINK makes use of the OpenVMS Linker Utility's LNK$LIBRARY logical names to reference specific object libraries as input to the linker. If the CXXLINK command includes any form of the /USERLIBRARY , an informational message appears, and CXXLINK lists any required object libraries in a linker options file.
  • CXXLINK always creates and repopulates the object library. For large repositories, this mechanism is slower than processing the linker output and creating the linker options file listing each object file.
  • CXXLINK does not create the CXX$LINK.OLB file in nonwritable repository directories. Currently, this must be done outside of CXXLINK by entering the command:

    $ LIBRARY/CREATE non-writeable-repository-dirCXX$LINK.OLB - non-writeable-repository-spec*.OBJ

• Programs that use extern_model can encounter problems, because object files from an object library do not produce the same extern_model code that is generated when the object file is used directly.
• Modules that use extern_model must be listed separately as an input to the linker.
• A compiler crash caused by a label statement in a switch statement has been corrected. [6614]
• If a user calls VAXC$ESTABLISH or LIBC$ESTABLISH in a function with a try/catch, the establish routine now works correctly. Note that C++ exception handling is disabled in these routines, as described in