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

Compaq Computer Corporation
Houston, Texas

The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document.

The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license.

No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies.

Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.

©1992-1999 Digital Equipment Corporation

Compaq, the Compaq logo, and Alpha, DEC, DECthreads, DECwindows, OpenVMS, VAX, and VMS are registered in the U.S. Patent and Trademark Office.

PostScript is a trademark of Adobe Systems Incorporated.

UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Ltd.

Other product names mentioned herein may be the trademarks of their respective companies.

Contents

1 Introduction

This document contains the release notes for Compaq C++ Version 6.2 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.2 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.2 but will be supported in a future version:

• Overriding a virtual member function based only on a derived class return type.
• reinterpret_cast casting a pointer to member of one class to a pointer to member of another class if the classes are unrelated
• Name binding in templates in the style of N0288/93-0081
• Class name injection
• Putting a try/catch around the initializers and body of a constructor
• Templates as template parameters
• Koenig lookup of function names on all calls (see Sections 8.2.6 and 11.2.4 of The C++ Programming Language, 3rd Edition)
• Finding friend functions of the argument class types on name lookup on the function name in calls
• String literals do not have a const type
• Universal character set escapes (for example, uabcd)
• The export keyword for templates
• No cname version of headers provided
  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.

    <cname> // name.h includes types.h & brings it into std:: <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 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.2 kit and must be installed to debug programs compiled with Compaq C++ Version 6.2. 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 7.0, 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.

4.1 Enhancements and Changes in Version 6.2

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 an 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 the C++ Class Library Reference Manual and Class Library Restrictions 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-1999 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 in Version 6.2

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 iostreamand 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, you'd need to 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.

• 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 typedefed, 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 7.0 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 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_ptrs 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.

Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor.

© 1999 Digital Equipment Corporation.

Contents