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

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.

©1993-1999 Digital Equipment Corporation

Compaq, the Compaq logo, Alpha, DEC, DECthreads, DECwindows, Ladebug, and Tru64 UNIX 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.

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

The software and information pertaining to such portions of the C++ Standard Library are proprietary to, and comprise valuable trade secrets of, Rogue Wave Software, Inc., which intends to preserve as trade secrets such software and information.

This software and information are furnished pursuant to a written license agreement and may be used, copied, transmitted, and stored only in accordance with the terms of such license and with the inclusion of the above copyright notice. This software and information or any other copies thereof may not be provided or otherwise made available to any other person.

Contents

1 Introduction

This document contains the release notes for Compaq C++ Version 6.2 for Compaq Tru64 UNIX.

This kit installs two compilers:

• The cxx command invokes the Version 6.2 compiler. The version is Version 6.2.
• The cxx -oldcxx command invokes the Version 5.7 compiler. The version is V5.7-002.

The Ladebug version installed by this kit is 4.0-48 or higher.

HTML files are provided for the release notes and some of the product manuals for use with a web browser. You can install these files by selecting the subset Compaq C++ HTML documentation.

To view this documentation, point your browser to file:/usr/share/doclib/cplusplus/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 (libcxx) 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 the C++ Run-Time Library, see Deploying Your Application in Using Compaq C++ for Tru64 UNIX.

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

• Language differences
  The compiler implements most of the C++ International Standard, which differs significantly from the language specified in the ARM (The Annotated C++ Reference Manual, 1991, by Ellis and Stroustrup) with some ANSI C++ extensions. 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 Version 5.n source code with minimal source changes, specify the -std arm option. See Porting to Compaq C++ in Using Compaq C++ for Tru64 UNIX.
  If Version 6.n requires excessive changes to your applications even when you use the -std arm option, or if you encounter problems using the Version 6.n compiler, you can compile using the cxx -oldcxx command. If you discover a compatiblity problem that is not documented, please file a PTR or SPR.
• Diagnostic differences
  The Version 6.n compiler does more error checking than Version 5.7 and generates more diagnostics. If you want the number of diagnostics issued by the Version 6.n compiler to be similar to Version 5.7, compile with the -msg_quiet option. For details, see Message Control Options in Using Compaq C++ for Tru64 UNIX.
• 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 5.n instantiation process with a Version 5.n (or specify the -oldcxx option) before linking with code compiled with Version 6.n. See Using Templates in Using Compaq C++ for Tru64 UNIX.

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

• 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 devised that that can be implemented without changing all existing C headers. If and when such a mechanism becomes available, we plan to use it, rather than use the simple-to-implement but nonstandard-conforming mechanism used by other C++ vendors: have the <cname> version 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 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.

    // name.h includes types.h & brings it into std:: <cname> // types.h in global namespace <types.h> 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++ implementations.
  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

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

3.1 Enhancements and Changes in Version 6.2

Version 6.2 includes the following enhancements and changes:

• Some functions needed for language compatibility run-time support have been moved from libcxxstd.a to the shared library libcxx.so. For details, see Deploying Your Application in Using Compaq C++ for Tru64 UNIX.
• Many compiler and library problems have been corrected (see Section 3.2 and Section 4.2).
• Many improvements have been made to cross-reference information generated by the compiler.
• The compilation system and run-time library now call destructors that are defined in shared images which have been closed correctly using dlclose(), with the linker option -depth_ring_search. This feature requires that a new libcxx be installed on your system with Version 6.2. Otherwise, the compiler reports the undefined symbol __cxx_call_static_dtors.
• The -gall option now outputs debugging information about unused variables, so that you can make queries. For more information about this option, see Using the -gall and -gall_pattern Options in Using Compaq C++ for Tru64 UNIX.
• 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
• Diagnostics from the driver during the link phase are now sent to stderr instead of to stdout.
• Consumption of virtual memory is significantly reduced when computing the addresses of deeply nested virtual base classes. [6473]
• More cases of unreachable code are now diagnosed. If you receive warnings you believe to be inappropriate, please report them. [6534]

This section summarizes compiler changes and the most important problems corrected in Version 6.2.

• Specifying -noglobal_array_new no longer indirectly causes generation of rogue cleanup handlers. [6095]
• Enum types larger than int are now compatible with arm mode. [4499]
• Specifying -v now displays command-line, driver-generated, and predefined macros on standard output. The listing file now contains correct list of command-line and predefined macros, taking into account macro undefines and redefines. [4723] [5609]
• The compiler now correctly calls a function with an argument with short pointers in -xtaso_short mode from within a template member function instantiation. An error message is now longer displaued for the call.
• 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 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]

• Bad code is no longer generated for an array reference within a template instantiation. [6394]
• 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 generates incorrect code for offsets to external arrays. [6386]
• The routine for new[] now calls delete[] if an exception occurs during construction. [6243]
• A compiler crash caused by a label statement in a switch statement has been corrected. [6614]
• Macro expansions are now output to the listing file when both -show expansion and -source_listing are specified. [6107]
• When a local stack is used in constructors, the compiler displays the warning "Initialization of references requires temporaries of automatic storage duration". [4522]
• Null characters in comments are now ignored in -std arm mode. The Version 6.0 compiler treated null characters in comments as errors. Outside of comments, null characters are now diagnosed as warnings in -std arm mode, and as errors otherwise. [3740]
• 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 UNIX builtins.h file. See Built-In Functions in Using Compaq C++ for Tru64 UNIX.
• A template class name can now be reused as a nontemplate class in a private namespace without generating an error message. [6541]
• 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 Version 6.2. If you have such a bitfield in your code, you must recompile. [6567]

• If -nocleanup is specified, the compiler does not reference the destructors or delete operators used for cleanup code that is not generated. The -noexceptions option now implies -nocleanup. [6216]
• The compiler no longer generates code in -std arm mode to the left side of the -> and . operators if the right hand operand is a static member. [4469]
• For compatibility with Version 5.6, the ec_inaccessible_base_class error on function return expressions in -std arm mode is now disabled. [3744]
• The compiler now warns about differences in meaningless qualifiers.
• The driver now terminates if the compilation results in a fatal error or ctrl-c.
• In -std arm mode, the compiler no longer checks for suitable copy constructors of classes with volatile qualifiers. [6087]
• To maintain compatibility with arm, cfront, and ms modes, null preservation code is enabled for cases where a pointer should not be null. [4695]
• The compiler now checks for comparison of two incompatible enums. The compiler reports this condition with a new informational message ec_incompatible_enum_comparison. [6172]

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.
• Intrinsic bcopy generates warning
  Starting with C++ Version 6.2, the bcopy function has been made intrinsic to improve performance. On Compaq Tru64 UNIX Version 4.n systems, this change can cause the compiler to issue the following warning message:

  cxx: Warning: /usr/include/strings.h, line 83: Expected type "void (const void *, void *, unsigned long) C" is incompatible with declared type "void (const char *, char *, int) C", function will not be made intrinsic extern void bcopy __((const char *, char *, int)); ------------^

  
  Compaq Tru64 UNIX Version 4.n systems provide two function prototypes for bcopy, one that conforms to the standard, and another, the system default, for compatibility with previous operating system versions. The compiler issues the warning when it encounters the nonstandard version. For details, see the bcopy(1) reference page.
  To suppress the message, you can do one of the following:

  • Use an ANSI-standard copy function such as memcpy
  • Enable the standard function by defining -D_XOPEN_SOURCE_EXTENDED -D_OSF_SOURCE before including the header file
  • Compile with the -std strict_ansi option
  • Use #pragma function(bcopy)
  
  Because the next major operating system release implements a change in the UNIX98 standards and provides only the standard definition, the first or second method is recommended. The third and fourth methods prevent the function from being made intrinsic.
• Some features implemented in Version 5.7 are not supported by the current compiler. See Porting to Compaq C++ in Using Compaq C++ for Tru64 UNIX.
• The UNIX utility nm does not always work on Compaq Tru64 UNIX Version 4.n systems with object files generated by the current compiler. The symptom is a seg fault when nm attempts to dump its list. An alternative to nm might be the odump utility. For example, the command odump -tv foo.o lists all the symbols in the archive. See the odump reference page for more details on the odump utility. Another possible workaround is to compile your object file with -g (debugging), then recompile it without -g. That procedure might avoid triggering the nm bug.
  If you want to obtain a version of nm that corrects this problem, these are the patch kit identifiers:
  

  OPERATING SYSTEM VERSION	PATCH ID
  v40	OSF400-438
  v40a	OSF405-438
  v40b	OSF410-438
  v40c	OSF415-438
  v40d	OSF420-42

• If you use a non-default pointer size or member alignment and header files are not protected, the following warning is issued:

  < cxx: Warning: A non-default pointer size or member alignment is specified and the system header files are not protected. This may yield unpredictable results. The protect_headers_setup script can help. See the protect_headers_setup(8) reference page for details.

  
  The protect_headers_setup(8) reference page page is planned for a future release of Compaq Tru64 UNIX. For now, see Protecting System Header Files in Using Compaq C++ for Tru64 UNIX.

• Debugging programs that use namespaces
  For this version of Compaq C++, namespaces are presented as classes of the same name to the debugger. This affects Ladebug in the following ways:
  • Ladebug does not make a distinction between namespaces and classes. For example, Ladebug reports a namespace as being a class if you issue the whatis namespace-name command.
  • Ladebug does not support the using declaration; you must fully qualify names in a namespace. For example:

    namespace_name::name

  • Ladebug support for Version 6.n-specific features, such as Run-Time type identification (RTTI), has not yet been added.
  • Ladebug does not provide information about templates or macros; it does provide information about template instantiations.
  • Namespace definitions can be different between different files.
    You might need to qualify a namespace with a filename or set your file scope to view namespace extensions. For example, suppose your program has two source files: one.cxx and two.cxx as follows:

    //one.cxx namespace ns { int a; } void two(); main() { two(); } //two.cxx namespace ns { int a; } namespace ns { // extend the namespace float b; } void two() { }

    
    While you are in main(), you can view ns::b using either of the following methods:

    print "two.cxx"`ns::b #qualifying with name file two.cxx ; print ns::b #setting file scope

• Restricted address space size for precompiled headers in some versions of Compaq C++.
  Some versions of Compaq C++ might restrict the size of the address space available for use by precompiled headers. If the compiler terminates with a message about mapped memory, this may be the problem.
  To increase the address space available for precompiled headers you need to increase the mapentries limit.
  Follow these steps to change the mapentries limit:
  1. Become the root user.
  2. Create a new file named /tmp/xxx and insert the following lines:

     vm: vm-mapentries=5000

  3. Execute the sysconfigdb command as follows:

     # /sbin/sysconfigdb -f /tmp/xxx -m vm

  4. Reboot the system.
  
  This procedure increases the mapentries limit from the default 200 to 5000. Increasing the limit by that amount has no adverse effect on the system.
• When using PCH, the line number associated with an inline function is the line at which the PCH stop is encountered.
• Certain utilities, such as GNU Make, do not recognize compressed object files, which the compiler creates by default. If you encounter problems, you can specify the -nocompress command-line option.
• 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.
• Linker -no_archive does not work with Compaq C++
  The switch does not work because the Standard Library, libcxxstd.a, is supplied only in archive form.
  Specifying -no_archive causes the cxx drive to issue the following messages:

  ld (prelink): Can't locate file for: -lcxxstd ld: Can't locate file for: -lcxxstd

• Class and Standard Libraries generate Third Degree messages. Appendix B in Using Compaq C++ for Tru64 UNIX describes these messages.

This section summarizes compiler changes, enhancements, and the most important problems corrected in Version 6.1-029.

• The optimization phase of the compiler has been changed to disable a specific optimization that caused ATOM based tools to behave unpredictably. This optimization may be restored once these tools have been enhanced to expect this optimization.
• New warning messages indicate when assigning from a larger to a smaller data type might cause a truncation. These messages facilitate porting from 32-bit to 64-bit platforms. [3971]
• A workaround has been implemented to prevent the linker from erroneously declaring too many GOTs during the prelink phase. [6027] [43-4-305]
• Templates made friend are now instantiated with external linkage when -timplicit_local is specified. [6056]
• Access checking for pointer to members in ARM mode has been relaxed to be more compatible with Version 5.n. [6088]
• Calling operator(new) on an array of objects allocates extra header information to describe the array so that operator delete can call destructors on the elements. In this release, the header has been made compatible with object code generated with version 5.n releases. [6151]
• During the prelink phase, the driver no longer splits linker output lines at 8000 characters. [6166]
• The driver no longer suppresses error messages during the prelink phase. As a result, messages might apprear multiple times. This new behavior helps prevent silent or confusing failures. [6168]
• A problem unwinding from multiple exceptions has been corrected. [6185]
• A compiler fatal error using volatile structures has been corrected. [6186]
• The cxx driver no longer runs post-link phases that are unnecessary to determine required templates. [6191]
• A problem with interaction between -vptr_size_short and -xtaso_short has been corrected. [6195]
• If a local static object is referenced by more than one template, the compilation no longer results in an unresolved symbol for the __fini routine. The routines to call the destructors for static objects, which are prefixed with __fini, are now allocated properly with automatic instantiation mode. [6278]

This section summarizes compiler changes, enhancements, and the most important problems corrected in Version 6.1.

• The Version 6.0 compiler incorrectly mangled the name of a class virtual function table when that class was nested within another class or namespace. If object modules compiled with Version 5.n and Version 6.0 were linked together, the compiler might display the following message:

  ld: Unresolved: std::__vtbl_3std9type_info

  
  This problem has been corrected. Any code generated with Version 6.0 that demonstrates this problem should be recompiled with the current compiler. [5144]

• The compiler used to mark all member functions of the class that had not already been specialized as needing to be instantiated when processing a #pragma define_template class <args>. But the compiler did not instantiate the functions until processing the end of the scope. If a specialization occurred after the #pragma but before the compiler tried to instantiate it, the compiler found that the member function had already been specialized and reported the following error:

  "function" cannot be instantiated -- it has been explicitly specialized

  
  This error is reduced to a warning and is issued only once per instantiation. The warning can be suppressed by using the command-line switch -msg_disable 490. See Compaq C++ Implementation in Using Compaq C++ for Tru64 UNIX. [43-4-137]

• The compiler no longer generates incorrect code when dereferencing an element of an array of pointers. [5236]
• A problem creating shareable libraries has been corrected by allocating static local const variables initialized with pointers to .rdata instead of to .rconst. [43-4-166]
• To facilitate setting default compiler flags, you can now create an optional configuration file named comp.config or an environment variable named DEC_CXX.
  • The comp.config file allows system administrators to establish a set of compilation flags that are applied to compilations on a system-wide basis. The compiler flags in comp.config must be specified on a single line, and the comp.config file should be stored in the compiler target directory, /usr/lib/cmplrs/cxx.
  • The DEC_CXX environment variable allows users to establish a set of compilation flags that are applied to subsequent compilation on a per user basis.
    The DEC_CXX environment variable can contain two distinct sets of compilation flags separated by a single vertical bar ( | ). The flags before the vertical bar are known as prologue flags and the flags after the bar are know as epilogue flags.
    The DEC_CXX environment variable can begin or end with a vertical bar, or have no vertical bar at all. If no vertical bar is present, the flags are treated as prologue flags by default. Any vertical bar found after the first vertical bar is treated as whitespace and a warning is issued.
  
  During a compilation, compiler flags are processed in the following order:
  1. comp.config flags
  2. DEC_CXX prologue flags
  3. command line flags
  4. DEC_CXX epilogue flags
  If -v is specified on the command line, the contents of DEC_CXX and comp.config, if present, are displayed. [4488]
• By default, C files are compiled with -std. Users can now override the default by specifying
  -std0/-std1. [4392]
• The compiler no longer mishandles "?" operations on a boolean type in constructs like that in the following example. [43-4-135]

  bool f(int i) { return (i<5 ? false : true ); }

• Parallel compiles now work correctly because the compiler no longer deletes an empty template repository. [5544]
• The current version does not support the -show statistics option implemented in Version 5.7.
  The following are now supported:
  • -nocpp
  • -show expansion
  • -xref
  • -xref_stdout
  • listing of predefined macros
  • #pragma message

This section briefly summarizes changes and enhancements made in Version 6.0. For information about compatibility issues that you might encounter using Version 6.2 if you have used Version 5.n in the past, refer to Porting to Compaq C++ in Using Compaq C++ for Tru64 UNIX.

• Support for the C++ International Standard (with some differences, as described in Section 2.3), including the C++ Standard Library. See Section 4 for information about and changes to the Standard Library.
• Language mode options
  For compatibility with previous versions, the compiler supports an ARM language mode and provides both -std ansi and -std 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 Tru64 UNIX.
• Improved automatic instantiation of templates, including fewer restrictions. In particular, Compaq C++ no longer requires that template declarations and definitions appear in header files. For details, see Using Templates in Using Compaq C++ for Tru64 UNIX.
• Support for precompiled headers to decrease compilation times. For complete information, refer to Precompiled Headers in Using Compaq C++ for Tru64 UNIX.
• Performance optimization options
  To improve performance, the compiler provides the following options:
  • -[no]ansi_alias
  • -assume [no]pointers_to_globals
  • -assume [no]whole_program
  
  For details, see Performance Optimization Options in Using Compaq C++ for Tru64 UNIX.
• Run-Time type identification
  The compiler emits type information for Run-Time type identification (RTTI) in the object module with the virtual function table, for classes that have virtual function tables. For details, see Run-Time Type Identification in Using Compaq C++ for Tru64 UNIX.
• Changes to behavior of the -gall option. See Using the -gall and -gall_pattern Options in Using Compaq C++ for Tru64 UNIX.

The following sections describe enhancements, changes, problems corrected, and restrictions for the C++ Standard Library. For information about the Compaq C++ Class Library, see Appendix A in Using Compaq C++ for Tru64 UNIX.

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

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.

4.1 Enhancements and Changes in Version 6.2

The following enhancements and changes are included in Version 6.2:

• Cleaner header file inclusion policy
  This new version of the Standard Library is much cleaner in its inclusion of unnecessary headers. 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);

• Many common iostream and locale instantiations (for example, those based on the char type) have been put into the Standard Library to improve compile-time performance. If you want to instantiate them yourself and use your own instantiations (perhaps to have a debugging version), follow these steps:
  1. Compile with the macro __FORCE_INSTANTIATIONS defined (-D__FORCE_INSTANTIATIONS).
  2. Link with the option -nopreinst. The linker then finds the instantiations in your repository before it finds those in the Standard Library.

The following problems are corrected in Version 6.2:

• money_get/money_put locale facets now conform to C++ International 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 Standard
  The standard file stream classes have been corrected to conform to the 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 need to 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 Standard Library supplies the following template definition files in /usr/include/cxx:

  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 before /usr/include/cxx, the automatic instantiation mechanism picks up your local copy and does not correctly find the library files. (See Using Compaq C++ for Tru64 UNIX for more information about how the prelinker finds template definition files.)
  Do 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 ANSI draft 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's declared in the header.
  For example:

  #include <new.h> // override default operator new // this gives 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.1 ships the following non-Standard headers which are for internal use only. Their contents are subject to change and can not be relied upon.

  <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 internal use only. They are subject to change and can not be relied on.

• Warning on Cast to CV_qualified Types
  When using STL container classes with Compaq C++ Version 6.1 the compiler might issue a warning the following:

  cxx: Warning: /usr/include/cxx/utility, line 131: type qualifier is meaningless on cast type detected during: instantiation of "std::pair<const int, char>::pair() ... : first(T1()), second(T2()) --------^

  
  The preceding was generated from the following:

  typedef multimap<int, char, less<int> > mmap; typedef pair<int, char> pair_type; pair_type p1 (3, 'c'); pair_type p2 (4, 'd'); ... pair_type array [] = {p1,p2,p3,p4,p5,p6}; mmap m (array, array + 6);

  
  The reason for this warning is that internally the container classes may make calls to Standard Library utilities like pair() which make use of functional-notation casts. For example pair() makes use of first(T1()). In this example T1() is a functional-notation cast to type T1. The type in a functional-notation cast has to be a single type identifier. Internally the library may add the const qualifier to a template type to ensure "constness". In the above example this has happened leading to an instantiation of first (const int()), which generates a warning.
  Warnings about casts to cv_qualified types will no longer be issued when the types come from a template parameter. In the meantime suppress such warning by compiling with:

  -msg_disable cast_to_qualified_type

• 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 tmplatized on the iterator category

• Restrictions on Printing Some Cases of bool/wchar_t Types with pre-ANSI Library
  Objects of a class which contain a user defined conversion operator to either bool or wchar_t can not be output directly with cout when including <iostream.h>. For example, the following program will give compilation errors indicating that more than one operator "<<" matches these operands:

  #include <stdlib.h> #include <iostream.h> struct B { operator bool() { return true; } }; struct W { operator wchar_t() { return L'0'; } }; int main() { B b; cout << b << endl; // V6.1 ambiguity error W w; cout << w << endl; // V6.1 ambiguity error return EXIT_SUCCESS; }

  
  If you try to output the subscript operator of vector<bool> directly with cout, you will encounter this problem in the library. The following will generate an ambiguity error:

  #include <stdlib.h> #include <iostream.h> #include <vector> int main () { vector<bool> vb; // V6.1 ambiguity error cout << vb[1] << endl; return EXIT_SUCCESS; }

  
  The workaround is to cast your class to either (bool) or (wchar_t) respectively. You would code the previous programs as follows:

  #include <stdlib.h> int main() { B b; cout << (bool)b << endl; W w; cout << (wchar_t)w << endl; return EXIT_SUCCESS; } int main () { vector<bool> vb; cout << (bool)vb[1] << endl; return EXIT_SUCCESS; }

• Compiling STL and "Arg list too long" Error
  Compiling STL code may generate a compilation error similar to that below indicating "Arg list to long":

  Error: Can't find or exec: /usr/lib/cmplrs/cxx/cc : Arg list too long

  
  If you are building an executable image the workaround is to add the following to your command line:

  -use_ld_input

  
  You cannot use this workaround to create a library.

• Use of exception in <math.h> and Standard C++ Library
  In Compaq C++ Version 6.1, namespaces resolve a conflict between the name exception found in the header <math.h>, which represents a structure, and the name exception found in the C++ Standard Library header <exception>, which represents the Standard Library exception class. The structure exception from <math.h> is visible in the global namespace. The Standard Library exception class from <exception> is visible in the std namespace.
  Because of this behavior, if you include, directly or indirectly, both of the headers <math.h> and <exception> you must qualify actual uses of exception to avoid name conflicts:

  #include <math.h> #include <exception> int main () { ::exception e; // exception from math.h std::exception e1; // Standard Library exception class return 0; }

• collate_byname<wchar_t>::do_transform()
  The function collate_byname<wchar_t>::do_transform() seg faults if you use it with any locale other than the "C" locale. This happens because of a bug with the underlying C function wcsxfrm(). No workaround currently exists for this problem.
• 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 in library
  You can define a global operator new() to displace the version used by the C++ Standard Library or C++ Class Library. For instructions, see Overriding operator(new) in Using Compaq C++ for Tru64 UNIX.
• The -define_templates and -tall options are not guaranteed to work with the Standard Library. Specify -tused instead.
  When compiled with -define_templates or -tall, the following code generates compilation errors indicating that no operator "<" (and ">" or "+" or "-") matches these operands:

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

  
  The instantiaton 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 -tall 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 -tall or cxx -define_templates, 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 -tused 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.

• Linker might produce multiply defined symbols from Standard Library
  The linker might produce multiply defined symbols from the Standard Library when linking against your own shared library.
  If you find multiply defined symbols like the following coming from libcxxstd.a, you might be creating a shared library and then using that shared library to create an executable.

  ld: /usr/lib/libcxxstd.a(typeinfo.o): std::__vtbl_3std9type_info: multiply defined /usr/lib/libcxxstd.a(vec_newdel.o): __vec_new_eh: multiply defined

  
  The problem is that libcxxstd.a is an archive library. When you create a shared object that references this library, the symbols are pulled into that shared object. When you then use the shared library, it finds the symbol both in your shared object and in the libcxxstd.a library archive.
  To work around this problem, use a command like the following when you create your shared library objects:

  cxx -hidden /usr/lib/cmplrs/cxx/libcxxstd.a -non_hidden -shared foo.cxx

  Note Version 6.1-029 corrects a problem that sometimes occurred when using this workaround. You must, however, still use the workaround if you receive multiply defined symbols from libcxxstd.a.

  
  To prevent the generation of multiply defined symbols, a future release will include a shared object version of libcxxstd.a.
• 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 size of long double has changed in Compaq Tru64 UNIX Version 5.0 If you use the standard iostreams or locale library to input or or output long doubles, you must specify the -nopreinst with your link command for instantiations to work correctly.

The following enhancement is included in Version 6.1-029:

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

The following problems are corrected in Version 6.1-029:

• list::sort(Compare comp) member function now correct
  Previously, if users supplied their own Comparison function object for the element of the list, the compiler still required an operator< defined for the element type. This is no longer the case.
• strstream now correctly deletes underlying strstreambuf
  The Standard Library strstream classes now delete the underlying strstreambuf (and string) when a strstream object is 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.

• stringstream.str() can now be accessed after seekp(0)
  The underlying string in a stringstream can now be accessed properly after a seekp(0). For example, the following program no longer causes a run-time core dump.

  #include <iostream> #include <sstream> int main() { std::ostringstream out; out << std::string("This is a test"); out.seekp(0); std::cout << "out.str(): " << out.str() << std::endl; return EXIT_SUCCESS; }

• <wchar.h> can be included before <fstream>
  Including <wchar.h> before <fstream> no longer causes compilation errors.
• std::ostrstream::freeze() no longer leaks memory
  The std::ostrstream::freeze() function no longer leaks memory when used in combination with an ostrstram object. If you declare an ostrstream object as std::ostrstream out, the memory to which output is written is dynamically allocated. Previously, calling freeze(false) incorrectly froze a stream, thereby preventing the deletion of allocated memory. This is no longer the case.
  The following program (which would have illustrated the memory leak when instrumented with third degree) no longer leaks memory.

  #include <stdlib.h> #ifndef __USE_STD_IOSTREAM #define __USE_STD_IOSTREAM #endif #include <iostream> #include <strstream> void TestIt() { std::ostrstream out; out << std::string("This is a test"); out.freeze(false); char *s = out.str(); return; } int main() { for (int i = 0; i < 100; i++) TestIt(); return EXIT_SUCCESS; }

• Math overloads in <valarray> OK
  Including <valarray> and then calling some of the math routines (for example, abs()) with an int argument might have produced an ambiguity error. This has been corrected.

The C++ Standard Library provided with this release defines a complete specification (with some differences) of the C++ International Standard. The library includes the ANSI locale and iostream libraries. Reference pages describing the Standard Library are provided; you can type man cxxlibstd_intro to access them.

Tutorial programs illustrating functionality found in the Standard Library, including the locale, iostream, and STL classes shipped with this release are available in:

/usr/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:

/usr/examples/cxx/*.res

Version 6.1 introduces the following major enhancements and changes. For detailed information, on the Compaq C++ Standard Library, refer to Using Compaq C++ for Tru64 UNIX.

• Support for C++ International Standard iostream and locale
  The Version 6.1 kit contains detailed documentation in PostScript and PDF formats:
  • /usr/share/doclib/cplusplus/intzln.ps
  • /usr/share/doclib/cplusplus/intzln.pdf
  • /usr/share/doclib/cplusplus/locale.ps
  • /usr/share/doclib/cplusplus/locale.pdf
• Reference pages for the Standard Library. You can access them by typing man cxxlibstd_intro.
• Several new options (see The C++ Standard Library in Using Compaq C++ for Tru64 UNIX.)
• pre-ANSI/ANSI iostreams compatibility.
• Support for ANSI/pre-ANSI operator new().
• Support for global array new and delete.

Additional changes include the following:

• 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 under -std strict_ansi or -std strict_ansi_errors 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.n uses compile time rather than link time template instantiation, there is no use for common instantiation libraries. No build_common_instantiation_library script is supplied. See Using Templates in Using Compaq C++ for Tru64 UNIX.
• Interface change for STL distance() function
  Because the Version 6.1 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.1 the result was returned in d distance(first,last,d);

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

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

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

• Specific changes to match the November C++ Final Draft 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 has changed from allocator<T> to allocator<pair<const Key, T> >.
• Some Standard Library ambiguities corrected
  The Standard Library vector, deque and list containers no longer generate ambiguities when using their constructors or insert member functions. However, 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; }

  
  A compilation error results from the overload resolution between integral and iterator types. The constructors involved are:

  // construct n elements and initialize with value basic_string(size_type n, charT c, const Allocator& a = Allocator()); // construct a vector 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, ...) The reason is that size_type a size_t is an unsigned long on Compaq C++. So you have:

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

  
  The second constructor is the better match, but it is not what we want, because we are not constructing with 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; }

This section describes library problems corrected in Version 6.1.

• STL map containers are now accessible in multithreaded environments
  Erasing elements from two STL map containers in a multithreaded environment no longer causes a segmentation fault. With previous versions, the problem was caused by an incorrect locking mechanism in an implementation class used when a map is being "erased".
  To correct the original problem reported against the STL map class, we reworked map's entire underlying implementation class. The underlying implementation class is found in the <tree> header. This class has been modified so that it no longer contains static data members.
• Standard Library IOStream cerr.flush() no longer hangs in multithreaded environments
  Applications making use of the Standard Library IOStream cerr.flush() function in combination with other I/O related activities in a multithreaded environment no longer experience hangs in their executing code.
• Piping standard output or standard error to a file no longer loses output when using Standard Library IOStreams
  The symptoms of this Standard Library bug varied. One noticeable effect could be seen when executing a program using Standard Library IOStreams which inserted items to cout and then piped this output along with other output to a file.
  For example, if a program inserted into cout as follows:

  #define __USE_STD_IOSTREAM #include <stdlib.h> #include <iostream> int main() { cout << "Hello from C++" << endl; return EXIT_SUCCESS }

  
  And if a script, d.sh executed the above program and made use of a command that output to Standard Error like this:

  a.out ls -X

  
  And if you piped both Standard Output and Standard Error to a file like this:

  d.sh >& testlog

  
  The output to Standard Output was lost. The testlog would contain:

  + ls -X ls: illegal option -- X usage: ls [ -1ACFLRabcdfgilmnopqrstux ] [files]

  
  Rather than:

  Hello from C++ + ls -X ls: illegal option -- X usage: ls [ -1ACFLRabcdfgilmnopqrstux ] [files]

  
  This problem has been corrected.

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

© 1999 Digital Equipment Corporation.

Contents

privacy and legal statement