This document contains information about new and changed features in this version of Compaq C++ for OpenVMS Alpha.

Compaq Computer Corporation
Houston, Texas

© 2001 Compaq Computer Corporation.

COMPAQ, the Compaq logo, and Alpha, DEC, Ladebug, OpenVMS, and VMS are registered in the U.S. Patent and Trademark Office. Tru64 is a trademark of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX is a trademark of The Open Group in the United States and other countries. All other product names mentioned herein may be trademarks of their respective companies.

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

Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided as is without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.

Confidential computer software. Valid license from Compaq 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.

Contents

1 Introduction

This document contains the release notes for Compaq C++ Version 6.3 for OpenVMS Alpha. The Compaq C++ product requires OpenVMS Alpha Version 6.2 or higher.

The Compaq C++ media contains the following:

• The Version 6.3 kit, which includes the Compaq C++ compiler and associated files, such as the Class Library and Standard Library header files.
• The ADX072 kit, which contains an enhanced OpenVMS Debugger that provides better debugging of applications built with the Compaq 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

Compaq 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 Run-Time Library versions
• Differences between compiler versions
• Differences between Compaq C++ and the C++ International Standard

The next sections discuss these differences.

2.1 Run-Time Library Differences

Applications must use a version of the C++ Run-Time library that provides all the functions they require. If an application is linked shared, and the correct library version is not installed, "undefined symbol" error messages appear at run time. Changes in the Run-Time Library occurred in Versions 6.0 and 6.2.

For information about redistributing C++ Run-Time Library components, see Deploying Your Application in Using Compaq C++ for OpenVMS Alpha .

2.2 Compiler Differences

Starting with Version 6.0, the Compaq C++ compiler differs significantly from previous versions. There are several major differences that you should be aware of before using a Version 6.n compiler for the first time. These differences are summarized here. For more detailed information, see Porting to Compaq C++ in Using Compaq C++ for OpenVMS Alpha .

• 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 Porting to Compaq C++ in Using Compaq C++ for OpenVMS Alpha .

  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 requires excessive changes to your applications even when you use the /standard=arm option, or if you encounter problems using the Version 6.n 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 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 compiler to be similar to Version 5.6, compile with the /quiet option. See Message Control and Information Options in Using Compaq C++ for OpenVMS Alpha .
• Implementation differences
  The automatic template instantiation model has been redesigned for the current version. Although code compiled with Version 5.n and 6.n compilers 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. See Using Templates in Using Compaq C++ for OpenVMS Alpha .

The following items, specified in the C++ International Standard, are not supported in Version 6.3 but will 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)
• No cname version of headers provided (Standard §17.4.1.2; Stroustrup §16.1.2)
  Compaq C++ does not currently provide <cname> versions of the 18 ISO C library headers because no standard-conforming mechanism has yet been defined. Once such a mechanism is available, we plan to use it, rather than have the <cname> version incorrectly include the non- <cname> version.
  The C++ header file inclusion policy for treating ISO C Library headers specifies that for each of the 18 ISO C headers, C++ should provide a <cname> form and a <name.h> form. The <cname> version defines all the symbols defined by ISO C in the corresponding <name.h> header in the std namespace. The <name.h> header defines all the symbols defined by ISO C in the corresponding <name.h> header in both the std and global namespace.
  Some of the problems are as follows:
  • Because C library headers contain many non-ISO C names, it is impossible to avoid polluting either the std namespace, the global namespace, or both. (Remember that the global namespace is considered a real namespace that must not be polluted.) Namespace pollution is not only incorrect, it can lead to unexpected ambiguities.
    Consider the following program, which includes <cname> and <types.h> directly.

    #include <cname> // name.h includes types.h & brings it into std:: #include <types.h> // types.h in global namespace using namespace std; use something from types // ambiguity

  • Synchronizing the release of C and C++ headers.
  • C++ inherits and must work around bugs in the C headers.
  
  Compaq continues to investigate methods for providing this functionality in a way that ensures long-term compatibility with various C and C++ mplementations.
  As a workaround, you can conditionalize your modules to use the <cname> versions of the headers when they become available. For example:

  #ifndef __NO_NEW_HEADER #include <cstddef> #include <cstdlib> #include <cstdio> #else #include <stddef.h> #include <stdlib.h> #include <stdio.h> #endif //__NO_NEW_HEADER

A new OpenVMS Debugger (kit ADX072, dated 4-Mar-1999) is provided with the Version 6.3 kit and must be installed to debug programs compiled with Compaq C++ Version 6.3. This debugger solves several problems with the previous debugger.

To install the special C++ debugger, invoke VMSINSTAL:

@SYS$UPDATE:VMSINSTAL ADX072 device-name option-list

See the Compaq 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

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

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

4.1 Enhancements, Changes, and Problems Corrected in Version 6.3

Enhancements, changes, and problems corrected are as follows:

• 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 { // Compaq C++ 6.2 and below thinks this is tree::iterator // Compaq 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 .OPT file is created in the user's current directory. CXXLINK passes this file to LINK as the second file specified on the LINK command. To preserve LINK's directory search order, the directory specification of the first file is prefixed to the name of the second file, if a second file is specified. Depending on the CXXLINK option selected, CXXLINK deletes this .OPT file by default, or renames it to CXX_REPOSITORY.OPT or to a user-specified file name. For detailed information on CXXLINK options, type HELP CXXLINK or point your browser to 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]

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.

4.3 Enhancements, Changes, and Problems Corrected inVersion 6.2A

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]

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 C++ Exceptions, lib$establish and vaxc$establish in Using Compaq C++ for OpenVMS Alpha .
• The compiler has implemented the _poppar builtin function and added code to convert output type for _poppar , _popcnt , _leadz , and _trailz to match contents of the new OpenVMS builtins.h file. See Built-In Functions in Using Compaq C++ for OpenVMS Alpha .
• SCA Version 4.6-4 and later can import C++ cross reference data into its analysis data file. To import the data, follow these steps:
  1. Enter the command CXX/XREF filename.cxx to have compiler emit the cross reference data file filename.xref .
  2. Enter the command SCA/IMPORT filename.xref to generate filename.ana , the analysis data file.
• Because of a bug introduced in Version 6.0, the compiler emitted a union layout incompatible with earilier versions if the union contained bitfield of size 8, 16, 24... up to the size of the type for the bitfield. For example:

  typedef struct size4 { union { unsigned ttn :8; struct { unsigned incr :3; unsigned rep :5; } v1; } u; } size4;

  
  The size of size4 is 4 bytes for Version 5.7, and was incorrectly set to 1 since Version 6.0. This bug is fixed in V6.2. If you have such a bitfield in your code, you must recompile. [6567]

• A problem with /extern_model=strict_refdef using template static data members and inline functions has been fixed. Previously, the compiler reported multiply defined external errors for symbols starting with __SDG and __LSG . When creating shared images, these symbols must be put in the symbol vector of the shared image. For more information, see Sample Code for Creating OpenVMS Shareable Images in Using Compaq C++ for OpenVMS Alpha . [6506]
• A template class name can now be reused as a non-template class in a private namespace without generating an error message. [6541]
• Mangled names beginning with CXXL$ and DECC$ are now included in the demangler database and can be demangled. [6458]
• More cases of unreachable code are now diagnosed. If you receive warnings you believe to be inappropriate, please report them. [6534]
• The compiler no longer can exhaust virtual memory when computing the addresses of deeply nested virtual base classes. [6473]
• va_start now handles parmN arguments of types that are promoted. [6471]
• Some compiler-generated wrapper functions with the __STF____default_version prefix were not resolved in template automatic instantiation mode. The problem is corrected. [6362]
• Debugging support for constant variables is improved. Although the compiler does not generate debug information for constant externs (because you might not be able to link), it does generate debug information for all constant variables whose underlying type is int or float
• Bad code is no longer generated for an array reference within a template instantiation. [6394]
• Runtime type identification has been corrected for shared images. The RTTI calls dynamic_cast and typeid now work for objects created inside OpenVMS shared images. With this correction, the name of virtual function tables have been changed to __vtbl2__<class> , to prevent the new virtual function tables that point to RTTI information from conflicting with old tables. [6348]
• Debugging support is now provided for anonymous union variables inside namespaces. In the following example, debuggers support referencing s.a and s.b :

  struct S { union { int a; int b; } } s;

  
  In the following example, the compiler generates two variables, x and y , which the debuggers can examine.

  union { int x; char y[4]; };

  
  The compiler no longer generates tag names for tagless structs and unions.

• Under the following conditions, the compiler could generate code that returned the value of i before the store of the new value:
  1. Take the address of a variable, using a type other than the variable's type,
     (p = (char *)&i) .
  2. Assign to the variable using a pointer addition expression, *(p + 0) = new_value .
  3. Fetch the variable's value directly (return i) .
  
  The problem could occur only if the store using the pointer addition expression appeared within an if statement, as in the following:

  int f(int flag) { int len = 1; if (flag) { char *ppp = (char *)&len; *(ppp + 0) = 2; }; return len; }

  
  The problem has been corrected. [6421]

• The compiler no longer generate incorrect code for offsets to external arrays. [6386]
• The routine for new[] now calls delete[] if an exception occurs during construction. [6243]
• Many improvements have been made to cross-reference information generated by the compiler and read by the SCA tool.
• The compiler now replaces embedded line feeds with blank spaces during the initial scan.

This release is not totally compatible with previous versions; source changes might be required. The following general restrictions apply for the current release:

• The C++ International Standard permits overriding a virtual member function based only on a derived class return type. The current release does not support this capability.
• Instantiating function templates with array types can result in different external name encoding than with C++ Version 5.n. To avoid link errors, recompile the template definition with the current version of the compiler.
• Specifying a different long double size than the default size for your version of the operating system (using the /l_double_size qualifier) does not work correctly with the Standard Library.

This section briefly summarizes changes and enhancements made in Version 6.0, including problems fixed.

• Support for the C++ International Standard (with some differences, as described in Section 2.3), including the C++ Standard Library. See Section 5 for information on and changes to the Standard Library.
• An updated debugger (dated 6-Jan-1999) that fixes problems with the previous version of the debugger.
• Language mode options For compatibility with previous versions, the compiler supports an ARM language mode and provides both /standard=ansi and /standard=arm language mode options, as well as options to support other C++ dialects. For details, see Porting to Compaq C++ in Using Compaq C++ for OpenVMS Alpha .
• Improved automatic instantiation of templates, including:
  • Fewer restrictions. In particular, Compaq C++ no longer requires that template declarations and definitions appear in header files.
  • Build-time performance improvements that further reduce build times for applications that use templates extensively.
  
  For details, see Using Templates in Using Compaq C++ for OpenVMS Alpha .
• Language feature options
  The compiler supports the following options:
  • Use of alternative tokens (see Alternative Tokens in Using Compaq C++ for OpenVMS Alpha ).
  • Run-Time type identification (see Run-Time Type Identification in Using Compaq C++ for OpenVMS Alpha ).
• Performance optimization options
  Version 6.0 provides the following performance optimization options:
  • /[no]ansi_alias
  • /assume=[no]pointers_to_globals
  • /assume=[no]trusted_short_alignment
  • /assume=[no]whole_program
  
  For details, see Performance Optimization Options in Using Compaq C++ for OpenVMS Alpha .

This section describes the enhancements, problems corrected, and restrictions for the C++ Standard Library. For information about the Compaq C++ Class Library, See Appendix A in in Using Compaq C++ for OpenVMS Alpha .

The current version of Compaq C++ implements the new Standard Library string class, known as the String Library. Do not confuse this class with the String Package, which is part of the DEC C++ Class Library implemented in earlier versions of Compaq C++.

Note that portions of the ANSI C++ Standard Library have been implemented in Compaq C++ using source licensed from and copyrighted by Rogue Wave Software, Inc. Information pertaining to the C++ Standard Library has been edited and incorporated into Compaq C++ documentation with permission of Rogue Wave Software, Inc. All rights reserved.

Portions copyright 1994-2001 Rogue Wave Software, Inc.

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.

5.1 Enhancements and Changes, and Problems Corrected in Version 6.3

Enhancements, changes, and problems corrected are as follows:

• 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 B in Using Compaq C++ for OpenVMS Alpha ). [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 Compaq 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]

Enhancements, changes, and problems corrected are as follows:

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

The following enhancements and changes are included in Version 6.2:

• Cleaner header file inclusion policy
  The new version of the Standard Library is much more effecient than previous versions in its header inclusion policy. For example, the header file <algorithm> no longer includes <functional> . <ostream> and <istream> no longer include <locale> . Programs that used to count on these inclusions might break. You can correct them by explicitly including any header files you use in your own sources.
• New interface to get_temporary_buffer and use_facet
  Because the Version 6.2 C++ compiler now supports explicit template function arguments, it also supports the standard interface to the get_temporary_buffer() function. The following example shows how code must change:
  Change this:

  get_temporary_buffer(len,(T*)0); // two arguments

  
  to this:

  get_temporary_buffer<T>(len); // one argument

  
  where "T" is the value type of the container.
  The standard interface to the locale class use_facet() function is also now supported. The following example shows how code must change:
  Change this:

  use_facet(loc,(ctype<char>*)0);

  
  to this:

  // use_facet only takes one argument use_facet<ctype<char> >(loc);

• Smaller executables for users of the basic_string library component
  The Standard Library now provides a better separation of the STL and Standard IO components. As a result, users of the basic_string component of the Standard Library should obtain smaller executables. In Version 6.1, using only a string in an application caused all iostream and locale object files from the Standard Library to be included in the executable. These unnecessary files are no longer included. A correction to the Standard Library helps programmers users of just the basic_string component to obtain smaller executables. In the previous version, using just a string in an application caused the iostream and locale object files from the Standard Library to be included in the executable. The new version corrects that problem.

The following problems are corrected in Version 6.2:

• money_get / money_put locale facets now conform to International C++ Standard
  The money_get and money_put locale facets have been corrected to match the standard. In the previous version, for example, money_get appeared as:

  template <class charT, bool Intl = false, class InputIterator = istreambuf_iterator<charT> > class money_get;

  
  They now correctly match the standard, where the interface appears as:

  template <class charT, class InputIterator = istreambuf_iterator<charT> > class money_get;

  
  Note that the second template argument "Intl" has been removed. The member functions get() and put() now accept Intl as an argument.

• ios_base::openmode flags set to conform to the International Standard
  The Standard Library file stream classes have been corrected to conform to the International Standard with regard to setting the ios_base::openmode flags. In the previous release, it was possible to create a file for reading and writing with this code:

  #define __USE_STD_IOSTREAM #include <stdlib.h> #include <fstream> int main() { fstream fs("foo.out", ios_base::in | ios_base::out); fs << "abc" << endl; return EXIT_SUCCESS; }

  
  In the current release, this code works only if the file already exists. If the file does not exist, you must also specify ios_base::trunc ; that is, you must change the first line in main() to:

  fstream fs("foo.out", ios_base::in | ios_base::out | ios_base::trunc);

  
  This conforms to table 92 in the Standard, which specifies the "C" equivalent of the File open modes.

• Correction to list::sort(Compare)
  A bug in the list::sort(Compare comp) member function is corrected. Previously, if users supplied their own Comparison function object for the element of the list, the compiler issued a message stating that it required an operator< defined for the element type. This no longer occurs.
• reverse_iterator now matches the Standard
  reverse_iterator has been changed to match the standard. It now takes only one template argument of type iterator instead of five. Users must change existing code to remove the additional unnecessary arguments.
• bitset constructors no longer accept a const char
  A bitset can no longer be constructed with a const char* argument. For example, the following no longer compiles:

  bitset<32> b("111111111");

  
  The constructor that takes a string is a templatized constructor, and thus can perform type deductions only on exact matches, not conversions (for example, const char* to string). To make the code in the previous example compile with the current version, the argument must be explicitly cast to a string, as follows:

  bitset<32> b( string("111111111"));

• assign(size_t) removed from vector , deque , list
  Previous releases of the Standard Library contained a member function called assign() inside the vector , deque , and list classes. This function accepted only a size_t argument. This has been removed, because it is not in the Standard. You must add an extra argument indicating the value you want assigned. For example, you change calls like the following:

  v.assign(5); // where v is a vector<int>

  
  to:

  v.assign(5, int());

• allocator<>::deallocate(pointer) removed
  The member function allocator<>::deallocate(pointer) has been removed. The Standard requires two arguments for this member function. The second argument should be of size_type and have the same value as the first argument passed to allocator<>::allocate() .
• basic_ios now initializes skipws|dec
  To conform to the Standard, the following basic_ios constructor constructs a basic_ios object and initializes the format control bits to skipws | dec :

  explicit basic_ios(basic_streambuf<charT, traits>*sb)

  
  Previously, this constructor also initialized the bit indicating that output is right justified. Because the constructor is called while constructing any of the IOStream objects cout , clog , cerr , wcout , wclog , or wcerr , the difference is apparent if you examine the format control bits set after initializing one of these objects.
  Consider the following program:

  #include <stdlib.h> #include <iostream> using namespace std; int main() { cout << cout.flags() << endl; cout << clog.flags() << endl; cout << cerr.flags() << endl; cout << wcout.flags() << endl; cout << wclog.flags() << endl; cout << wcerr.flags() << endl; return EXIT_SUCCESS; }

  
  The output now indicates that only the skipws and dec format control bits are initialized. Previously it would have indicated that the right bit was also set.

• Some iterator classes removed
  The following classes no longer exist in the Standard and have been removed from library headers.

  reverse_bidirectional_iterator
  random_access_iterator
  bidirectional_iterator
  forward_iterator
  output_iterator
  input_iterator

  
  Use instead the template class iterator with the template argument category to indicate which type of iterator you are constructing.
• The default allocator argument changed for basic_string
  The default allocator argument for the class basic_string has been changed from allocator<void> to allocator<charT> . Any STL container constructed with an allocator<void> template argument no longer compiles, because the specialization of allocator<void> does not contain all the necessary typedefs.
• strstream now deletes underlying strstreambuf
  A problem has been corrected in the Standard Library strstream classes that prevented underlying strstreambuf (and thus the string) from being deleted when the strstream object was destroyed. The standard states that they should be deleted if strmode & allocated is true and strmode & frozen is not true.
  For example:

  #define __USE_STD_IOSTREAM #include <strstream> void func() { ostrstream myostr; myostr << "abc"; }

  
  If you called func() the string "abc" was never deleted when the myostr stream was destroyed. This problem has been corrected. Note that the Class Library strstream classes have always deleted the underlying string.

• sync_with_stdio() function is static
  In previous versions, the function sync_with_stdio() was incorrectly declared as a member function of ios_base . The function is now correctly defined as a static member function; it is no longer necessary to call it with the "->" or or "." notation.

This section describes problems you might encounter when using the current release of the C++ Standard Library with the Compaq C++ compiler. Where appropriate, workarounds are suggested.

• Do not use Standard Library template definition file names.
  The C++ Standard Library supplies the following template definition files in SYS$LIBRARY:CXXL$ANSI_DEF.TLB:
  

  algorithm.cc	fstream.cc	streambuf.cc	vector.cc	time.cc
  bitset.cc	ios.cc	locimpl.cc	string.cc	ctype.cc
  istream.cc	numbrw.cc	tree.cc	collate.cc	messages.cc
  complex.cc	iterator.cc	ostream.cc	valarray.cc	money.cc
  deque.cc	list.cc	sstream.cc	valimp.cc	numeral.cc
  rwlocale.cc

  
  If you use the same prefix name for any of your local files and have the directory that contains them in your include search path, the automatic instantiation mechanism picks up your local copy and does not find the library files. (See Automatic Template Instantiation in Using Compaq C++ for OpenVMS Alpha .)
  It is best not to use any of these names as source file names for your application.
• Redeclaration of Standard Library Functions
  Many of the prototypes in the Standard Library have been changed to conform to the C++ International Standard by the addition of exception specifications. This means that if you have redeclared the declarations in your own code, you need to add the correct exception specification in order to match what is declared in the header.
  For example:

  #include <new.h> // override default operator new // this will give an error inline void* operator new(size_t s);

  
  To prevent this behavior, you must change your new() declaration to:

  inline void* operator new(size_t s) throw(bad_alloc);

• Files/Macros for internal use only
  Compaq C++ Version 6.n ships the following non-Standard headers for Compaq internal use only. Their contents are subject to change and can not be relied on.

  <stdcomp>, <stl_macros>, <stddefs>, <compnent.hxx>, <stdmutex>, <stdexcept>, <lochelp>, <locimpl>, <locimpl.cc>, <valimp>, <valimp.cc>, <vendor>, <codecvt>, <codecvt.cc>, <collate>, <collate.cc>, <ctype>, <ctype.cc>, <locvector>, <math>, <messages>, <messages.cc>, <money>, <money.cc>, <numeral>, <numeral.cc>, <random>, <rwcats>, <rwlocale>, <rwlocale.cc>, <rwstderr>, <rwstderr_macros>, <string_ref>, <time>, <time.cc>, <traits>, <usefacet>

  
  In addition both Standard and non-Standard headers make use of macros beginning with _RW or __RW . These _RW * and __RW * macros are for Compaq internal use only. They are subject to change and can not be relied on.

• Pre-ANSI iterators no longer available
  The following classes are no longer in the ANSI draft standard and should not be used:

  input_iterator output_iterator forward_iterator bidirectional_iterator random_access_iterator

  
  The functionality of these classes is now provided by the single class iterator, which is templatized on the iterator category.

• ctype_base::graph
  In the current implementation of the ctype_base class, a character has a 'graph' property if and only if it also has an 'Alpha', a 'digit' or a 'punct' property. Thus, mathematical and scientific symbols and dingbats from the UNICODE character set will not be classified properly.
• IOStreams cannot output IEEE NaNs/Infinities
  The Standard IOStreams library does not support output for IEEE NaNs and Infinities.
• ios_base::out does not truncate a file to zero length
  The ios_base::openmode ios_base::out should open a file for output. This means that the file is either truncated to zero length if it exists or created for writing if it does not. Therefore ios_base::out is the same as ios_base::out | ios_base_trunc .
  With our sources, the following program behaves incorrectly.

  #include <stdlib.h> #include <iostream> #include <fstream> using namespace std; int main() { fstream fs ("t.in",ios_base::out); fs << "A"; return EXIT_SUCCESS; }

  
  Where t.in contains xyz.
  After running this program, t.in contains

  Ayz

  
  It should contain

  A

  
  You can work around this problem by replacing ios_base::out with ios_base::out | ios_base::trunc .

• Specifying a different l_double_size than the default size for your particular version of the operating system does not work correctly with the standard library.
• Input and output to and from long double types on when specifying /L_DOUBLE_SIZE=64 does not work if you use standard iostreams. This restriction will be lifted in a future release.
• Overriding operator new() or operator delete()
  You can define a global operator new() or operator delete() to displace the versions used by the C++ Standard Library or C++ Class Library. For instructions, see Overriding operator(new) in Using Compaq C++ for OpenVMS Alpha .
• The /template_define and /template_define=all options are not guaranteed to work with the Standard Library. Specify /template_define=used instead.
  When compiled with /template_define or /template_define=all , the following code generates compilation errors indicating that no operator "<" (and ">" or "+" or "-") matches these operands:

  #include <map> map<int,int> foo;

  
  The instantiation options are not guaranteed to work with the Standard Library because they request the compiler to instantiate all templates, even those that are not used.
  The /template_define=all option does not work because rb_tree , the underlying implementation of map and set supports a bidirectional iterator class. Thus, operator+ , operator- , operator< and operator> are not defined in the iterator for that class.
  When you instantiate the tree with cxx /template_define=all or cxx /template_define , the compiler attempts to instantiate recursively everything that is typedef ed, even if not used. Thus, the tree contains a typedef for std::reverse_iterator<iterator> , which then instantiates the global class reverse_iterator with the tree iterator as the template argument RandomAccessIterator , a misnomer in this case.
  This behavior generates undefined symbols for these operators because they are used within the definition of the operator member functions inside reverse_iterator . The compiler therefore attempts to instantiate them even though they do not exist.
  Specifying /template_define=used for the Standard Library directs the compiler to only instantiate those templates that are used.

• Description of the initial state of the stringstream Ctor
  There has been some controversy in the comp.lang.c++ reflector and within the standards committee on the semantics of the stringstream constructor. Consider the following example:

  #define __USE_STD_IOSTREAM #include <stdlib.h> #include <sstream> int main() { ostringstream ost("Hello, "); // ost.rdbuf()->pubseekoff(0,ios::end,ios::out); ost << "world!"; cout << ost.str() << endl; return EXIT_SUCCESS; }

  
  Depending on the setting of the streambuf put pointer after the initial construction, the program could print either "Hello, world!" or "world!". The Rogue Wave (and Compaq C++) interpretation is that the stringstream constructor does not change the initial position of the streambuf pointer, so that the program prints "world!".
  If you want to change the setting of the put pointer to match the other interpretation (that the pointer should move to the end of the initializer string), you must insert a call to pubseekoff() , as shown in the commented line.
  If the ANSI C++ committee issues a clarification on this matter Compaq C++ will implement their decision.

• basic_string ambiguities
  If you declare a basic_string of int you might encounter ambiguities in the constructors, append , assign , insert , and replace member functions. For example, if you write:

  #include <stdlib.h> #include <string> int main() { basic_string<int> si (5,0); return EXIT_SUCCESS; }

  
  Compilation errors result from the overload resolution between integral and iterator types. The constructors involved are the following:

  // construct n elements and initialize with value basic_string(size_type n, charT c, const Allocator& a = Allocator()); // construct using iterator ranges template<class InputIterator> basic_string(InputIterator begin, InputIterator end, const Allocator& a = Allocator());

  
  The compiler matches on the constructor basic_string(InputIterator begin, InputIterator end, ...) because size_type a size_t is an unsigned int on OpenVMS Alpha systems. So you have:

  basic_string(unsigned int, int, ...) vs. basic_string(int, int,...)

  
  The second constructor is the better match, but it is undesirable because we are not constructing via iterator ranges.
  The workaround is to avoid matching on iterator types by casting integral arguments. So for example, the previous program would compile correctly if the size argument were cast to a size_t :

  #include <stdlib.h> #include <string> int main() { basic_string<int> si ((size_t)5,0); return EXIT_SUCCESS; }

• Restartable/non-restartable conversion routines in Locale classes
  In codecvt class from localization library, the C++ standard assumes availability of restartable conversion routines such as mbrtowc , wcrtomb , and so forth.
  These routines. introduced by ISO C Amendment 1: C Integrity, were implemented in OpenVMS Alpha Version 6.2A and were never ported back to the previous version.
  Because restartable conversion routines are unavailable, the C++ Standard Library on OpenVMS Version 6.2 uses their non-restartable counterparts such as mbtowc , wctomb and so forth.
  Note that restartable versions of conversion routines are functional only when used with locales that support state-dependent codeset encoding. Currently, neither the OpenVMS Alpha nor the Tru64 UNIX operating system provides any locales based on a state-dependent codeset.
  With a codeset that is not state-dependent, both restartable and non-restartable conversion routines behave exactly the same. Therefore, using non-restartable conversion routines instead of restartable ones does not constitute any lack of functionality of C++ Standard Library on OpenVMS Version 6.2.
• cxxlink errors with heavily templatized applications
  When linking an application that uses many templates, cxxlink might report and error indicating that no I/O channels are available. For example:

  $ cxxlink test %LINK-F-OPENIN, error opening T4:[TEST.CXX_REPOSITORY]CXX$CTQ173DGTWRTRB0K 64LIR.OBJ;1 as input -RMS-F-CHN, assign channel system service request failed -SYSTEM-F-NOIOCHAN, no I/O channel available

  
  This error is generated when the process of linking all of an application's template instantiations requires more open files than the underlying system can support. In C++ Version 6.n, automatic template instantiation occurs at compile time (not link time as in previous versions. Automatic template instantiation files are therefore written into a repository as object files during compilation. Cxxlink then invokes the OpenVMS linker to link each instantiation file into the application.
  To work around this problem, you must allocate sufficient system resources to handle an extended number of open files. You might need to increase the SYSGEN parameter CHANNELCNT, which specifies the number of permanent I/O channels available to the system. You might also need to increase the following process quotas:

  open file quota ( fillm )
  buffered I/O quota ( biolm )
  page file quota ( pgflquo )
  enqueue quota ( enqlm )

• cxxlink might fail with many large template instantiations
  If you have many large template instantiations in your source file, the cxxlink command may fail with the following message:

  %LINK-F-OPENIN, error opening <some repository> as input -RMS-E-ACC, ACP file access failed -SYSTEM-F-EXBYTLM, exceeded byte count quota

  
  To work around this limit, you must increase your Buffered I/O byte count quota, which you can see by entering the command SHOW PROCESS/QUOTA. Ask your system administrator to use the Authorize utility to increase the size. The recommended value is 199296.

• C++ Class Library dependencies on the Standard Library
  As of Version 6.0, the Class Library has dependencies on the Standard Library. The dependencies have to do with incompatible name mangling changes made between Version 5.n and Version 6.0 to address Version 5.n name mangling problems. In all cases, entry points to the Version 6.0 mangled names are available in the Version 6.0 Standard Library. This means that all Version 6.0 programs (even those using only the Class Library) should be linked with the Standard Library either with cxxlink or by adding sys$library:libcxxstd.olb to your link command. Using cxxlink is recommended.
  The following specific dependencies require support from the Standard Library:
  • Class library routines that use an ios::seek_dir type input parameter:

    istream::seekg()
    ostream::seekp()
    streambuf::seekoff()
    filebuf::seekoff()
    strstreambuf::seekoff()
    stdiobuf::seekoff()

  • In Version 5.n, the mangled name for an enum nested in a class did not contain the class name. This was corrected in Version 6.0. Version 6.0 provides a switch ( /distinguish_nested_enums ) that allows you to compile programs amd generate either a Version 5.n or Version 6.0 style mangled name.
    Because support for the routines with Version 6.0 mangling resides in the Standard Library, Version 6.0 programs making use of the above routines compiled using /distinguish_nested_enums must link with the Standard Library either with cxxlink or by inclusion of sys$library:libcxxstd.olb on the link line.
  • Class Library inserter/extractor routines that accept __int64 type parameters.
    In Version 5.n, the mangled name for a routine accepting an __int64 parameter differed from the mangled name for a routine accepting a long long . This problem was corrected for Version 6.0 on OpenVMS. Because support for the routines with Version 6.0 mangling resides in the Standard Library, Version 6.0 programs making use of such routines in code like the following

    ifstream instream ("t.dat"); __int64 s_value unsigned __int64 u_value ... cout << u_value; instream >> s_value;

    
    must link with the Standard Library either with cxxlink or by inclusion of sys$library:libcxxstd.olb on the link line.

• Access violation when using Standard Library version of cout cin , and other standard streams inside static constructors
  If you are using the standard iostreams library (if you have defined the macro __USE_STD_IOSTREAM ) , and if you attempt to use cout , cin , cerr , clog , wcout , wcin , wcerr , or wclog in a static constructor, a core dump occurs.
  For example:

  #include <ostream> using namespace std; struct C { C(); }; C::C() { cout << "hello world"; // cout not initialized here } C c1; int main() {}

  
  To work around the problem, must modify your cxxlink step as follows:

  1. Create an options file, image_name.opt , whose content is SYS$SHARE:LIBCXXSTD/INCLUDE=CXXL_STD_INIT
  2. Modify your cxxlink command to be:

     $ CXXLINK/EXE=programname.exe image_name.opt/opt,[rest of command]

• Compilation warnings and errors with auto_ptr
  In ansi and arm mode, using the auto_ptr class can generate compilation warnings. In strict_ansi , using the class can generate compilation errors. For example:

  #include <stdlib.h> #include <memory> #include <iostream> class Base {}; class Derived: public Base {}; std::auto_ptr<Derived> f(); int main() { // warning in ansi mode, error in strict_ansi std::auto_ptr<Base> q = f(); return EXIT_SUCCESS; }

  
  Currently there is no consensus in the ANSI committee about whether these errors are caused by a bad design of the auto_ptr class or are compiler bugs. We hope to have a resolution soon. In the meantime, the workaround for ansi mode is to use a pragma or compiler option to disable the warning. In strict_ansi mode, uses might need to recode programs to store the value returned by f() in a temporary, and then use that temporary for copy construction and assignment to another auto_ptr .
  Remember that auto_ptr s should not be used as elements of an STL container, because they do not meet the CopyConstructible and Assignable requirements for Standard Library container elements.

The C++ Standard Library provided with this release defines a complete specification (with some differences as described in Section 2.3) of the C++ International Standard. The Standard Library in this release includes for the first time the ANSI locale and iostream libraries.

Tutorial programs illustrating functionality found in the standard C++ library including the locale , iostream , and STL classes shipped with this release can be found in:

SYS$SYSROOT:[SYSHLP.EXAMPLES.CXX]*.CXX

You can compile and run these programs and use them as models for your own coding. The expected output for each program can be found in:

SYS$SYSROOT:[SYSHLP.EXAMPLES.CXX]*.RES

Version 6.0 introduces the following major enhancements and changes. For detailed information about the Compaq C++ Standard Library, refer to Using Compaq C++ for OpenVMS Alpha.

• Support for C++ International Standard iostream and locale
  If you plan to use the standard iostream classes or the standard locale (internationalization) classes, The C++ Standard Library in Using Compaq C++ for OpenVMS Alpha provides more information than that available in The C++ Programming Language, 3rd Edition. The Version 6.0 kit also contains detailed documentation in PostScript and PDF formats:

  Standard Library Internationalization and Localization (PDF)
  Standard Library Internationalization and Localization (PS)
  Standard Library Stream Input/Output (PDF)
  Standard Library Stream Input/Output (PS)

• Several new options.
• pre-ANSI/ANSI iostreams compatibility.
• Support for ANSI/pre-ANSI operator new() .
• Support for global array new and delete .

Additional changes include the following:

• Specific changes to match the C++ International Standard
  • iterator_traits::distance_type now iterator_traits::difference_type
    The name of the typedef inside the classes iterator_traits and iterator that specifies the type of the result when two iterators are subtracted has been changed from distance_type to difference_type .
  • typedef name changes in iterator classes
    The names of some of the typedefs in the reverse_iterator and reverse_bidirectional_iterator classes have changed as follows:

    iter_type is now iterator_type
    reference_type is now reference
    pointer_type is now pointer
    distance_type is now difference_type

  • slice/gslice classes member function length() name change
    The member function length() in the slice and gslice classes has changed its name to size() .
  • has_denorm data member of the numeric_limits class changed
    The has_denorm data member of the numeric_limits class, <limits> , has been updated. has_denorm is changed from type bool to an enum type float_denorm_style to reflect that support for denormalized values might not be detectable at compile time. The float_denorm_style type looks like this:

    namespace std { enum float_denorm_style { denorm_indeterminate = -1; denorm_absent = 0; denorm_present = 1; }; }

    
    The values representing the presence or absence of denorms are as follows:

    denorm_indeterminate : cannot determine if type supports denormalized at compile time
    denorm_absent : the type does not support denormalized values
    denorm_present : the type supports denormalized values

  • Default allocator value for map and multimap has changed
    The default value for the template argument Allocator in map and multimap was changed from allocator<T> to allocator<pair<const Key, T> > .
  • Interface Change for STL distance() function
    Because the V6.0 compiler now supports partial specialization of class templates, the interface to the distance() algorithm has been updated to conform to the latest C++ standard. This means that previously, if you made a call to distance , the result was returned by using a reference argument for the third argument:

    // pre 6.0 the result was returned in d distance(first,last,d);

    
    Beginning with V6.0, the result is returned in the return type:

    d = distance(first,last); // 6.0

    
    You must therefore change all your calls to distance() .

• Support for long long and unsigned long long types.
  The non-ANSI standard types long long and unsigned long long are now supported in the Standard Library iostreams as well as being valid types for numeric_limits specializations and as types for which destroy() specializations are provided. For example, you can now say:

  long long l; cout << l << endl; // compiles without error

  
  Note that these types are not supported in the /standard=strict_ansi compiler mode.
  long long and unsigned long long are also supported in the iostream class library in the default compiler mode.

• Common Instantiation Libraries no longer needed
  Because Version 6.0 uses compile time rather than link time template instantiation, there is no use for common instantiation libraries and we have therefore not supplied any build_common_instantiation_library script. See the discussion of templates in Using Compaq C++ for OpenVMS Alpha .

Contents

privacy and legal statement