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

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.

Copyright ©1999

The following are trademarks of Digital Equipment Corporation: Alpha, DEC, DEC FUSE, DECthreads, Ladebug, OpenVMS, ULTRIX, VAX, VAX DOCUMENT, VMS, and the DIGITAL logo. COMPAQ and the Compaq logo 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.

All other trademarks and registered trademarks are the property of their respective holders.

Contents

1 Introduction

This document contains the release notes for DIGITAL C++ Version 6.1 and Version 6.0 for OpenVMS Alpha. The DIGITAL C++ product requires OpenVMS Alpha Version 6.2 or higher.

The DIGITAL C++ media contains the following:

• The CXX060 kit, which includes the DIGITAL C++ compiler and associated files, such as the DIGITAL C++ Class Library and Standard Library header files.
• The ADX072 kit, which contains the OpenVMS Debugger. This debugger supports namespaces. You can refer to a namespace in the same way you refer to a class: namespace::name.

HTML files are provided for the release notes and some of the product manuals for use with a web browser. To view this documentation, open the following file using your web browser:

file:/sys$common/syshlp/cxx$help/cxx.html

2 Important Compatibility Information

Starting with Version 6.0, the DIGITAL C++ compiler differs significantly from previous versions. There are several major differences that you should be aware of before using a Version 6 compiler for the first time. These differences are summarized here and discussed in more detail in Section 6.6.

• Language differences
  Version 6.0 implements (with some differences, as described in Section 6.7), the C++ International Standard (IS), which differs significantly from the language specified in The Annotated C++ Reference Manual 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 Section 6.1.
• Diagnostic differences
  The Version 6.0 compiler does more error checking than Version 5.6 and generates more diagnostics. If you want the number of diagnostics issued by Version 6.0 to be more similar to Version 5.6, compile with the /quiet option. See Message Control and Information Options in Using DIGITAL C++ for OpenVMS Alpha.
• Implementation differences
  The automatic template instantiation model has been redesigned for the current version. While 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 with code compiled with Version 6.n. See Using Templates in Using DIGITAL C++ for OpenVMS Alpha.

These notes apply to DIGITAL C++ Version 6.1 for OpenVMS Alpha. For detailed directions on installing the kit, see the DIGITAL C++ Installation Guide for OpenVMS Alpha.

4 New Debugger

A new OpenVMS Debugger (kit ADX072, dated 9-Jan-1999) is provided with the Version 6.1 kit and must be installed to debug programs compiled with DIGITAL C++ Version 6.1. This deugger solves several problems with the previous version of the debugger.

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

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

See the DIGITAL C++ Installation Guide for OpenVMS Alpha for additional information.

If you install the debugger on a version of OpenVMS that does not have DECwindows Motif installed, or on a version of OpenVMS that has a version of DECwindows Motif prior to Version 1.2-4, the C++ debugger's GUI image will not be installed. If, at some later point, you decide to install Motif or upgrade Motif to Version 1.2-4 and you then want to use the debugger's GUI, you should re-install the C++ debugger, so as to create the debugger's GUI image.

After installing the debugger, you must invoke a command procedure to install the C++ debug images and define the default system debugger.

If you want the special C++ debugger to be the default debugger for the system, you should do the following, after installing the ADX072 kit:

• Invoke the command procedure as follows:

  @SYS$STARTUP:DEBUG$STARTUP_V72X.COM V72X

• Add the following line to the system startup procedure;

  $ @SYS$STARTUP:DEBUG$STARTUP_V72X.COM V72X

• On OpenVMS versions prior to V7.0, copy the following resource file:

  $ COPY DECW$SYSTEM_DEFAULTS:CXXVMSDEBUG.DAT - DECW$SYSTEM_DEFAULTS:VMSDEBUG.DAT

Note that DIGITAL C++ Version 6.0 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, you should do the following:

• Invoke the command procedure as follows:

  @SYS$STARTUP:DEBUG$STARTUP.COM VMS

• Add the following line to the system startup procedure;

  $ @SYS$STARTUP:DEBUG$STARTUP.COM VMS

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

Changes and enchancements are as follows:

• Improved EV6 support
• Previous compiler versions displayed line feed characters in listing files. You can now specify the /preprocessor_only qualifier to replace these characters with spaces before lexical processing.

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 6.7), including the C++ Standard Library. See Section 10 for information on and changes to the Standard Library.
• An updated debugger (dated 9-Jan-1999) that fixes problems with the previous version of the debuhger.
• Language mode and diagnostic message options increase compatibility with earlier versions. See Section 6.1 and Message Control and Information Options in Using DIGITAL C++ for OpenVMS Alpha.
• 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.
• Improved automatic instantiation of templates, including:
  • Fewer restrictions. In particular, DIGITAL 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 complete information, refer to Using DIGITAL C++ for OpenVMS Alpha.
• New command options, which are described in the following sections.

Section 6.6 discusses compatibility issues that you might encounter in using the compiler if you have used Version 5.n in the past.

6.1 Language Mode Options

Starting with Version 6.0, DIGITAL C++ supports the C++ International Standard. DIGITAL C++ releases prior to Version 6.0 implemented the ARM (The Annotated C++ Reference Manual, 1991, by Ellis and Stroustrup) with some ANSI C++ extensions. The international standard differs in significant ways from the language implemented by DEC C+ Version 5.n.

The default language mode for Version 6.0 is ANSI, and many programs developed using Version 5.n require modifications before they can be compiled in the default ANSI mode. 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 DIGITAL C++ Implementation in Using DIGITAL C++ for OpenVMS Alpha.

6.2 Standard Library Options

The compiler provides various Standard Library options. For information about the DIGITAL C++ Standard Library, see The DIGITAL C++ Standard Library in Using DIGITAL C++ for OpenVMS Alpha.

6.3 Template Options

Version 6.0 provides new options for templates. For detailed information about templates, see Using Templates in Using DIGITAL C++ for OpenVMS Alpha.

6.4 Language Feature Options

The compiler now supports the following options:

• Use of alternative tokens (see Alternative Tokens in Using DIGITAL C++ for OpenVMS Alpha).
• Run-Time type identification (see Run-Time Type Identification in Using DIGITAL C++ for OpenVMS Alpha).

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 DIGITAL C++ for OpenVMS Alpha.

6.6 Compatibility With Previous Versions

This section provides details about differences between the current and previous compiler versions:

• Language differences
• Implementation differences
• Library differences

Users should be aware of the following language differences between the current and previous versions of the compiler:

• The most important language differences result from the current implementation of the C++ International Standard in Version 6.0. If you want to compile existing source code with minimal source changes, compile using the /standard=arm option. See Section 6.1.
• Because the current compiler performs more error checking than previous versions, it generates significantly more diagnostic messages. However, you can use the /quiet option to relax error checking and reduce the severity of many diagnostics. Message Control and Information Options in Using DIGITAL C++ for OpenVMS Alpha.
• The following keywords, introduced with the C++ International Standard, are always reserved keywords in all compiler modes:

  bool, const_cast, explicit, export, false, mutable, dynamic_cast, reinterpret_cast, static_cast, true, typeid, typename, wchar_t

  
  Alternative representation keywords are as follows:

  and, and_eq, bitand, bitor, compl, not, not_eq, or, or_eq, xor, xor_eq

• Taking the address of a bit field is not allowed in the current version.
• Creation of temporaries and their lifetimes vary among compiler modes.
• Macro expansion in pragmas can give different results in the current and previous versions.
• The following are distinct types in the current version; they were the same type in previous versions:

  typedef void (*PF)(); // Pointer to an extern "C++" function extern "C" typedef void (*PCF)(); // Pointer to an extern "C" function void f(PF); void f(PCF);

• The current version does not allow converting a pointer to member from a derived class to a virtual base class.
• Calling a nonstatic member function through a null pointer is undefined behavior. Certain cases that used to run without errors in previous versions no longer run in the current version. For example:

  #include <iostream.h> struct A { int a; }; struct D : public virtual A { A* toA(){ return (A*) this; } }; main () { D* d = NULL; A* ad = d->toA(); // will ACCVIO if (ad==NULL) cout << "ok"; }

• In the current version, bool is a built in type. In previous versions, it is user defined, typically as int in system header files. Mangling differs in this respect only for functions that have arguments of type bool.
  In the current version, the size of bool is 1. In previous versions, bool is user defined, typically as int with a size of 4.
  In the current version, the size of a boolean expression ( sizeof(a && b) ) is 1. In previous versions, the size is 4, independent of the size of bool.
• The current version does not cause pragmas to become effective within function bodies when scanning template definitions.
• The current version does not allow the "virtual" storage class modifier to be used with member function definitions outside a class.
• The current version does not allow typedef void Z::* any_ptom;.

Users should be aware of the following implementation differences between the current and previous versions of the compiler:

• The automatic template instantiation model has been redesigned for the current version. See Using DIGITAL C++ for OpenVMS Alpha for details.
• The current version drops qualifiers on parameters when determining the function type, as dictated by the C++ International Standard. For instance, in the following example, the function declarations are the same function.

  f(const int p1); f(int p1);

  
  For compatibility with previous versions, if qualifiers are included in function declarations, they are also included in the mangled name.

• The current and previous versions differ in interpreting undefined behavior, as when incrementing takes effect in this example:

  f(i++, i++);

• The current version cannot handle a #pragma define_template that spans multiple lines without the backslash ( \ ) delimiter. Version 5.6 can handle this without problems.
• The current version displays #line number in /preprocess_only output. The previous version displays #number.
• After encountering an illegal multibyte character sequence, the current version issues a warning diagnostic and continues processing. The previous version issues an error and stops processing.
• The current compiler does not support VAX C module include syntax (for example, #include acms$submitter without <> or " " delimiters). The compiler searches text libraries for modules included using the normal include syntax (specifying the " " or <> delimiters) and correctly (according to the C++ standard) rejects #include directives that do not follow this syntax.

Aspects of memory allocation and deallocation have changed. See the description of /[no]stdnew and /[no]global_array_new in The DIGITAL C++ Standard Library in Using DIGITAL C++ for OpenVMS Alpha.

6.7 Language Differences Between the C++ International Standard and DIGITAL C++

The following items, specified in the C++ International Standard, are not supported in Version 6.0 but will be supported in a future version:

• Enums larger than can be contained in an int
• reinterpret_cast casting a pointer to member of one class to a pointer to member of another class if the classes are unrelated
• Two-phase name binding in templates, as described in [temp.res] and [temp.dep] of the C++ International Standard, is not implemented.
• Evaluation of f in a reference of the form f()->g(), with g as a static member
• Class name injection
• Putting a try/catch around the initializers and body of a constructor
• Templates as template parameters, as shown in the following example:

  template <class T, template <class> class C> class Xrefd { // not yet allowed C<T> mems; C<T*> refs; };

• explicit qualification of function templates; for example:

  template <class T> T f(); // T not used in argument list void main() { f<int>(); }

  
  This behavior causes some function signatures for the Standard Library, such as use_facet<>, to be non-standard conforming.

• 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

The following general restrictions apply for Version 6.0:

• Version 6.0 is not totally compatible with previous versions, and source changes might be required to use this version. See Section 6.1 and Message Control and Information Options in Using DIGITAL C++ for OpenVMS Alpha.
• 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.
• Comma lists for cxx command line parameters are not yet fully supported and can cause the compiler to ACCVIO.
• 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.
• If a C++ function is called from a program where the main function is not C++, terminate is not called. The call stack points to the point of the throw instead.
• When using /extern_model=relaxed_refdef (the default) or /extern_model=common, the C++ compiler describes each global variable in the VMS Object language as using a unique Program Section (PSECT). The name of the program section is the same as the name of the variable, but it is subject to type encoding and shortening. However, because the compiler must use several PSECTs with fixed names to encode other aspects of the compiled program, these fixed-name PSECTs are not available to users when these EXTERN_MODEL values are in effect. All the names are prefixed and suffixed with a dollar sign ( $ ) character, which generally identifies global names reserved to OpenVMS system usage. The following fixed name PSECTs not available as user variables with /extern_model=relaxed_refdef or /extern_model=common:

  $ABS$, $BSS$, $CODE$, CXX$$RTTI, $DATA$, $LINK$, $LITERAL$, $READONLY$, $TLS$

• The /template_define (or /template_define=all) qualifier is not guaranteed to work with the Standard Library. Specify /template_define=used instead.
  When compiled with /template_define or /template_define=all, the following generates compilation errors indicating that no operator "<" (and ">" or "+" or "-") matches these operands.

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

  These template 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 qualifier 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 <sstream> void main() { ostringstream ost("Hello, "); // ost.rdbuf()->pubseekoff(0,ios::end,ios::out); ost << "world!"; cout << ost.str() << endl; }

  
  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 DIGITAL 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 DIGITAL C++ will implement their decision.

• Debugging support for C++ references is incomplete.
  The debugger enters an infinite loop when attempting to examine some structures that contain references. For example, the debugger cannot examine
  • A structure that contains a reference to itself:

    struct A { A &x; A(); } a; A::A() : x(a) {} int main () { return 0; }

  • A structure that contains a reference to a second structure that contains either a reference to the original structure or the original structure itself:

    struct B; struct A { B &x; A(); }a; struct B { A y; // or A &y B(); }b; A::A() : x(b) {} B::B() : y(a) {} int main () { return 0; }

• OpenVMS Version 6.2 multithread programs might need linker file options to execute a C++ program intended to run in a multithreaded environment and might generate a DECthreads bugcheck like the following:

  % DECthreads bugcheck (version T2.12-296), terminating execution. % Running on OpenVMS AXP [OpenVMS V6.2; AlphaStation 400 4/233, 1 cpu, 128Mb] % Reason: Activation of DECthreads attempted after creating TIS mutexes. % See 'cma_dump.log' for state information. %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address= 00000008 ...

  
  The reason for this bugcheck is that DECthreads requires programs to set their final reentrancy level prior to creating thread objects. However, the Digital C++ Standard Library currently creates thread objects during its initialization, before completing processing of the /REENTRANCY qualifier, which sets the final reentrancy level. Working around this problem requires that the MULTITHREAD reentrancy level be made known to DECthreads prior to initialization of the library.
  There are two ways for an application program to set the reentrancy level to MULTITHREAD, which would require this workaround on OpenVMS Alpha Version 6.2 systems:

  1. Raising the reentrancy level using the compiler qualifier /REENTRANCY=MULTITHREAD
  2. Calling the decc$set_reentrancy routine directly in a program:

     #include <reentrancy.h> void main() {decc$set_reentrancy(C$C_MULTITHREAD);}

  
  The workaround is to set the REENTRANCY level to MULTITHREAD by explicitly linking against the shareable image CMA$RTL.EXE. This method allows the reentrancy level to be set early enough in the process to avoid the bugcheck. Adding CMA$RTL.EXE to your link command can be done either directly on the command line:

  $ CXXLINK PROG,SYS$INPUT/OPT SYS$SHARE:CMA$RTL.EXE/SHARE

  
  or via an options file:

  $ CREATE RTL.OPT SYS$SHARE:CMA$RTL.EXE/SHARE ^Z $ CXXLINK PROG, RTL/OPT

  
  This workaround has no adverse effects on application performance, because the DECthreads routines link dynamically against this same shareable image upon recognizing that the MULTITHREAD reentrancy level is required.

• Strict ANSI compilations must protect against dollar signs from macro expansions in C Library headers
  The Standard C Library headers contain macros whose underlying definitions contain a dollar sign. This practice follows standard OpenVMS naming conventions. Therefore, when compiling in strict ANSI mode, if you use a macro from a C Library header whose expansion contains a dollar sign, the compiler issues a %CXX-W-DOLLARUSEDID message.
  There are two workarounds:
  • You can add a pragma in your code to disable the message. For example, the following program, when compiled in a strict ANSI mode, generates the %CXX-W-DOLLARUSEDID message.

    #include <stdio.h> void foo(void){ FILE *x = stdout; }

    
    You can disable the message as follows:

    #include <stdio.h> #if defined(__STD_STRICT_ANSI) #pragma message disable dollarusedid #endif void foo(void){ FILE *x = stdout; }

  • If you prefer not to change your code, you can disable the message on the command line as follows:

    cxx/standard=strict_ansi/warning=disable=dollarusedid

Partitioning a large application into several shared libraries, which are then linked into an executable, is a useful technique for reducing link times during development. See the discussion about How to Organize Your C++ Code in Using DIGITAL C++ for OpenVMS Alpha for details.

9 Release Notes for the DIGITAL C++ Class Library

This section describes the problems fixed, known problems, and restrictions for the DIGITAL C++ Class Library. See Section 10 for information on the C++ Standard Library. Please note that String Package, which is part of the DIGITAL C++ Class Library, is entirely different from the String class that is part of the newly-implemented C++ Standard Library and known as the String Library. Do not confuse these two contrasting implementations.

9.1 Restrictions

The following restrictions apply for Version 6.0:

• 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.
• No Class Library support for 128-bit long doubles
  The Class Library does not include support for 128-bit long doubles.
• Conflict with redefinition of clear()
  If your program includes both <curses.h> and <iostream.hxx>, DIGITAL C++ might fail to compile your program because clear() is defined by both header files. In <curses.h>, clear() is defined as a macro whereas in <iostream.hxx> clear() is defined as a member function.
  Workarounds:
  If your program does not use either clear() or uses the <curses.h> clear(), include the <iostream.hxx> header first, followed by <curses.h>.
  If your program uses the ios::clear() function, undefine the clear() macro directly after the #include <curses.h> statement.

This section describes the enhancements, problems fixed, known problems, and restrictions for the C++ Standard Library. See Section 9 for information on the DIGITAL C++ Class Library. Please note that the current version of DIGITAL C++ implements the new standard string class, known as the String Library. Do not confuse this with the String Package, which is part of the DIGITAL C++ Class Library implemented in earlier versions of DIGITAL C++.

Note that portions of the ANSI C++ Standard Library have been implemented in DIGITAL 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 DIGITAL 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.

10.1 Enhancements and Changes in Version 6.0

The C++ Standard Library provided with this release defines a complete specification (with some differences as described in Section 6.7) 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, on the DIGITAL C++ Standard Library, refer to Using DIGITAL C++ for OpenVMS Alpha.

• Support for standard iostream and locale
  If you plan to use the standard iostream classes or the standard locale (internationalization) classes, The DIGITAL C++ Standard Library in Using DIGITAL 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 (see Section 6.2).
• 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
  1. 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.
  2. 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
  3. slice/gslice classes member function length() name change
     The member function length() in the slice and gslice classes has changed its name to size().
  4. 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
  5. 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> >.
  6. 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:

     distance(first,last,d); // pre 6.0 the result was returned in 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 DIGITAL C++ for OpenVMS Alpha.

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

• Do Not Use Standard Library Template Definition File Names
  The standard library supplies the following template definition files in SYS$LIBRARY:CXXL$ANSI_DEF.TLB:

  algorithm.cc	fstream.cc	locale.cc	streambuf.cc	vector.cc
  bitset.cc	ios.cc	locimpl.cc	string.cc
  byname.cc	istream.cc	numbrw.cc	tree.cc
  complex.cc	iterator.cc	ostream.cc	valarray.cc
  deque.cc	list.cc	sstream.cc	valimp.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 Using DIGITAL C++ for OpenVMS Alpha for more information on how the prelinker finds template definition files.)
  We suggest that you not 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 inline void* operator new(size_t s); // this will give an error

  
  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
  DIGITAL C++ Version 6.0 ships the following non-Standard headers which are for 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>

  
  In addition both Standard and non-Standard headers make use of macros beginning with _RW or __RW. These _RW* and __RW* macros are for 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 <iostream> #include <fstream> using namespace std; int main() { fstream fs ("t.in",ios_base::out); fs << "A"; return 0; }

  
  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.

• ios_base::in creates a file when it should not.
  ios_base::openmode ios_base::in should open a file for input. This means that if the file does not exist, it is not created.
  With our sources, the following program behaves incorrectly.

  #include <iostream> #include <fstream> int main() { fstream fs ("t.in",ios_base::in); return 0; }

  
  If t.in does not exist and this program is run, then t.in should not be created. Because of a bug, it is created in our ANSI library.

• Overriding operator new() or operator delete()
  To define a global operator new() or a global operator delete() to replace uses of global ::new or global ::delete in a user-compiled module, compile your program as follows:

  CXX/PREFIX=EXCEPT=(__nw__xui,__dl__xpv)

  
  The ability to override the library version of global operator new() and global operator delete() is available with OpenVMS V6.2 and later.
  If you want to define your own version of global operator new() on OpenVMS, you must define your own version of global operator delete() and vice versa. To define a global operator new() or a global operator delete() to replace the version used by the C++ Standard Library or the C++ Class Library, or both, follow these steps:

  1. Define a module to contain two entry points for your version of global operator new(). You must code the module so that it is always compiled either with the /stdnew or with the /nostdnew qualifier.
  2. If you code your module to compile with /stdnew, follow instructions in the next subsection. If you code your module to compile with /nostdnew, follow instructions in the subsection "Compiling with /nostdnew".

  Compiling with /stdnew
  

  1. Verify that your module contains two entry points for your version of global operator new(). One entry point, which has the name __nw__XUi, is used to override global operator new() in the Class Library. The other entry point, which has the name new, is used to override global operator new() in the Standard Library.
  2. Define global operator new() in terms of the entry point new. Code __nw__XUi to call operator new. Your module appears as follows:

     #include <new> ... using namespace std; // redefine global operator new(), // entry point into C++ Standard Library based on compiling /stdnew void *operator new(size_t size) throw(std::bad_alloc) { printf("in my global new\n"); ... void *p = malloc(size); return(p); } // redefine global operator delete() void operator delete(void *ptr) { free (ptr); } // entry point into C++ Class Library extern "C" void *__nw__XUi(size_t size) { printf("in my new\n"); return ::operator new(size); }

  Compiling with /nostdnew
  

  1. Verify that your module contains two entry points for your version of global operator new(). One entry point, which has the name __stdnw__XUi, is used to override global operator new() in the Standard Library. The other entry point, which has the name new, is used to override global operator new() in the Class Library.
  2. Define global operator new() in terms of the entry point new. Code __stdnw__XUi to call operator new. Your module appears as follows:

     #include <new> ... using namespace std; // redefine global <code_example>(operator new()), // entry point into C++ Class Library based on compiling /nostdnew void *operator new(size_t size) { printf("in my global new\n"); ... void *p = malloc(size); return(p); } // redefine global operator delete() void operator delete(void *ptr) { free (ptr); } // entry point into C++ Standard Library extern "C" void *__stdnw__XUi(size_t size) { return ::operator new(size); }

  3. Link your program using the /nosysshr qualifier of the LINK command. You must also link with a linker options file that includes the shareable images your program requires. (This is because some pieces of OpenVMS ship only in shareable form.) The file contains at least the shareable images shown below. The options file cannot contain, DECC$SHR, because it contains the definitions of new() and delete() that you are attempting to override. So your LINK command will be similar to the following:

     $ CXXLINK TEST,SYS$LIBRARY:STARLET.OLB/INCLUDE=CXXL_INIT, - SYS$DISK:[]AVMS_NOSYSSHR.OPT/OPT/NOSYSSHR

     
     where AVMS_NOSYSSHR.OPT is:

     SYS$SHARE:CMA$TIS_SHR/SHARE SYS$SHARE:LIBRTL/SHARE

     
     Linking /nosysshr is the only way to override calls to new() and delete() in the C++ Class Library and C++ Standard Library.

• 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 <string> int main() { basic_string<int> si (5,0); return 0; }

  
  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. 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 <string> int main() { basic_string<int> si ((size_t)5,0); return 0; }

• 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 Version 7.0 and were never ported back to the previous version.
  Because restartable conversion routines are unavailable, the C++ standard library on OpenVMS V6.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 OpenVMS the DIGITAL UNIX 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 V6.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 DIGITAL C++ Version 6.0, 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 file name> 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; void 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]

This section describes how developers who need to redistribute Run-Time Library components to user system are required to do so. The DIGITAL C++ Version 6.0 kit contains two Run-Time Library components that you might need to redistribute:

• DIGITAL C++ Standard Library Object Library (LIBCXXSTD)
• DEC C Run-Time Object Library (DECC$CRTL.OLB)

Redistribution of other components on the DIGITAL C++ Version 6.0 is prohibited. The redistribution rights set forth in the Software Product Description do not apply to the DECC$CRTL.EXE or DECC$CRTL.README files which are distributed with this kit.

11.1 Redistribution of the DECC$CRTL.OLB Object Library

Redistribution of this library is only required by those applications which need to be linked during or after installation on an end user target system. If you link your application and ship either a shareable or executable image to your customers, then redistribution of the object library is not necessary. The linking process of your application causes those library modules to be incorporated into your resultant image.

There are two options that you can be used to redistribute the DECC$CRTL.OLB object library. The options are based on whether the library is needed after the installation is completed.

The first option is for applications which link during installation, but have no need for the object library once installation is completed. For that set of developers, we recommend placing DECC$CRTL.OLB on your kit, but to link using the copy in VMI$KWD and not issue a PROVIDE_FILE option which would move this file onto the system. In other words, the object library resides only on your kit, is used during installation to link your application, but is not placed onto the end user system.

The second option is for applications which do need the object library after installation is completed. For this class of applications, the object library should be placed in a product specific location on the target system and not in SYS$LIBRARY. The contents of this object library must not be inserted into the SYS$LIBRARY:STARLET.OLB library.

11.2 Redistribution of the LIBCXXSTD.OLB Object Library

Redistribution of this library is only required by those applications which need to be linked during or after installation on an end user target system. If you link your application and ship either a shareable or executable image to your customers, then redistribution of the object library is not necessary. The linking process of your application causes those library modules to be incorporated into your resultant image.

There are two options that you can be used to redistribute the LIBCXXSTD.OLB object library. The options are based on whether the library is needed after the installation is completed.

The first option is for applications which link during installation, but have no need for the object library once installation is completed. For that set of developers, we recommend placing LIBCXXSTD.OLB on your kit, but to link using the copy in VMI$KWD and not issue a PROVIDE_FILE option which would move this file onto the system. In other words, the object library resides only on your kit, is used during installation to link your application, but is not placed onto the end user system.

The second option is for applications which do need the object library after installation is completed. For this class of applications, the object library should be placed in a product specific location on the target system and not in SYS$LIBRARY. The contents of this object library must not be inserted into the SYS$LIBRARY:STARLET.OLB library.

12 About This Product

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.

©Digital Equipment Corporation 1999. All Rights Reserved.

Contents