United States    
COMPAQ
C++
Compaq C++ Version 5.6C

Compaq C++ Version 5.6C

Release Notes for OpenVMS VAX Systems

December, 1999

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

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 5.6C for OpenVMS VAX Systems and for several previous versions of the compiler.

The compiler requires OpenVMS VAX Version 5.5 or higher. If you are installing on an OpenVMS VAX system older than Version 6.1, please read Section 3.3.

The Compaq C++ distribution contains three kits:

2 Important Compatibility Information

3 Installation Notes

These notes apply to Compaq C++ Version 5.6C for OpenVMS VAX. For detailed directions on installing the kit, see the Compaq C++ Installation Guide for OpenVMS VAX Systems.

3.1 Changes with Version 5.3

This section describes changes made to the installation procedure with Version 5.3:

3.2 Upgrading OpenVMS VAX

3.3 C/C++ Run-Time Components

Read this section only if you are installing the compiler on OpenVMS VAX systems older than Version 6.1. The Run-Time Components include image files and libraries for the C Run-Time Library identical to the binaries provided with Version 6.0 of OpenVMS for VAX. For installation and usage information, see the Compaq C/C++ for OpenVMS VAX Run-Time Components Reference and Installation Manual in the AACRTnnn kit's documentation directory.

4 Compiler Release Notes

This is Version 5.6C of the Compaq C++ compiler.

4.1 Enhancements and Changes in Version 5.6C

Changes and enhancements are as follows:

4.2 Enhancements and Changes in Version 5.6

This section briefly summarizes changes and enhancements that were made in Version 5.6.

4.3 Enhancements and Changes in Version 5.5

This section briefly summarizes changes and enhancements that were made in Version 5.5.

4.4 Enhancements and Changes in Version 5.4

This section briefly summarizes changes and enhancements that were made in Version 5.4.

4.5 Enhancements and Changes in Version 5.3

This section briefly summarizes changes and enhancements that were made in Version 5.3. See Using Compaq C++ for OpenVMS Systems for details and additional information.

4.6 Problems Fixed in Version 5.6

The following problems have been fixed in Version 5.6:

4.7 Problems Fixed in Version 5.5

The following problems have been fixed in Version 5.5:

4.8 Problems Fixed in Version 5.4

The following problems have been fixed in Version 5.4:

4.9 Problems Fixed in Version 5.3

The following problems have been fixed in Version 5.3:

4.10 Current Restrictions

This section contains usage notes and known problems with C++ Version 5.6.

4.11 Other Restrictions

This section describes problems, of interest to C++ users, that Compaq has no current plans to fix. Where feasible, a way to work around the problem is provided.

5 Creating an OpenVMS Shareable Image from C++ Source Code

This section describes how to to create a shareable image on an OpenVMS System. Before attempting this, you should review the section in the OpenVMS Linker Utility manual that describes shareable images.

The steps described here are not intended to cover all of the details of creating shareable images; they are instead intended to address the unique problems related to performing this task for C++ code.

This section cites examples of code supplied with the compiler kit. You will find the sources in SYS$COMMON:[SYSHLP.EXAMPLES.CXX]. Table 1 gives a short description of each of the files.

5.1 Determining Which Names to Export

The set of header files that contain class definitions for your product determine what routines and data need to be be exported by your shareable image. Any member function or data declared as public in a class will need to be exported; the only exceptions to this rule are inline functions whose code exists within the header file itself.

C++ encodes type information in function and data names, it is these encoded names that need to be exported, not the function name that appears in the code. For example: 


class test { 
public: 
   void  show_it(); 
   void  show_it(int); 
};

In this example, the function show_it() generates the encoded name SHOW_IT__4TESTXV . Similarly, the function show_it(int) generates the name SHOW_IT__4TESTXI .

5.2 Generating Symbols

Generating a list of symbols that must be exported is the single most complicated part of creating a shareable image that supports a C++ code base. The procedure involves several steps requiring human intervention and a knowledge of the interface into the product.

Compaq strongly recommends that the __extern_prefix compiler directive be used to avoid name conflicts with other software packages that may exist on the system. When using this directive, it is easy to identify all global objects using a LIBRARY/LIST/NAMES command.

The following steps assume that the code makes use of the __extern_prefix directive.

5.2.1 OpenVMS Alpha

  1. Create an object library and put all object modules that will be part of the shareable image into the library by issuing the following command: 


    $ LIBRARY/CREATE sw.olb SW.OBJ,SW_VEC_ALPHA.OBJ

  2. Create a list of global names from the object library by executing the following command: 


    $ LIBRARY/LIST=sw_shr_alpha.opt/NAMES sw.olb

  3. Process the SW_SHR_ALPHA.OPT file as follows:
    1. Remove any extra lines that are not global names and change the remaining lines so they look as follows: 


      SYMBOL_VECTOR=(SW_G_SW                 = PROCEDURE) 
SYMBOL_VECTOR=(SW_REAL__9STOPWATCHXV    = PROCEDURE) 
SYMBOL_VECTOR=(SW_RESET__9STOPWATCHXV   = PROCEDURE)

    2. Include only names you know you want to export.
      If you are exporting a class instance, and you are using the macros similar to the ones provided in the example code, the LIBRARY/LIST/NAMES listing will contain both the global pointer from the macro source and the _DATA version from the C++ source. For example: 


      Module SW 
SW_G_SW_DATA 
[...] 
 
Module SW_SHR_DATA 
SW_G_SW

      Only the global pointer from the macro source should be included in the symbol vector ( SW_G_SW ), not SW_G_SW_DATA .

  4. Test link using the options file as follows: 


    $ LINK/SHARE/EXE=SW_SHR.EXE - 
        SW.OBJ,SW_VEC_ALPHA.OBJ, - 
        SW_SHR_ALPHA.OPT/opt

  5. Process the link errors (if any). This may be an iterative process: expect to see several warnings in the following form: 


    %LINK-W-SYMVABNORMAL, Symbol SW_G_SW 
        defined in module SW as DATA 
        was declared in options as PROCEDURE

    Re-edit the linker options file and change the SYMBOL_VECTOR line from PROCEDURE to DATA . For example: 


    SYMBOL_VECTOR=(SW_G_SW = PROCEDURE)

    becomes: 


    SYMBOL_VECTOR=(SW_G_SW = DATA)

    Try the link command again.

  6. Continue the process until the linker reports no more errors.

5.2.2 OpenVMS VAX Following OpenVMS Alpha

If you are creating both an OpenVMS VAX and an OpenVMS Alpha shareable image, perform the OpenVMS Alpha procedure first. The OpenVMA Alpha Linker Utility provides better warnings to help avoid confusing data and procedure external data.

The steps to go from an OpenVMS Alpha linker options file to an OpenVMS VAX transfer vector macro file are as follows:

  1. Copy the OpenVMS Alpha linker options file to create a macro source file as follows: 


    $ COPY SW_SHR_ALPHA.OPT SW_VEC_VAX.MAR

  2. Remove all non SYMBOL_VECTOR lines from the file.
  3. Assuming the use of macros similar to the ones found in the SW_DEFS.MAR file, modify each SYMBOL_VECTOR lines as follows (actual names have been shortened):
    OpenVMS Alpha OpenVMS VAX
    SYMBOL_VECTOR=(9STWATCHXV= PROCEDURE) $CALL 9STWATCHXV
    SYMBOL_VECTOR=(G_SW = DATA) $GSYM G_SW SW_DATA
  4. See the comments below on adding $FUTURE to reserve space in the symbol vector.
  5. Continue with the steps below on compiling, linking and testing the shareable image.

5.2.3 OpenVMS VAX
  1. Create an object library and put all object modules that will be part of the shareable image into the library by issuing the following command: 


    $ LIBRARY/CREATE sw.olb SW.OBJ

    A macro source file will be added to the code base later.

  2. Create a list of global names from the object library by executing the following command: 


    $ LIBRARY/LIST=sw_vec_vax.mar/NAMES sw.olb

  3. Process the SW_VEC_VAX.MAR file as follows:
    1. Remove any extra lines that are not global names.
      Take each symbol listed and place it on a separate line. Thus: 


      Module SW 
SW_G_SW_DATA SW_REAL__9STOPWATCHXV SW_RESET__9STOPWATCHXV SW_START__9STOPWATCHXV

      Becomes: 


      SW_G_SW_DATA 
SW_REAL__9STOPWATCHXV            
SW_RESET__9STOPWATCHXV           
SW_START__9STOPWATCHXV

    2. Using macros similar to the SW_DEFS.MAR example code, change each line depending on its data type. For example:
      Routines:
      Change: To:
      SW_REAL__9STOPWATCHXV $CALL SW_REAL__9STOPWATCHXV

      Data:
      Change: To:
      SW_G_SW_DATA $GSYMSW_G_SW SW_G_SW_DATA

      If you are exporting a class instance, and you are using the macros similar to the ones provided in the example code, the LIBRARY/LIST/NAMES of the SW.OBJ will list the _DATA version of your class instance. The MACRO code will create a pointer to this _DATA version.
    3. Because OpenVMS VAX shareable images create a static transfer entry table in the shareable image, the best course of action is to extend the size of the transfer vector with spare space that can be used for future entry points without having to break upward compatibility. The SW_VEC_VAX.MAR example shows how to use the $FUTURE macro to reserve some space in the transfer vector.
  4. Compile the macro source: 


    $ LIBRARY/CREATE/MACRO SW_DEFS.MLB SW_DEFS.MAR 
$ MACRO SW_VEC_VAX+SW_DEFS/LIB

  5. Test link as follows: 


    $ LINK /SHARE/EXE=SW_SHR.EXE - 
        SW.OBJ,SW_VEC_VAX.OBJ, - 
        SW_SHR_VAX.OPT/OPT

  6. Process any link errors and review the above steps if necessary.
  7. Continue the process until the linker reports no more errors.

5.3 Verification

If you wish to verify the encoded names (and what they actually reference) you can use the CXXDEMANGLE utility to view the translation.

5.4 Testing the Results

Once done, you should be able to link and run the test program using the shareable image as follows: 


$ DEFINE SW_SHR SYS$DISK:[]SW_SHR.EXE 
$ LINK SW_TEST,SYS$INPUT:/opt 
Sw_Shr/Share <ctrl/z> 
$ RUN SW_TEST

The results should be the same as the test being linked against the object modules used to create the shareable image.

If the test output differs or if the link fails, review the steps used to create the entry points.

5.5 Additional Topics

The sections below describe some common topics that relate to OpenVMS Shareable images and C++. They are provided to help C++ users on OpenVMS systems better understand the extra steps required in creation of a shareable image that provides a C++ interface.

5.5.1 Testing

A test that accesses all entry points should be written. The test needs to be verified by hand to make sure it accesses each public class member function (non-inlined) or public data item. Although inline functions are not exported, the test should be verbose enough to include a call to each and every method within a class.

The test should first be linked against the same set of objects that were used to create the shareable image. It should then be relinked using the shareable image. The two test images should have the same results.

If you intend to provide an upward compatible shareable image, before shipping out your first shareable image, you should verify that new items can be added without breaking existing programs that are linked against an existing shareable image.

Here are the steps to accomplish this:

  1. Link and test the verification test program against a pre-modified shareable image.
  2. Make modifications to the shareable image code base (including adding any new entry points).
  3. Run the same executable image created in step 1 using the new shareable image. Do not relink the test image otherwise you are not performing an test of link compatibility.

The test program should run without error. The program will not be able to access any of the new items added to the shareable image but telling a user (a customer) that they must recompile to get new features is easier instructing a customer to relink because you made a coding change.

Breaking upward compatibility can cause several different run time errors to occur depending on what was changed. For example, changing the order of SYMBOL_VECTOR entries or $CALL lines will cause the wrong routine to be called or the wrong data element to be accessed at run time. This, more often than not, results in a run time access violation.

5.5.2 Adding New Entry Points

If new classes or new member functions are added, you can use the previously described $ LIB/LIST/NAMES step to determine the new encoded names that must be exported. Existing names must remain if upward compatibility of the shareable image is to be maintained. See the OpenVMS Linker Utility manual for more details on extending a shareable image's global entry point list.

5.5.3 Using __extern_prefix

Providers of shareable images need to ensure that users of their shareable image do not experience name conflicts with other shareable images and software packages that may be installed on the same system.

The recommended method of doing this in C++ is by using the #pragma __extern_prefix compiler directive. For example:

#pragma __extern_prefix sw_

The sw_ variable represents a name unique to your software package.

The C++ Class Library uses CXXL$ as the unique name to export all of its global entry points.

The result of using #pragma __extern_prefix is that all global data and global routines are prefixed with the unique name as part of their encoded name.

For examples of how to use __extern_prefix , see the SW.HXX example, located in the SYS$COMMON:[SYSHLP.EXAMPLES.CXX] directory..

5.5.4 Transfer Vectors and Symbol Vectors

A Transfer Vector is the term used to describe the area of a shareable image in OpenVMS VAX that contains its public interface (or Entry Points).

The only way to create this transfer vector is by using VAX MACRO.

A Symbol Vector is the term used to describe the entry points for an OpenVMS Alpha shareable image. The symbol vector is created via the SYMBOL_VECTOR directive in a linker options file.

5.5.5 Exporting Global Data

For a shareable image to export a global instance of a class (for example: cout from CXXL$011_SHR) it must export a pointer to that instance. The OpenVMS Linker Utility manual describes this type of export as a "data cell".

Exporting a pointer allows the developer of the shareable image the option of modifying the class definition in a future release. The developer must take care to not effect the memory layout of the class.

The SW_SHR.HXX example file, located in the SYS$COMMON:[SYSHLP.EXAMPLES.CXX] directory, shows how the exporting of the pointer can be made somewhat invisible to the user.

5.5.6 Initilizing Global Data

The C++ compiler generates code in the LIB$INITIALIZE image program section (psect), which calls every global objects's constructor routine before the program executes its first statement.

This is also true for a shareable image's global data. The OpenVMS image activator calls each LIB$INITIALIZE contribution for each shareable image that is linked into a program. This means that, before a program executes its first statement, all global classes in every shareable image it references must have had their constructors called.

If you plan on providing an option of linking with an object library form of your shareable image, refer to the section in Using Compaq C++ for OpenVMS Systems on linking against the C++ Class Library Object Library. This section shows how users of the object library should link their application.

5.5.7 Virtual Functions

Virtual functions can not be added to public classes without breaking compatibility. This limitation is imposed by the method used to implement virtual function tables in the C++ object model. See Using Compaq C++ for OpenVMS Systems for more details on the C++ object model.

5.5.8 Using UNIVERSAL=

On OpenVMS VAX, you have the option of exporting global data and routines by using the UNIVERSAL option in a linker options file. Using this option requires any image linked against the shareable image to relink every time the shareable image is rebuilt. Because of the need to relink each time, Compaq does not recommend using this feature.

5.5.9 Description of Sample Code for Creating a Shareable Image Using C++

The SW_SHR sample code consists of several source modules, a command procedure and this description. Table 1 lists of each of the modules.

The code creates an OpenVMS shareable image called SW_SHR.EXE that supplies a Stopwatch class identical to the C++ Class Library's Stopwatch class. The Compaq C++ Class Library Reference Manual has details on the Stopwatch class.

SW_SHR also provides an instance of a Stopwatch class named G_sw that shows how to export a class instance from a shareable image. The method used is the same method used to export cout , cin , cerr , and clog from the C++ Class Library shareable image.

The files listed in Table 1 are located in the SYS$COMMON:[SYSHLP.EXAMPLES.CXX] directory.

Table 1 Shareable Image Example Files
Module Name Description
SW_DEFS.MAR Macro definitions for use by both the SW_VEC_ALPHA and SW_VEC_VAX macro source files.
SW_DEFS_ALPHA.MAR Macro definitions of globally accessible class objects defined within the shareable image.
SW_DEFS_VAX.MAR Entry point macro definitions and macro definitions of globally accessible class objects defined within the shareable image.
SW_SHARE.HXX General use macros to make exporting of global data (class instances) from shareable images more transparent to the users of class objects.
SW.HXX The definition of the Stopwatch class supplied by the shareable image.
SW.CXX Source associated with the public functions defined in SW.HXX. The file also contains the declaration of the global Stopwatch (G_sw) class instance.
SW_TEST.CXX A test of each of the Stopwatch's public access points and also the G_sw class instance.
SW_BUILD.COM A DCL command procedure used to build both the shareable image and the program.
SW_SHR_ALPHA.OPT An OpenVMS Linker options file, used on OpenVMS Alpha, that contains the SYMBOL_VECTOR entry points and other shareable image linker directives.
SW_SHR_VAX.OPT An OpenVMS Linker options file, used on OpenVMS VAX, that contains shareable image linker directives.

6 File Inclusion

To support processing of "prologue" and "epilogue" file inclusion, the C++ compiler introduced substantial changes to the processing of the #include directive prior to Version 5.3 that allowed for increased code commonality between the OpenVMS Alpha and VAX versions of the compiler. In Version 5.3, further changes were made to make the #include searching behavior of the VAX and Alpha OpenVMS compilers identical, and to support new ANSI C++ requirements on header file naming conventions. The following are some of the highlights of these modifications:

7 Improving Build Performance

This section contains suggestions for improving the performance of C++ on your system.

7.1 Template Instantiation

The cxxlink command automatically instantiates templates by prelinking to find unresolved symbols due to uninstantiated templates. Instantiations are completed by compiling instantiation source files in the repository. The prelinking and compiling process is repeated until all template instantiations have been compiled.

For some applications, the link-time automatic instantiation process can be time consuming. The following approaches may be helpful in reducing the amount of time it takes to build your application:

8 Namespaces Support

C++ Version 5.6 has added support for namespaces, as specified in the draft ANSI C++ Standard. Section 8.6 describes restrictions that pertain to namespaces support.

A namespace is an optionally named region in which you can place declarations. They are useful for avoiding name clashes. For example, 


namespace N { 
        int x; 
} 
 
namespace M { 
        double x; 
}

Placing these conflicting declarations of x into differently-named namespaces, lets you use both variables safely in your program; you can use the appropriate qualified names ( N::x, M::x ), or use one of the other means described in this section.

You can split the definition of a namespace into separate parts that can appear in one or more translation units. A translation unit can be thought of as a single source file together with any header files that the source file pulls in.

8.1 Namespace definition and namespace extension

A namespace is defined as follows:
namespace identifier { namespace-body }

namespace-body

Is a sequence of declarations.

Defining another namespace using the same name constitutes an extension namespace definition. For example: 


namespace N { 
        int n; 
} 
 
... 
 
namespace N { // extend namespace N 
        void func(void); 
}

The identifier used to name a namespace must be unique in the region where it appears.

Every namespace definition must appear in the global scope or in a namespace scope. Namespaces can be nested.

8.2 Unnamed namespaces

You may omit the identifier in a namespace definition:
namespace { namespace-body }

An unnamed namespace definition behaves as though it was written as:
namespace unique {}
using namespace unique;
namespace unique { namespace-body }

C++ replaces all occurrences of unique in a translation unit with the same identifier, and this identifier is different from all other identifiers

Unnamed namespaces are intended to be the preferred alternative to using the static keyword in namespace scope. Unnamed namespaces allow items to be visible within an entire compilation unit, but not visible in other translation units.

8.3 Namespace Alias

A namespace alias declares an alternate name for an existing namespace, according to the following syntax:

namespace-alias-definition:
namespace identifier = qualified-namespace-specifier ;

qualified-namespace-specifier:
::opt nested-name-specifier opt namespace-name

The identifier in a namespace alias definition becomes a synonym for the qualified namespace specifier. For example: 


namespace Outer { 
    namespace A_Long_Inner_Name { 
        int x; 
    } 
} 
 
namespace N = Outer::A_Long_Inner_Name; 
N::x = 0; // same as Outer::A_Long_Inner_Name::x = 0;

8.4 using Declaration

A using declaration introduces a name into a declarative region. That name is a synonym for a name declared somewhere else. The name specified in a using declaration in a class or namespace scope shall not already be a member of that scope. The syntax of a using declaration is as follows:

using-declaration:
using ::opt nested-name-specifier unqualified-id ;
using :: unqualified-id ;

Using declarations can result in function overloading. For example: 


namespace M { 
    void f(double); 
} 
 
namespace N { 
    void f(int); 
} 
 
void sub(void) 
{ 
    using M::f; 
    using N::f; 
 
    f('a');     // calls N::f(int) 
    f(1);       // calls N::f(int) 
    f(1.2);     // calls M::f(double) 
}

A using declaration that declares a class member, must refer to a member of a base class. Using declarations in classes are similar to access declarations.

8.5 using Directive

A using directive specifies that the names in the nominated namespace can be used in the scope where the directive appears, after the directive. A using directive cannot be used in class scope, but only in namespace scope or block scope. Further, a using directive does not declare names in the scope where the directive appears, it merely allows access to the names declared in the nominated namespace.

Using directives are transitive, for example: 


namespace M { 
        int i; 
        int j; 
} 
 
namespace N { 
        int i; 
        using namespace M; 
} 
 
void f() 
{ 
        using namespace N; 
        j = 0;  // assigns 0 to M::j 
        i = 1;  // ambiguous, both M::i and N::i are visible 
}

If a namespace is extended after a using directive for that namespace, the additional members can be used after the extension namespace definition.

8.5.1 Unqualified Name Lookup With using Directives

For unqualified name lookup, names appear in the nearest scope that contains both the using directive and the namespace definition. For example: 


namespace N { 
        int n = 1; 
} 
 
namespace A { 
        int n = 2; 
        namespace B { 
                using namespace N; 
                void f() { cout << n; } 
        } 
} 
 
... 
A::B::f(); // prints out the value 2 from A::n

This example shows that a using directive does not insert the declarations from a namespace into the region where the using directive apprears. The name lookup would look in the following scopes, in the following order:

Namespace B
Namespace A
File scope, including namespace N

Because name n is not locally declared in B , a unqualified name lookup must proceed upward through various scopes. The using namespace N directive signifies that looking in namespace N to resolve names is permitted. However, the definition of namespace N is at file scope, so any names from N are not available until the lookup has walked through scope all the way to file scope. Thus, in this example, the name from namespace A is found and used.

8.5.2 Qualified Name Lookup with using Directives

Given a qualified name, X::m , the compiler creates a set of all declarations of m in namespace X , and in all the namespaces nominated by using directives in X . Recall that using directives are transitive. Also, if any namespace directly contains a declaration of m , then any using directives in that namespace are not followed. The following is an example: 


int x; 
namespace Y { 
        void f(float); 
        void h(int); 
} 
namespace Z { 
        void h(double); 
} 
namespace A { 
        using namespace Y; 
        void f(int); 
        void g(int); 
        int i; 
} 
namespace B { 
        using namespace Z; 
        void f(char); 
        int i; 
} 
namespace AB { 
        using namespace A; 
        using namespace B; 
        void g(); 
} 
 
void h() 
{ 
        AB::g();     // g is declared directly in AB, 
                     // therefore S is { AB::g() } and AB::g() is chosen 
        AB::f(1);    // f is not declared directly in AB so the rules are 
                     // applied recursively to A and B; 
                     // namespace Y is not searched and Y::f(float) 
                     // is not considered; 
                     // S is { A::f(int), B::f(char) } and overload 
                     // resolution chooses A::f(int) 
        AB::f('c');  // as above but resolution chooses B::f(char) 
 
        AB::f(1.0f); // no best match between A::f(int) and B::f(char) 
 
        AB::x++;     // x is not declared directly in AB, and 
                     // is not declared in A or B, so the rules are 
                     // applied recursively to Y and Z, 
                     // S is { } so no x is found 
        AB::i++;     // i is not declared directly in AB so the rules are 
                     // applied recursively to A and B, 
                     // S is { A::i, B::i } so the use is ambiguous 
                     // and the program is ill-formed 
        AB::h(16.8); // h is not declared directly in AB and 
                     // not declared directly in A or B so the rules are 
                     // applied recursively to Y and Z, 
                     // S is { Y::h(int), Z::h(double) } and overload 
                     // resolution chooses Z::h(double) 
}

8.6 Restrictions

This section describes restrictions to namespace support in C++.

8.6.1 Restrictions in the Current Implementation

9 Additional Template Instantiation Options with Version 5.5

In addition to link-time automatic instantiation (the default) and compile-time instantiation using the /template_define command line qualifier, C++ Version ersion 5.5 provides two additional compile-time instantiation options for the /template_define command line qualifier, as follows:
local Instantiate only the template entities that are used in this compilation, and force those entities to be local to this compilation.
used Instantiate only the template entities that are used in this compilation. The template entities are instantiated with external linkage.

Similarities and differences between the three compile-time instantiation options are as follows:

Determining When to Use the Compile-time Instantiation Options

The compile-time instantiation options are primarily useful for reducing the time required to build an application.

One approach to reduce build times, would be to identify within your application the one module that contains the most uses of template entities. Once identified, this module can be compiled with either the all or used option and the remaining modules compiled with automatic instantiation. This approach avoids the problem of multiply defined symbols at link time that can occur when using these options; this approach also offers the convenience of automatic instantiation.

You can also use the local option to improve build times, provided that any redundant initializers for static data members do not have unwanted side effects. You can specify the local option for all modules in your application, something you cannot do with the all and used options. With the local option, instantiations are local to each module. These local instantiations are not shared across the various modules within an application. For some applications, multiple copies of the same instance can greatly increase the size of executables.

10 Explicit Instantiation

The new ANSI syntax for explicit instantiation has been implemented in the C++ compiler. The syntax for this (as of the January 26th, ANSI C++ working paper) is as follows:

template declaration

Currently, C++ accepts only template function declarations and template class declarations. C++ does not yet support explicitly instantiating template member functions or template static data members.

Note that because explicit specification of function template arguments is not yet implemented, a template argument list may not be specified in an explicit instantiation.

Examples of use: 


 
template <class T> class X { public: 
        // stuff; 
}; 
template <class T> void f(const T &t) { printf("f(const T&) called\n"); } 
 
template class X<int>;        // instantiate template class X with T=int 
template void f(int &);       // instantiate template function f with T=int 
template void f<int>(int &);  // not yet implemented

The ANSI syntax is unambiguous regarding template functions. Only the template function that matches the declaration in the explicit instantiation will be instantiated. The C++ #pragma define_template directive is ambiguous, and instantiates all the template functions that have the same number of template parameters as specified in the pragma.

To explicitly instantiate templates, Compaq now recommends that you use the new ANSI syntax instead of the #pragma define_template directive because the new syntax is more portable, as other compiler vendors implement the ANSI standard.

Note that the ANSI syntax for explicit instantiation uses a semicolon at the end of the declaration, while the syntax for the #pragma define_template directive does not. Omitting the semicolon can lead to obtuse error messages, because the code that follows may look like part of the declaration in the explicit instantiation.

Explicit instantiation currently has the same restrictions on code ordering as does the #pragma define_template directive. The explicit instantiation must appear in the code after the definitions of a class and its member functions or after the definition of the template function.

11 Release Notes for the C++ Class Library

This section describes the problems fixed, known problems, and restrictions for the C++ Class Library. See Section 13 for information on the C++ Standard Library. Please note that String Package, which is part of the 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.

11.1 Restrictions

12 Thread Safety for the C++ Class Library

The Class Library is now threadsafe on OpenVMS Version 7.0 systems: the predefined stream objects and internal library data are protected against simultaneous access from multiple threads. The Class Library also provides a new Mutex class for use in synchronizing access to user-defined objects. For more information about this support, see the Compaq C++ Class Library Reference Manual.

To take advantage of this thread safety support, you need to compile your application with the threadsafe header files and link and run your application with the threadsafe run-time library.

If your application is not compiled with the threadsafe header files, your application will continue to work on OpenVMS Version 7.0 and later systems. However your application will not be threadsafe.

13 Release Notes for the C++ Standard Library

This section describes the enhancements, problems fixed, known problems, and restrictions for the C++ Standard Library. See Section 11 for information on the C++ Class Library. Please note that the current version of 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 C++ Class Library implemented in earlier versions of C++.

13.1 Enhancements and Changes in Version 5.6

13.2 Differences between Version 5.5 and Version 5.6

13.3 Problems Fixed in Version 5.6

13.4 Enhancements and Changes in 5.5

Version 5.5 of the compiler included a subset of the C++ Standard Library. The set included:

The Standard Template Library (STL)
The String library
The Numeric Limits class
The auto_ptr class
The Standard exception classes

13.5 Problems Fixed in 5.5

13.6 Problems Fixed in Version 5.4

13.7 Known Problems

The following are known problems when using the current release of the STL with the compiler. Where appropriate, workarounds are suggested.

13.8 Restrictions

This section describes problems of interest to Standard Library users that Compaq has no current plans to fix. Where feasible, a way to work around the problem is suggested.

14 About This Product

Compaq Computer 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 Compaq or an authorized sublicensor.

Contents
  

1.800.AT.COMPAQ

privacy and legal statement