Compaq C++ Version 6.5
Compaq C++ Version 6.5
Release Notes for OpenVMS Alpha
February, 2002
This document contains information about new and changed features in
this version of Compaq C++ for OpenVMS Alpha.
Compaq Computer Corporation
Houston, Texas
© 2002 Compaq Information Technologies Group, L.P.
COMPAQ, the Compaq logo, Alpha, OpenVMS, VMS, and Tru64 are trademarks
of Compaq Information Technologies Group, L.P. in the U.S. and/or other
countries. UNIX is a trademark of The Open Group in the U.S. and/or
other countries. All other product names mentioned herein may be
trademarks of their respective companies.
Portions of the ANSI C++ Standard Library have been implemented using
source licensed from and copyrighted by Rogue Wave Software, Inc. All
rights reserved.
Information pertaining to the C++ Standard Library has been edited and
reprinted with permission of Rogue Wave Software, Inc. All rights
reserved.
Portions copyright 1994-2002 Rogue Wave Software, Inc.
Confidential computer software. Valid license from Compaq required for
possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government
under vendor's standard commercial license.
Compaq shall not be liable for technical or editorial errors or
omissions contained herein. The information is provided "as
is" without warranty of any kind and is subject to change without
notice. The warranties for Compaq products are set forth in the express
limited warranty statements accompanying such products. Nothing herein
should be construed as constituting an additional warranty.
1 Introduction
This document contains the release notes for Compaq C++ Version 6.5
for OpenVMS Alpha. The Compaq C++ product requires OpenVMS Alpha Version
6.2 or higher.
The Compaq C++ media contains the following:
- The Version 6.5 kit, which includes the Compaq C++ compiler and
associated files, such as the Class Library and Standard Library header
files.
- The ADX072 kit, which contains an enhanced OpenVMS Debugger that
provides better debugging of applications built with the Compaq C++
compiler.
HTML files are provided for the release notes and some of the product
manuals for use with a web browser. To view this documentation, point
your browser to
file:/sys$common/syshlp/cxx$help/index.htm
|
2 Important Compatibility Information
Compaq strives to maintain a high degree of compatibility between
successive versions of the compiler and its run-time environment.
Because, however, each new version includes enhancements and changes,
you should be aware of the following whenever you upgrade:
- Differences between Standard Library versions
- Differences between compiler versions
- Differences between Compaq C++ and the C++ International Standard
- Retirement of
cfront
language dialect
The next sections discuss these differences.
2.1 Standard Library Differences
Any code that references the C++ Standard Library (any of the STL
containers or algorithms, standard iostreams or locales) must be
recompiled and relinked because there is no guarantee that the C++
standard library shipped with a given version of the C++ compiler will
be compatible with the C++ standard library shipped with previous
versions. This restriction does not apply to code that references the
pre-standard class library, because the stability of that library's
interface guarantees link compatibility in future releases.
For example, the C++ Standard Library shipped with Compaq C++ Version
6.3 is incompatible with header files and the Standard Library shipped
with Compaq C++ Version 6.2. Linking an object file compiled with
Compaq C++ Version 6.2 using the library shipped with Compaq C++
Version 6.3 may result in undefined symbols.
For example, if you compile the following simple program with Version
6.2 and use CXXLINK to link the object file after installing the
Version 6.3 compiler, the following undefined symbols are reported:
#define __USE_STD_IOSTREAM
#include <iostream>
main() {
cout << "hello, world";
}
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, COUT__3STD
%LINK-I-UDFSYM, CXX$LS3STDXNQ13STD41BSCS2D8124H
|
For applications that will relink on the end-user's system, see
Deploying Your Application
in
Using Compaq C++ for OpenVMS Alpha
for information about redistributing C++ Run-Time Library components.
2.2 Compiler Differences
Starting with Version 6.0, the Compaq C++ compiler differs significantly from previous versions. There are several major differences that you should be aware of before using a Version 6.n compiler for the first time. These differences are summarized here. For more detailed information, see
Porting to Compaq C++
in
Using Compaq C++ for OpenVMS Alpha
.
- Language differences
The compiler implements (with some
differences, as described in Section 2.3), the C++ International
Standard, which differs significantly from the language specified in
the ARM (The Annotated C++ Reference Manual, 1991, by Ellis and Stroustrup) and implemented
by the Version 5.n compilers. When switching from a Version
5.n compiler, you might need to modify your source files,
especially if you use the default language mode. In addition, language
changes can affect the run-time behavior of your programs. If you want
to compile existing source code with minimal source changes, compile
using the
/standard=arm
option. See
Porting to Compaq C++
in
Using Compaq C++ for OpenVMS Alpha
.
Note
The installation procedure checks whether a Version 5.3 to 5.6 compiler
is installed on your system. If so, it asks whether you want to save
it, and if so, where. The default save area for a Version 5.6 compiler
is SYS$COMMON:[CXX056].
If you find that Version 6.n requires excessive changes to
your applications even when you use the
/standard=arm
option, or if you encounter problems using the Version 6.n
compiler, you can return to your previous C++ environment by invoking
the command procedure
SYS$COMMON:[CXX0nn]COMPILER_SETUP.COM
|
where nn specifies the version of your previous compiler.
|
- Diagnostic differences
The Version 6.n compiler does
more error checking than Version 5.6 and generates more diagnostics. If
you want the number of diagnostics issued by the Version 6.n
compiler to be similar to Version 5.6, compile with the
/quiet
option. See
Message Control and Information Options
in
Using Compaq C++ for OpenVMS Alpha
.
- Implementation differences
The automatic template instantiation model has been redesigned for the current version. Although code compiled with Version 5.n and 6.n compilers can be combined, you must complete the Version V5.n instantiation process with a V5.n compiler before linking to code compiled with Version 6.n. See
Using Templates
in
Using Compaq C++ for OpenVMS Alpha
.
2.3 Differences Between Compaq C++ and the C++ International Standard
The following items, specified in the C++ International Standard, are
not supported in Version 6.5 but will be supported in a future
version. Details about each item are provided in the indicated sections
of the C++ International Standard document and The C++ Programming Language, 3rd Edition by
Bjarne Stroustrup.
- The
export
keyword for templates (Standard §14, paragraph 6;
Stroustrup §9.2.3)
- No
cname
version of headers provided (Standard §17.4.1.2;
Stroustrup §16.1.2)
Compaq C++ does not currently provide
<cname>
versions of the 18 ISO C library headers because no standard-conforming
mechanism has yet been defined. Once such a mechanism is available, we
plan to use it, rather than have the
<cname>
version incorrectly include the non-
<cname>
version.
The C++ header file inclusion policy for treating ISO C
Library headers specifies that for each of the 18 ISO C headers, C++
should provide a
<cname>
form and a
<name.h>
form. The
<cname>
version defines all the symbols defined by ISO C in the corresponding
<name.h>
header in the
std
namespace. The
<name.h>
header defines all the symbols defined by ISO C in the corresponding
<name.h>
header in both the
std
and global namespace.
Some of the problems are as follows:
- Because C library headers contain many non-ISO C names, it is
impossible to avoid polluting either the
std
namespace, the global namespace, or both. (Remember that the global
namespace is considered a real namespace that must not be polluted.)
Namespace pollution is not only incorrect, it can lead to unexpected
ambiguities.
Consider the following program, which includes
<cname>
and
<types.h>
directly.
#include <cname> // name.h includes types.h & brings it into std::
#include <types.h> // types.h in global namespace
using namespace std;
use something from types // ambiguity
|
- Synchronizing the release of C and C++ headers.
- C++ inherits and must work around bugs in the C headers.
Compaq continues to investigate methods for providing this
functionality in a way that ensures long-term compatibility with
various C and C++ 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
|
2.4 Retirement of CFRONT Language Dialect
The CFRONT dialect was provided for migrating code from the CFRONT compilers to the Compaq C++ compiler. Because it has been over five years since the last CFRONT compiler was released, we are retiring this dialect: it will be removed from the next release of the compiler. If you depend on the CFRONT dialect, please send email to the C++ team at
compaq_cxx@compaq.com
.
3 New Debugger
A new OpenVMS Debugger (kit ADX072, dated 4-Mar-1999) is provided with
this kit and must be installed to debug programs compiled with the
compiler in this release. This debugger solves several problems with
the previous debugger.
Note
The version of the OpenVMS Alpha operating system running on your
computer determines how the ADX072 kit links debugger images when you
run VMSINSTAL. When linked with Version 6.n, the ADX072
debugger does not work correctly on Version 7.n systems. For
example, if you install ADX072 on a Version 6.2 system, and if you
later upgrade that system to Version 7.2, the ADX072 debugger does not
work correctly until you reinstall ADX072.
OpenVMS Alpha releases after Version 6.2 include a debugger that
supports the new C++ capabilities. If you are running OpenVMS Alpha
Version 6.2 or later, consult the OpenVMS New Features Manual
to determine whether you must install the debugger shipped with
Compaq C++.
|
To install the special C++ debugger, invoke VMSINSTAL:
@SYS$UPDATE:VMSINSTAL ADX072 device-name option-list
|
See the
Compaq C++ Installation Guide for OpenVMS Alpha
for additional information.
The C++ debugger GUI image is not installed automatically on
OpenVMS systems that are not running DECwindows Motif or that
run a version earlier than 1.2-4.
If you decide to install Motif or upgrade to Version 1.2-4 or later,
and if you then want to use the debugger GUI, you must perform these
tasks:
- Reinstall the ADX072 kit to create the debugger's GUI image
- Execute a command procedure to install the debugger images and
define the default system debugger
Follow these steps:
If you want the special C++ debugger to be the default debugger
for the system:
- Invoke the command procedure as follows:
@SYS$STARTUP:DEBUG$STARTUP_V72X.COM V72X
|
- Add this line to the system startup procedure:
$ @SYS$STARTUP:DEBUG$STARTUP_V72X.COM V72X
|
- On OpenVMS systems prior to Version 6.2A, copy the
resource file:
$ COPY DECW$SYSTEM_DEFAULTS:CXXVMSDEBUG.DAT -
DECW$SYSTEM_DEFAULTS:VMSDEBUG.DAT
|
Note that C++ Version 6.n does not run on any OpenVMS
versions prior to Version 6.2.
If you do not want the special C++ debugger to be the default
debugger for the system:
- Invoke the command procedure as follows:
@SYS$STARTUP:DEBUG$STARTUP_V72X.COM VMS
|
- Add this line to the system startup procedure:
$ @SYS$STARTUP:DEBUG$STARTUP_V72X.COM VMS
|
4 Release Notes for the C++ Compiler
The following sections describe enhancements, changes, and restrictions
for the C++ compiler environment.
4.1 Enhancements, Changes, and Problems Corrected in Version 6.5
Enhancements, changes, and problems corrected are as follows:
- Improved conformance to the C++ International Standard
- Improved code optimization
- Retirement of CFRONT dialect announced
4.2 Restrictions and Known Problems in Version 6.5
If you compile and link with /MODEL=ANSI and then try to use the VMS
debugger to access members of a virtual base class, you might see this
error:
%DEBUG-E-INTERR, debugger error in DBG$GET_BASE_CLASS_OFFSET: can't find __bptr
or session corruption
|
The error is displayed because the debugger has not yet been updated to
understand the new internals of the ANSI object model.
4.3 Enhancements, Changes, and Problems Corrected in Version 6.3
Enhancements, changes, and problems corrected are as follows:
- In
strict_ansi
mode, the name of a class is now entered as a member of itself, as
required by clause 9 (para 2) of the Standard; this behavior is
implemented more or less as an implicitly declared member typedef and
might cause some existing programs to fail. For example:
namespace std {
class iterator {};
}
struct tree
{
struct iterator {};
struct nested : public std::iterator
{
// Compaq C++ 6.2 and below thinks this is tree::iterator
// Compaq C++ ?? in strict_ansi mode thinks this is std::iterator
nested(const iterator&);
};
};
|
[6613]
- The error "incompatible parameter", issued when there is a
difference in sign between pointers, has been made discretionary. As a
result you can now reduce/increase the severity of this message or
enable/disable it using its error tag
incompatibleprm
or its error number. The same can also be done by enclosing the
offending code in #pragma. For Example, the error message for the
following program can now be controlled.
void f(unsigned int *i) {
}
void main() {
f((int *)0x05);
}
|
In addition, specifying
-std gnu
reduces the message severity to warning.
- The undocumented operator
char*()
, which converts a
String
to a pointer to
char
in the non-standard
String
class has been conditionalized with the macro
__DEC_STRING_COMPATIBILITY
so that it is available only when the program is compiled with the
macro defined.
This operator has been conditionalized beccause it
allows passing a
String
object to functions like
istream::get()
or
istream::getline()
that expect a pointer to
char
.
The
String::operator char*()
returns a pointer to the "data component" of the
String
, which is a private data member inside the
String
class. When a
String
object is passed to a function expecting a pointer to
char
, the function cannot determine how much memory has been allocated by
the
String
, and the
String
cannot determine the status of the exposed pointer and the memory to
which it points.
This design flaw in the non-standard
String
class has been fixed in a way that leaves the legacy functionality
available as an option. The standard ANSI C++
String
class, for example, lets users retrieve only a
const char*
, not a
char*
, to the pointer owned by the
String
. [10.1563]
- In response to user requests, CXXLINK by default now deletes the
option file SYS$DISK[]CXX_REPOSITORY.OPT that previously remained in
the user's current directory on completion of CXXLINK.
To support
this change, CXXLINK creates a unique prefix for the repository .OPT
filename in the following format:
For example, if the node name is MYNODE and the PID is 020204AEA, the file name would be MYNODE020204AEA.OPT. This option file is created in the [.CXX_REPOSITORY] directory, if one exists. If the [.CXX_REPOSITORY] directory does not exist, the .OPT file is created in the user's current directory. CXXLINK passes this file to LINK as the second file specified on the LINK command. To preserve LINK's directory search order, the directory specification of the first file is prefixed to the name of the second file, if a second file is specified. Depending on the CXXLINK option selected, CXXLINK deletes this .OPT file by default, or renames it to CXX_REPOSITORY.OPT or to a user-specified file name. For detailed information on CXXLINK options, type HELP CXXLINK or point your browser to
CXXLINK
. [7135]
- In Version 6.2, signaling of VMS exceptions or a C signal might
cause a program to terminate with
%CXXL-F-TERMINATE
status regardless of which VMS exception or C signal has been raised
and regardless of whether a VMS exception handler or C signal handler
has been established.
For example, the following
test1.cxx
program calling
lib$stop(SS$_MCNOTVALID)
terminates with
%CXXL-F-TERMINATE
:
#include <lib$routines.h>
#include <ssdef.h>
main() { lib$stop(SS$_MCNOTVALID); }
$ run test1
%CXXL-F-TERMINATE, terminate() or unexpected() called
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
...
|
Similarly, the following
test2.cxx
program, establishing a C signal handler to catch a
SIGILL
signal, also terminates with
%CXXL-F-TERMINATE
without a signal handler being invoked:
#include <signal.h>
#include <stdio.h>
static void signal_handler(int x)
{
puts("signal arrived");
}
void main()
{
signal(SIGILL, signal_handler);
raise(SIGILL);
}
|
Version 6.3 corrects this behavior: the C++ run-time environment no
longer issues a call to
terminate()
if a VMS exception (possibly, generated by a
raise()
or
gsignal()
function arrives. Instead, the exceptions is resignaled to the next
exception handler, and the exception is handled properly.
For
example, the
test1.cxx
program now correctly terminates with the OpenVMS condition value
specified in the call to
lib$stop()
as follows:
$ run test1
%SYSTEM-F-MCNOTVALID, device microcode is not valid
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
...
|
And
test2.cxx
now catches the signal and terminates correctly as follows:
$ run test2
signal arrived
$
|
[7550, 8234]
- The compiler can no longer generate machine code listing when
requested to not produce object files. [8448]
- CXXLINK no longer incorrectly concatenates arguments passed to it
if such arguments are defined as logical names. [8467]
- CXXLINK now correctly handles filenames when using extended ODS-5
file parsing. [8626]
- In the ANSI object model (/model=ansi), string literals are treated
as pointers to const char (const char *). In the ARM object model
(/model=arm, the default), string literals continue to be treated as
pointers to char (char *). [8659]
- To generate the correct code to make calls to virtual functions
that return a structure, class, or union, the compiler needs the full
definition of the type returned, which is missing in the following code
fragment:
struct Cities;
struct Storage {
int x;
virtual Cities visit() = 0;
};
struct Reader : virtual Storage {
Cities visit();
};
struct T2 : Reader {
};
extern void ggg(Storage *);
void fff(void) {
Storage *s = new T2();
s-x = 23;
ggg(s);
}
|
Because the complete definition for the type Cities is missing, the
compiler cannot correctly generate the code that allows
ggg()
to call
s-visit()
for all possible definitions of the type Cities. Previous compiler
versions generated code that worked for some definitions of Cities but
not for others.
The current version of generates a diagnostic when
it encounters a situation:
virtual Cities visit() = 0;
...................^
%CXX-E-INCTYPPREVIRTAB, The incomplete type Cities precludes correct
generation of the virtual table for the type Reader.
Supply the complete type definition for Cities or use
/MODEL=ANSI.
at line number ... in file ...
|
If you provide the definition of the type Cities in the module that
generates this diagnostic, the compiler can generate the correct code.
This code generation problem has been corrected in the ANSI object
model. It could not be corrected in the ARM object model because an
model incompatibility would have resulted. [8668]
4.4 Restrictions and Known Problems in Version 6.3
If you compile and link with /MODEL=ANSI and then try to use the VMS
debugger to access members of a virtual base class, you might see this
error:
%DEBUG-E-INTERR, debugger error in DBG$GET_BASE_CLASS_OFFSET: can't find __bptr
or session corruption
|
The error is displayed because the debugger has not yet been updated to
understand the new internals of the ANSI object model.
4.5 Enhancements, Changes, and Problems Corrected inVersion 6.2A
Enhancements, changes, and problems corrected are as follows:
- The compiler now generates code that reports a static data member
as an undefined symbol at link time if the data member is referenced
but not defined. [CXXC_BUGS 6826]
- The new cxxlink design implemented in Version 6.2 to use .olbs
instead of objects is not a general solution. The default behavior of
cxxlink was changed back to using objects (
/prelink=use_object_files
) and the switch
/prelink=use_olb
was added to obtain the new mechanism. The new mechanism was simplified
for better performance. No attempt is made to try alternative link
methods if the link fails; the default link must be used. [6804, 6795,
6583, 5997]
- In the C++ Version 6.1 compiler, some objects might have their
exception unwinding information set to a negative index in the cleanup
table. This condition generates the following message:
Unexpected dtor_block_tag in do_dtor_cleanup
|
[7091]
4.6 Enhancements and Changes in Version 6.2
This release solves several problems in earlier versions of the
compiler and includes an updated OpenVMS debugger (dated 4-Mar-1999)
that solves problems with the previous debugger.
Enhancements and changes are as follows:
- Support for explicit template function arguments.
- Improved EV6 support.
- CXXLINK creates an object library.
CXXLINK now creates an
object library (CXX$LINK.OLB) in the writeable repository directory.
The object library is populated with all object files found in the
repository.
CXXLINK also checks any other repository directory
listed on the command line (by use of
/REPOSITORY= qualifier
) for CXX$LINK.OLB object libraries.
Each object library is then
used as input to the OpenVMS Linker through LNK$LIBRARY logical names.
In most cases, the OpenVMS Linker can resolve any missing
instantions by searching the object libraries. CXXLINK can then proceed
directly to the final link, without having to parse the linker output
looking for unresolved symbols and their matching object files.
Note the following restrictions:
- CXXLINK makes use of the OpenVMS Linker Utility's LNK$LIBRARY
logical names to reference specific object libraries as input to the
linker. If the CXXLINK command includes any form of the
/USERLIBRARY
, an informational message appears, and CXXLINK lists any required
object libraries in a linker options file.
- CXXLINK always creates and repopulates the object library. For
large repositories, this mechanism is slower than processing the linker
output and creating the linker options file listing each object file.
- CXXLINK does not create the CXX$LINK.OLB file in nonwritable
repository directories. Currently, this must be done outside of CXXLINK
by entering the command:
$ LIBRARY/CREATE non-writeable-repository-dirCXX$LINK.OLB -
non-writeable-repository-spec*.OBJ
|
- Programs that use
extern_model
can encounter problems, because object files from an object library do
not produce the same
extern_model
code that is generated when the object file is used directly.
- Modules that use
extern_model
must be listed separately as an input to the linker.
- A compiler crash caused by a label statement in a switch statement
has been corrected. [6614]
- If a user calls
VAXC$ESTABLISH
or
LIBC$ESTABLISH
in a function with a try/catch, the establish routine now works correctly. Note that C++ exception handling is disabled in these routines, as described in
C++ Exceptions, lib$establish and vaxc$establish
in
Using Compaq C++ for OpenVMS Alpha
.
- The compiler has implemented the
_poppar
builtin function and added code to convert output type for
_poppar
,
_popcnt
,
_leadz
, and
_trailz
to match contents of the new OpenVMS
builtins.h
file. See
Built-In Functions
in
Using Compaq C++ for OpenVMS Alpha
.
- SCA Version 4.6-4 and later can import C++ cross reference data
into its analysis data file. To import the data, follow these steps:
- Enter the command
CXX/XREF filename.cxx
to have compiler emit the cross reference data file
filename.xref
.
- Enter the command
SCA/IMPORT filename.xref
to generate
filename.ana
, the analysis data file.
- Because of a bug introduced in Version 6.0, the compiler emitted a
union
layout incompatible with earilier versions if the union contained
bitfield of size 8, 16, 24... up to the size of the type for the
bitfield. For example:
typedef struct size4 {
union {
unsigned ttn :8;
struct {
unsigned incr :3;
unsigned rep :5;
} v1;
} u;
} size4;
|
The size of
size4
is 4 bytes for Version 5.7, and was incorrectly set to 1 since Version
6.0. This bug is fixed in V6.2. If you have such a bitfield in your
code, you must recompile. [6567]
- A problem with
/extern_model=strict_refdef
using template static data members and inline functions has been fixed.
Previously, the compiler reported multiply defined external errors for
symbols starting with
__SDG
and
__LSG
. When creating shared images, these symbols must be put in the symbol vector of the shared image. For more information, see
Sample Code for Creating OpenVMS Shareable Images
in
Using Compaq C++ for OpenVMS Alpha
. [6506]
- A template class name can now be reused as a non-template class in
a private namespace without generating an error message. [6541]
- Mangled names beginning with
CXXL$
and
DECC$
are now included in the demangler database and can be demangled. [6458]
- More cases of unreachable code are now diagnosed. If you receive
warnings you believe to be inappropriate, please report them. [6534]
- The compiler no longer can exhaust virtual memory when computing
the addresses of deeply nested virtual base classes. [6473]
-
va_start
now handles
parmN
arguments of types that are promoted. [6471]
- Some compiler-generated wrapper functions with the
__STF____default_version
prefix were not resolved in template automatic instantiation mode. The
problem is corrected. [6362]
- Debugging support for constant variables is improved. Although the
compiler does not generate debug information for constant externs
(because you might not be able to link), it does generate debug
information for all constant variables whose underlying type is
int
or
float
- Bad code is no longer generated for an array reference within a
template instantiation. [6394]
- Runtime type identification has been corrected for shared images.
The RTTI calls
dynamic_cast
and
typeid
now work for objects created inside OpenVMS shared images.
With this correction, the name of virtual function tables have been
changed to
__vtbl2__<class>
, to prevent the new virtual function tables that point to RTTI
information from conflicting with old tables. [6348]
- Debugging support is now provided for anonymous union variables
inside namespaces. In the following example, debuggers support
referencing
s.a
and
s.b
:
struct S {
union {
int a;
int b;
}
} s;
|
In the following example, the compiler generates two variables,
x
and
y
, which the debuggers can examine.
union {
int x;
char y[4];
};
|
The compiler no longer generates tag names for tagless structs and
unions.
- Under the following conditions, the compiler could generate code
that returned the value of
i
before the store of the new value:
- Take the address of a variable, using a type other than the variable's type,
(p = (char *)&i)
.
- Assign to the variable using a pointer addition expression,
*(p + 0) = new_value
.
- Fetch the variable's value directly
(return i)
.
The problem could occur only if the store using the pointer
addition expression appeared within an
if
statement, as in the following:
int f(int flag) {
int len = 1;
if (flag) {
char *ppp = (char *)&len;
*(ppp + 0) = 2;
};
return len;
}
|
The problem has been corrected. [6421]
- The compiler no longer generate incorrect code for offsets to
external arrays. [6386]
- The routine for
new[]
now calls
delete[]
if an exception occurs during construction. [6243]
- Many improvements have been made to cross-reference information
generated by the compiler and read by the SCA tool.
- The compiler now replaces embedded line feeds with blank spaces
during the initial scan.
4.7 Restrictions in Version 6.2
This release is not totally compatible with previous versions; source
changes might be required. The following general restrictions apply for
the current release:
- The C++ International Standard permits overriding a virtual member
function based only on a derived class return type. The current release
does not support this capability.
- Instantiating function templates with array types can result in
different external name encoding than with C++ Version 5.n. To
avoid link errors, recompile the template definition with the current
version of the compiler.
- Specifying a different long double size than the default size for
your version of the operating system (using the
/l_double_size
qualifier) does not work correctly with the Standard Library.
4.8 Enhancements and Changes in Version 6.0
This section briefly summarizes changes and enhancements made in
Version 6.0, including problems fixed.
- Support for the C++ International Standard (with some differences,
as described in Section 2.3), including the C++ Standard Library. See
Section 5 for information on and changes to the Standard Library.
- An updated debugger (dated 6-Jan-1999) that fixes problems with the
previous version of the debugger.
- Language mode options For compatibility with previous versions, the
compiler supports an ARM language mode and provides both
/standard=ansi
and
/standard=arm
language mode options, as well as options to support other C++ dialects. For details, see
Porting to Compaq C++
in
Using Compaq C++ for OpenVMS Alpha
.
- Improved automatic instantiation of templates, including:
- Fewer restrictions. In particular, Compaq C++ no longer requires
that template declarations and definitions appear in header files.
- Build-time performance improvements that further reduce build times
for applications that use templates extensively.
For details, see
Using Templates
in
Using Compaq C++ for OpenVMS Alpha
.
- Language feature options
The compiler supports the following
options:
- Performance optimization options
Version 6.0 provides the
following performance optimization options:
- /[no]ansi_alias
- /assume=[no]pointers_to_globals
- /assume=[no]trusted_short_alignment
- /assume=[no]whole_program
For details, see
Performance Optimization Options
in
Using Compaq C++ for OpenVMS Alpha
.
5 Release Notes for the C++ Standard Library
This section describes the enhancements, problems corrected, and restrictions for the C++ Standard Library. For information about the Compaq C++ Class Library, See
Appendix A
in in
Using Compaq C++ for OpenVMS Alpha
.
The current version of Compaq C++ implements the new Standard Library
string class, known as the String Library. Do not
confuse this class with the String Package, which is part of
the Compaq C++ Class Library implemented in earlier versions of
Compaq C++.
Note that portions of the ANSI C++ Standard Library have been
implemented in Compaq C++ using source licensed from and copyrighted
by Rogue Wave Software, Inc. Information pertaining to the C++ Standard
Library has been edited and incorporated into Compaq C++
documentation with permission of Rogue Wave Software, Inc. All rights
reserved.
Portions copyright 1994-2002 Rogue Wave Software, Inc.
Thread Safety
The Standard Library provided with this release is thread safe but not
thread reentrant. Thread safe means that all library internal and
global data is protected from simultaneous access by multiple threads.
In this way, internal buffers as well as global data like
cin
and
cout
are protected during each individual library operation. Users, however,
are responsible for protecting their own objects.
According to the C++ standard, results of recursive initialization are
undefined. To guarantee thread safety, the compiler inserts code to
implement a spinlock if another thread is initializing local static
data. If recursive initialization occurs, the code deadlocks even if
threads are not used.
5.1 Enhancements and Changes, and Problems Corrected in Version 6.5
Enhancements, changes, and problems corrected are as follows:
- The library header and template definition files have been modified
to compile in STRICT_ANSI mode with the Version 6.5 compiler.
Modification was necessary because Version 6.5 enforces more stringent
language rules in some cases than previous versions. [10.1649]
- The
deallocate()
member function of the allocator class in the
<memory>
header has been modified so that
operator delete
is not called with the null pointer. Although calling
delete
with the null pointer is legal in Compaq C++, the Third Degree tool
on Tru64 UNIX issues a warning when such a call is made. The
modification was made to avoid the warning. [10.1657]
5.2 Enhancements and Changes, and Problems Corrected in Version 6.3
Enhancements, changes, and problems corrected are as follows:
- In
basic_istream
and
basic_ostream
, sentry constructor has been modified to not create the guard object
if the stream is
tie()
'ed to a stream using the same streambuf object. This eliminates the
mutex deadlock which can occur in a multithreaded application.
[10.1641]
With this modification, the following program no longer
hangs when compiled with
/define=DEADLOCK
and linked against the PTHREAD library.
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include <iostream>
int main() {
ostream x(std::cout.rdbuf());
ostream y(std::cout.rdbuf());
#ifdef DEADLOCK
y.tie(&x);
#endif
y << "Hello, world" << std::endl;
return 0;
}
|
- To ensure thread safety, the
basic_string
reference count used to be protected by a mutex, which called thread locking and unlocking routines. Performance of this class in multithreaded applications has been improved by changing the implementation to use instead atomic builtins (see
Appendix B
in
Using Compaq C++ for OpenVMS Alpha
). [10.1138]
- Undefined symbols from the Standard Library no longer occur when
using the
/names=as_is
qualifier. [10.1158]
- On OpenVMS Alpha Version 7.0 and above, the Standard Library
headers now include
pthread.h
to implement multithread safety. Currently this has the side effect of
polluting the global namespace with non-reserved macro and
typedef
names such as EXCEPTION, THROW, CATCH, and so on from
<pthread_exception.h>
. This problem has been acknowledged as a defect and is being
investigated In the meantime, if you are using any of these names you
must change them or devise a workaround.
For example, if you have:
#include <vector>
#define CATCH 42 // trying to define your own macro, but get redefinition error
|
you would need to make the following change:
#include <pthread.h>
#undef CATCH // undef the pthread macro
#include <vector>
#define CATCH 42 // define your own macro
|
[10.1205]
- The string extraction operator no longer removes the extra space at
the end of the string, as in the following example
ifstream inFile("input.dat"); // input.dat contains "abc de"
inFile >> word; // read "abc"
inFile.get(ch1); // ch1 should be space, was 'd'
|
[10.1300]
- The
basic_string::find_first_not_of(charT, size_type)
function now works correctly if the string contained embedded nulls.
[10.1316]
- In Version 6.2,
basic_ostream::flush()
did not always flush the buffer if the type of the stream was an
fstream
. The buffer is now always flushed. [10.1348]
- Compiling a program in
-std strict_ansi
mode using the
basic_fstream
class no longer causes run-time seg faults or core dumps. [10.1357]
- When using the Standard Library iostreams for interactive input to
cin
from a terminal, a user may have to type more than one Ctrl D to
indicate end-of-file. [10.1413]
- The
iostreams
and
locales
are now multi-thread safe. [10.1429]
- Currently you might encounter compilation errors if you try to use
a user-defined allocator and pointer class with the STL containers.
This problem will be fixed in a future release. [10.1430]
- The Standard Library vector class now allocates space correctly for
elements greater than 1024 bytes; runtime core dumps caused by
incorrect allocation in previous versions no longer occur. [10.1459]
- The tree data structure, which sets and maps usage, has been
refined to decrease the amount of space allocated for small element
size containers. [10.1475]
- The standard library headers no longer include
pthread.h
or
tis.h
. They can therefore be used in conjunction with the macro
_PTHREAD_USE_D4
(DECthreads POSIX 1003.4a/Draft 4 (or d4) interface). [10.1540]
- The following functions have been added to
basic_filebuf
class:
bool __sync_with_device() const;
// Returns the value of _RWsync_with_device flag.
|
bool __sync_with_device(bool state);
// Sets the value of _RWsync_with_device flag and returns
// the previous value of the flag.
|
These functions are not described in the C++ standard, and are
provided as an extension in order to control the behaviour of
basic_ostream::flush()
method and
std::endl
and
std::flush
manipulators. The functions are available only on OpenVMS systems.
If
_RWsync_with_device
flag is true, and if the type of the stream is an
fstream
, the
basic_ostream::flush()
function transfers all buffered data to the device as if the C Run-Time
Library
fsync()
function were called.
If
_RWsync_with_device
flag is false, it is not guaranteed that
basic_ostream::flush()
function or
std::endl
or
std::flush
manipulators will flush the data all the way to the device.
To
maintain compatibility with the behaviour of the Standard Library
shipped with the Compaq C++ Version 6.2 compiler, the default value of
_RWsync_with_device
flag is false. The following example shows how the new functions are
used.
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include <fstream>
#include <stat.h>
int main(void)
{
const char * filename = "file.dat";
std::ofstream testfile(filename);
struct stat buf;
// display file synchronization state
cout << "1? file synchronization state is: " <<
testfile.rdbuf()->__sync_with_device() << std::endl;
// write a record to the file
testfile << "x" << std::endl;
// check file size. Expected zero because by default endl
// manipulator does not force data to be transferred to
// the device.
stat(filename, &buf);
cout << "file size is: " << buf.st_size << std::endl;
// set _RWsync_with_device flag to TRUE and display
// previous file synchronization state
cout << "file synchronization state is: " <<
testfile.rdbuf()->__sync_with_device(1) << std::endl;
// write another record to the file
testfile << "y" << std::endl;
// check file size. Expected four because now std::endl
// will cause data to be transferred to the device.
stat(filename, &buf);
cout << "file size is: " << buf.st_size << std::endl;
return 0;
}
|
[10.1574]
5.3 Enhancements and Changes, and Problems Corrected in Version 6.2A
Enhancements, changes, and problems corrected are as follows:
- Fix for
raw_storage_iterator
assignment operator
In versions 6.2 and earlier, a problem in the
assignment operator for the class
raw_storage_iterator
could cause a run-time seg fault if, for example, you called the
algorithm
stable_sort()
more than once with the same container. The problem has been corrected.
[10.1284]
- Fix for
basic_string::compare()
member functions
In version 6.2, two of the
basic_string::compare()
member funrtions were throwing an exception if the length of the second
string was longer than the length of the current string. This has been
fixed so that they throw an exception only if the position the user
specifies within the second string is greater than the length of the
second string. [10.1298]
- Fix for
basic_string::resize()
A problem in the
basic_string::resize()
member function in Version 6.2 has been corrected. The incorrect
behaveior was that if two strings pointed at the same underlying
char*
, and the
resize()
function was called on one of them, and if you then you changed the
underlying string for one string, the value for the other strings value
would also be changed. [10.1287]
- Fix to string assignment operator when assigning string with
embedded nulls
A problem in the
basic_string
assignment operator prevented strings containing embedded nulls from
being copied correctly. The problem has been corrected. [10.1238]
5.4 Enhancements and Changes in Version 6.2
The following enhancements and changes are included in Version 6.2:
- Cleaner header file inclusion policy
The new version of the
Standard Library is much more effecient than previous versions in its
header inclusion policy. For example, the header file
<algorithm>
no longer includes
<functional>
.
<ostream>
and
<istream>
no longer include
<locale>
. Programs that used to count on these inclusions might break. You can
correct them by explicitly including any header files you use in your
own sources.
- New interface to
get_temporary_buffer
and
use_facet
Because the Version 6.2 C++ compiler now supports explicit template
function arguments, it also supports the standard interface to the
get_temporary_buffer()
function. The following example shows how code must change:
Change
this:
get_temporary_buffer(len,(T*)0); // two arguments
|
to this:
get_temporary_buffer<T>(len); // one argument
|
where "T" is the value type of the container.
The standard
interface to the
locale
class
use_facet()
function is also now supported. The following example shows how code
must change:
Change this:
use_facet(loc,(ctype<char>*)0);
|
to this:
// use_facet only takes one argument
use_facet<ctype<char> >(loc);
|
- Smaller executables for users of the
basic_string
library component
The Standard Library now provides a better
separation of the STL and Standard IO components. As a result, users of
the
basic_string
component of the Standard Library should obtain smaller executables. In
Version 6.1, using only a string in an application caused all
iostream
and
locale
object files from the Standard Library to be included in the
executable. These unnecessary files are no longer included. A
correction to the Standard Library helps programmers users of just the
basic_string
component to obtain smaller executables. In the previous version, using
just a string in an application caused the
iostream
and
locale
object files from the Standard Library to be included in the
executable. The new version corrects that problem.
5.5 Problems Corrected in Version 6.2
The following problems are corrected in Version 6.2:
-
money_get
/
money_put
locale
facets now conform to International C++ Standard
The
money_get
and
money_put
locale
facets have been corrected to match the standard. In the previous
version, for example,
money_get
appeared as:
template <class charT,
bool Intl = false,
class InputIterator = istreambuf_iterator<charT> >
class money_get;
|
They now correctly match the standard, where the interface appears
as:
template <class charT,
class InputIterator = istreambuf_iterator<charT> >
class money_get;
|
Note that the second template argument "Intl" has been removed. The
member functions
get()
and
put()
now accept
Intl
as an argument.
-
ios_base::openmode
flags set to conform to the International Standard
The Standard
Library file stream classes have been corrected to conform to the
International Standard with regard to setting the
ios_base::openmode
flags. In the previous release, it was possible to create a file for
reading and writing with this code:
#define __USE_STD_IOSTREAM
#include <stdlib.h>
#include <fstream>
int main() {
fstream fs("foo.out", ios_base::in | ios_base::out);
fs << "abc" << endl;
return EXIT_SUCCESS;
}
|
In the current release, this code works only if the file already
exists. If the file does not exist, you must also specify
ios_base::trunc
; that is, you must change the first line
in main()
to:
fstream fs("foo.out", ios_base::in | ios_base::out
| ios_base::trunc);
|
This conforms to table 92 in the Standard, which specifies the "C"
equivalent of the File open modes.
- Correction to
list::sort(Compare)
A bug in the
list::sort(Compare comp)
member function is corrected. Previously, if users supplied their own
Comparison
function object for the element of the list, the compiler issued a
message stating that it required an operator< defined for the
element type. This no longer occurs.
-
reverse_iterator
now matches the Standard
reverse_iterator
has been changed to match the standard. It now takes only one template
argument of type
iterator
instead of five. Users must change existing code to remove the
additional unnecessary arguments.
-
bitset
constructors no longer accept a
const char
A bitset can no longer be constructed with a
const char*
argument. For example, the following no longer compiles:
bitset<32> b("111111111");
|
The constructor that takes a string is a templatized constructor,
and thus can perform type deductions only on exact matches, not
conversions (for example,
const char*
to string). To make the code in the previous example compile with the
current version, the argument must be explicitly cast to a string, as
follows:
bitset<32> b( string("111111111"));
|
-
assign(size_t)
removed from
vector
,
deque
,
list
Previous releases of the Standard Library contained a member
function called assign() inside the
vector
,
deque
, and
list
classes. This function accepted only a
size_t
argument. This has been removed, because it is not in the Standard. You
must add an extra argument indicating the value you want assigned. For
example, you change calls like the following:
v.assign(5); // where v is a vector<int>
|
to:
-
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.
5.6 Restrictions in Version 6.2
This section describes problems you might encounter when using the
current release of the C++ Standard Library with the Compaq C++
compiler. Where appropriate, workarounds are suggested.
- Do not use Standard Library template definition file names.
The C++ Standard Library supplies the following template definition files in SYS$LIBRARY:CXXL$ANSI_DEF.TLB:
|
algorithm.cc
|
fstream.cc
|
streambuf.cc
|
vector.cc
|
time.cc
|
|
bitset.cc
|
ios.cc
|
locimpl.cc
|
string.cc
|
ctype.cc
|
|
istream.cc
|
numbrw.cc
|
tree.cc
|
collate.cc
|
messages.cc
|
|
complex.cc
|
iterator.cc
|
ostream.cc
|
valarray.cc
|
money.cc
|
|
deque.cc
|
list.cc
|
sstream.cc
|
valimp.cc
|
numeral.cc
|
|
rwlocale.cc
|
|
|
|
|
If you use the same prefix name for any of your local files and have the directory that contains them in your include search path, the automatic instantiation mechanism picks up your local copy and does not find the library files. (See
Automatic Template Instantiation
in
Using Compaq C++ for OpenVMS Alpha
.)
It is best not to use any of these names as source file names
for your application.
- Redeclaration of Standard Library Functions
Many of the
prototypes in the Standard Library have been changed to conform to the
C++ International Standard by the addition of exception specifications.
This means that if you have redeclared the declarations in your own
code, you need to add the correct exception specification in order to
match what is declared in the header.
For example:
#include <new.h>
// override default operator new
// this will give an error
inline void* operator new(size_t s);
|
To prevent this behavior, you must change your
new()
declaration to:
inline void* operator new(size_t s) throw(bad_alloc);
|
- Files/Macros for internal use only
Compaq C++ Version
6.n ships the following non-Standard headers for Compaq
internal use only. Their contents are subject to change and can not be
relied on.
<stdcomp>, <stl_macros>, <stddefs>, <compnent.hxx>,
<stdmutex>, <stdexcept>, <lochelp>, <locimpl>, <locimpl.cc>,
<valimp>, <valimp.cc>, <vendor>, <codecvt>, <codecvt.cc>,
<collate>, <collate.cc>, <ctype>, <ctype.cc>, <locvector>,
<math>, <messages>, <messages.cc>, <money>, <money.cc>,
<numeral>, <numeral.cc>, <random>, <rwcats>, <rwlocale>,
<rwlocale.cc>, <rwstderr>, <rwstderr_macros>, <string_ref>,
<time>, <time.cc>, <traits>, <usefacet>
|
In addition both Standard and non-Standard headers make use of
macros beginning with
_RW
or
__RW
. These
_RW
* and
__RW
* macros are for Compaq internal use only. They are subject to change
and can not be relied on.
- Pre-ANSI iterators no longer available
The following classes
are no longer in the ANSI draft standard and should not be used:
input_iterator
output_iterator
forward_iterator
bidirectional_iterator
random_access_iterator
|
The functionality of these classes is now provided by the single
class iterator, which is templatized on the iterator category.
-
ctype_base::graph
In the current implementation of the
ctype_base
class, a character has a 'graph' property if and only if it also has an
'Alpha', a 'digit' or a 'punct' property. Thus, mathematical and
scientific symbols and dingbats from the UNICODE character set will not
be classified properly.
- IOStreams cannot output IEEE NaNs/Infinities
The Standard
IOStreams library does not support output for IEEE NaNs and Infinities.
-
ios_base::out
does not truncate a file to zero length
The
ios_base::openmode ios_base::out
should open a file for output. This means that the file is either
truncated to zero length if it exists or created for writing if it does
not. Therefore
ios_base::out
is the same as
ios_base::out
|
ios_base_trunc
.
With our sources, the following program behaves incorrectly.
#include <stdlib.h>
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
fstream fs ("t.in",ios_base::out);
fs << "A";
return EXIT_SUCCESS;
}
|
Where
t.in
contains xyz.
After running this program,
t.in
contains
It should contain
You can work around this problem by replacing
ios_base::out
with
ios_base::out
|
ios_base::trunc
.
- Specifying a different
l_double_size
than the default size for your particular version of the operating
system does not work correctly with the standard library.
- Input and output to and from long double types on when specifying
/L_DOUBLE_SIZE=64
does not work if you use standard iostreams. This restriction will be
lifted in a future release.
- Overriding
operator new()
or
operator delete()
You can define a global
operator new()
or
operator delete()
to displace the versions used by the C++ Standard Library or C++ Class Library. For instructions, see
Overriding operator(new)
in
Using Compaq C++ for OpenVMS Alpha
.
- The
/template_define
and
/template_define=all
options are not guaranteed to work with the Standard Library. Specify
/template_define=used
instead.
When compiled with
/template_define
or
/template_define=all
, the following code generates compilation errors indicating that no
operator "<" (and ">" or "+" or "-") matches these operands:
#include <map>
map<int,int> foo;
|
The instantiation options are not guaranteed to work with the
Standard Library because they request the compiler to instantiate all
templates, even those that are not used.
The
/template_define=all
option does not work because
rb_tree
, the underlying implementation of
map
and
set
supports a bidirectional iterator class. Thus,
operator+
,
operator-
,
operator<
and
operator>
are not defined in the iterator for that class.
When you
instantiate the tree with
cxx /template_define=all
or
cxx /template_define
, the compiler attempts to instantiate recursively everything that is
typedef
ed, even if not used. Thus, the tree contains a
typedef
for
std::reverse_iterator<iterator>
, which then instantiates the global class
reverse_iterator
with the tree iterator as the template argument
RandomAccessIterator
, a misnomer in this case.
This behavior generates undefined
symbols for these operators because they are used within the definition
of the operator member functions inside
reverse_iterator
. The compiler therefore attempts to instantiate them even though they
do not exist.
Specifying
/template_define=used
for the Standard Library directs the compiler to only instantiate those
templates that are used.
- Description of the initial state of the
stringstream Ctor
There has been some controversy in the
comp.lang.c++
reflector and within the standards committee on the semantics of the
stringstream
constructor. Consider the following example:
#define __USE_STD_IOSTREAM
#include <stdlib.h>
#include <sstream>
int main() {
ostringstream ost("Hello, ");
// ost.rdbuf()->pubseekoff(0,ios::end,ios::out);
ost << "world!";
cout << ost.str() << endl;
return EXIT_SUCCESS;
}
|
Depending on the setting of the
streambuf put
pointer after the initial construction, the program could print either
"Hello, world!" or "world!". The Rogue Wave (and
Compaq C++) interpretation is that the
stringstream
constructor does not change the initial position of the
streambuf
pointer, so that the program prints "world!".
If you want
to change the setting of the
put
pointer to match the other interpretation (that the pointer should move
to the end of the initializer string), you must insert a call to
pubseekoff()
, as shown in the commented line.
If the ANSI C++ committee issues
a clarification on this matter Compaq C++ will implement their
decision.
-
basic_string
ambiguities
If you declare a
basic_string
of
int
you might encounter ambiguities in the constructors,
append
,
assign
,
insert
, and
replace
member functions. For example, if you write:
#include <stdlib.h>
#include <string>
int main() {
basic_string<int> si (5,0);
return EXIT_SUCCESS;
}
|
Compilation errors result from the overload resolution between
integral and iterator types. The constructors involved are the
following:
// construct n elements and initialize with value
basic_string(size_type n, charT c,
const Allocator& a = Allocator());
// construct using iterator ranges
template<class InputIterator>
basic_string(InputIterator begin, InputIterator end,
const Allocator& a = Allocator());
|
The compiler matches on the constructor
basic_string(InputIterator begin, InputIterator end, ...)
because
size_type
a
size_t
is an unsigned
int
on OpenVMS Alpha systems. So you have:
basic_string(unsigned int, int, ...) vs.
basic_string(int, int,...)
|
The second constructor is the better match, but it is undesirable
because we are not constructing via iterator ranges.
The workaround
is to avoid matching on iterator types by casting integral arguments.
So for example, the previous program would compile correctly if the
size argument were cast to a
size_t
:
#include <stdlib.h>
#include <string>
int main() {
basic_string<int> si ((size_t)5,0);
return EXIT_SUCCESS;
}
|
- Restartable/non-restartable conversion routines in Locale classes
In
codecvt
class from localization library, the C++ standard assumes availability
of restartable conversion routines such as
mbrtowc
,
wcrtomb
, and so forth.
These routines. introduced by ISO C Amendment 1: C
Integrity, were implemented in OpenVMS Alpha Version 6.2A and were never
ported back to the previous version.
Because restartable conversion
routines are unavailable, the C++ Standard Library on OpenVMS
Version 6.2 uses their non-restartable counterparts such as
mbtowc
,
wctomb
and so forth.
Note that restartable versions of conversion routines
are functional only when used with locales that support state-dependent
codeset encoding. Currently, neither the OpenVMS Alpha nor the Tru64
UNIX operating system provides any locales based on a
state-dependent codeset.
With a codeset that is not
state-dependent, both restartable and non-restartable conversion
routines behave exactly the same. Therefore, using non-restartable
conversion routines instead of restartable ones does not constitute any
lack of functionality of C++ Standard Library on OpenVMS
Version 6.2.
-
cxxlink
errors with heavily templatized applications
When linking an
application that uses many templates, cxxlink might report and error
indicating that no I/O channels are available. For example:
$ cxxlink test
%LINK-F-OPENIN, error opening
T4:[TEST.CXX_REPOSITORY]CXX$CTQ173DGTWRTRB0K
64LIR.OBJ;1 as input
-RMS-F-CHN, assign channel system service request failed
-SYSTEM-F-NOIOCHAN, no I/O channel available
|
This error is generated when the process of linking all of an
application's template instantiations requires more open files than the
underlying system can support. In C++ Version 6.n, automatic
template instantiation occurs at compile time (not link time as in
previous versions. Automatic template instantiation files are therefore
written into a repository as object files during compilation. Cxxlink
then invokes the OpenVMS linker to link each instantiation
file into the application.
To work around this problem, you must
allocate sufficient system resources to handle an extended number of
open files. You might need to increase the SYSGEN parameter CHANNELCNT,
which specifies the number of permanent I/O channels available to the
system. You might also need to increase the following process quotas:
open file quota (
fillm
)
buffered I/O quota (
biolm
)
page file quota (
pgflquo
)
enqueue quota (
enqlm
)
-
cxxlink
might fail with many large template instantiations
If you have many
large template instantiations in your source file, the cxxlink command
may fail with the following message:
%LINK-F-OPENIN, error opening <some repository> as input
-RMS-E-ACC, ACP file access failed
-SYSTEM-F-EXBYTLM, exceeded byte count quota
|
To work around this limit, you must increase your Buffered I/O byte
count quota, which you can see by entering the command SHOW
PROCESS/QUOTA. Ask your system administrator to use the Authorize
utility to increase the size. The recommended value is 199296.
- C++ Class Library dependencies on the Standard Library
As of
Version 6.0, the Class Library has dependencies on the Standard
Library. The dependencies have to do with incompatible name mangling
changes made between Version 5.n and Version 6.0 to address
Version 5.n name mangling problems. In all cases, entry points
to the Version 6.0 mangled names are available in the Version 6.0
Standard Library. This means that all Version 6.0 programs (even those
using only the Class Library) should be linked with the Standard
Library either with
cxxlink
or by adding
sys$library:libcxxstd.olb
to your link command. Using
cxxlink
is recommended.
The following specific dependencies require support
from the Standard Library:
- Class library routines that use an ios::seek_dir type input
parameter:
istream::seekg()
ostream::seekp()
streambuf::seekoff()
filebuf::seekoff()
strstreambuf::seekoff()
stdiobuf::seekoff()
- In Version 5.n, the mangled name for an
enum
nested in a class did not contain the class name. This was corrected in
Version 6.0. Version 6.0 provides a switch (
/distinguish_nested_enums
) that allows you to compile programs amd generate either a Version
5.n or Version 6.0 style mangled name.
Because support for
the routines with Version 6.0 mangling resides in the Standard Library,
Version 6.0 programs making use of the above routines compiled using
/distinguish_nested_enums
must link with the Standard Library either with
cxxlink
or by inclusion of
sys$library:libcxxstd.olb
on the link line.
- Class Library inserter/extractor routines that accept
__int64
type parameters.
In Version 5.n, the mangled name for a
routine accepting an
__int64
parameter differed from the mangled name for a routine accepting a
long long
. This problem was corrected for Version 6.0 on OpenVMS.
Because support for the routines with Version 6.0 mangling resides in
the Standard Library, Version 6.0 programs making use of such routines
in code like the following
ifstream instream ("t.dat");
__int64 s_value
unsigned __int64 u_value
...
cout << u_value;
instream >> s_value;
|
must link with the Standard Library either with
cxxlink
or by inclusion of
sys$library:libcxxstd.olb
on the link line.
- Access violation when using Standard Library version of
cout
cin
, and other standard streams inside static constructors
If you are
using the standard iostreams library (if you have defined the macro
__USE_STD_IOSTREAM
) , and if you attempt to use
cout
,
cin
,
cerr
,
clog
,
wcout
,
wcin
,
wcerr
, or
wclog
in a static constructor, a core dump occurs.
For example:
#include <ostream>
using namespace std;
struct C { C(); };
C::C() {
cout << "hello world"; // cout not initialized here
}
C c1;
int main() {}
|
To work around the problem, must modify your
cxxlink
step as follows:
- Create an options file,
image_name.opt
, whose content is
SYS$SHARE:LIBCXXSTD/INCLUDE=CXXL_STD_INIT
- Modify your cxxlink command to be:
$ CXXLINK/EXE=programname.exe image_name.opt/opt,[rest of command]
|
- Compilation warnings and errors with
auto_ptr
Using
auto_ptr
in non
strict_ansi
mode generates warnings about initializing a non-const ref with an
lvalue
. These warnings are due to the lack of enforcement of the rule in the
C++ standard that binding a reference to a non const to a class
rvalue
is illegal. To make
auto_ptr
work correctly, you must compile the module(s) that use
auto_ptr
s in
ansi
or
strict_ansi
language mode.
In
strict_ansi
mode, you may still encounter compilation errors when converting an
auto_ptr<Derived>
to an
auto_ptr<Base>
. For example, this does not work:
struct Base {};
struct Derived : Base {};
auto_ptr<Derived> source2() {return auto_ptr<Derived>(new Derived);}
int main() {
auto_ptr<Derived> d;
auto_ptr<Base> b(d); // compiles
auto_ptr<Base> p3(source2()); // doesn't compile
return 0;
}
|
This is a known deficiency of the
auto_ptr
class, see language issue 84 at:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/core-issues.htm
|
for a discussion of the problem. You must either use casts or
avoid temporaries under these conditions.
Remember that you should
not use
auto_ptr
s as elements of an STL container, because they do not meet the
CopyConstructible
and
Assignable
requirements for Standard Library container elements. Compilation
warnings occur if, for example, you try to insert an
auto_ptr
into a container. See
http://www.gotw.ca/gotw/025.htm
|
and
http://www.awl.com/cseng/titles/0-201-63371-X/auto_ptr.html
|
for discussions of the history and current restrictions of the
auto_ptr
class.
5.7 Enhancements and Changes in Version 6.0
The C++ Standard Library provided with this release defines a complete
specification (with some differences as described in Section 2.3) of
the C++ International Standard. The Standard Library in this release
includes for the first time the ANSI
locale
and
iostream
libraries.
Tutorial programs illustrating functionality found in the standard C++
library including the
locale
,
iostream
, and STL classes shipped with this release can be found in:
SYS$SYSROOT:[SYSHLP.EXAMPLES.CXX]*.CXX
|
You can compile and run these programs and use them as models for your
own coding. The expected output for each program can be found in:
SYS$SYSROOT:[SYSHLP.EXAMPLES.CXX]*.RES
|
Version 6.0 introduces the following major enhancements and changes. For detailed information about the Compaq C++ Standard Library, refer to
Using Compaq C++ for OpenVMS Alpha.
Additional changes include the following:
- Specific changes to match the C++ International Standard
-
iterator_traits::distance_type
now
iterator_traits::difference_type
The name of the
typedef
inside the classes
iterator_traits
and
iterator
that specifies the type of the result when two iterators are subtracted
has been changed from
distance_type
to
difference_type
.
-
typedef
name changes in
iterator
classes
The names of some of the typedefs in the
reverse_iterator
and
reverse_bidirectional_iterator
classes have changed as follows:
iter_type
is now
iterator_type
reference_type
is now
reference
pointer_type
is now
pointer
distance_type
is now
difference_type
-
slice/gslice
classes member function
length()
name change
The member function
length()
in the
slice
and
gslice
classes has changed its name to
size()
.
-
has_denorm
data member of the
numeric_limits
class changed
The
has_denorm
data member of the numeric_limits class,
<limits>
, has been updated.
has_denorm
is changed from type
bool
to an
enum
type
float_denorm_style
to reflect that support for denormalized values might not be detectable
at compile time. The
float_denorm_style
type looks like this:
namespace std {
enum float_denorm_style {
denorm_indeterminate = -1;
denorm_absent = 0;
denorm_present = 1;
};
}
|
The values representing the presence or absence of denorms are as
follows:
denorm_indeterminate
: cannot determine if type supports denormalized at compile time
denorm_absent
: the type does not support denormalized values
denorm_present
: the type supports denormalized values
- Default allocator value for
map
and
multimap
has changed
The default value for the template argument
Allocator
in map and multimap was changed from
allocator<T>
to
allocator<pair<const Key, T> >
.
- Interface Change for STL
distance()
function
Because the V6.0 compiler now supports partial
specialization of class templates, the interface to the
distance()
algorithm has been updated to conform to the latest C++ standard. This
means that previously, if you made a call to
distance
, the result was returned by using a reference argument for the third
argument:
// pre 6.0 the result was returned in d
distance(first,last,d);
|
Beginning with V6.0, the result is returned in the return type:
d = distance(first,last); // 6.0
|
You must therefore change all your calls to
distance()
.
- Support for
long long
and unsigned
long long
types.
The non-ANSI standard types
long long
and unsigned
long long
are now supported in the Standard Library iostreams as well as being
valid types for
numeric_limits
specializations and as types for which
destroy()
specializations are provided. For example, you can now say:
long long l;
cout << l << endl; // compiles without error
|
Note that these types are not supported in the
/standard=strict_ansi
compiler mode.
long long
and
unsigned long long
are also supported in the
iostream
class library in the default compiler mode.
- Common Instantiation Libraries no longer needed
Because Version
6.0 uses compile time rather than link time template instantiation,
there is no use for common instantiation libraries and we have
therefore not supplied any
build_common_instantiation_library
script. See the discussion of templates in
Using Compaq C++ for OpenVMS Alpha
.
|
