Jump to 
content
HP.com Home Products and Services Support and Drivers Solutions How to Buy
»  Contact HP

 

HP C++

HP C++
User's Guide for OpenVMS Systems


Previous Contents Index


Chapter 7
The C++ Standard Library

The C++ Standard Library provided with this release defines a complete specification of the C++ International Standard, with some differences, as described in the C++ release notes.

Note that portions of the C++ Standard Library have been implemented in HP 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 HP C++ documentation with permission of Rogue Wave Software, Inc. All rights reserved.

Some of the components in the C++ Standard Library are designed to replace nonstandard components that are currently distributed in the Class Library. HP will continue to provide the Class Library in its nonstandard form. However, you now have the option of using new standard components.

This chapter provides more information on the HP C++ implementation of the Standard Library, including upward compatibility, compiling, linking, and thread safety. Small example programs showing how to use the C++ standard library are located in the directory SYS$COMMON:[SYSHLP.EXAMPLES.CXX] .

The following are Standard Library qualifiers introduced with HP C++ Version 6.0:

/[NO]USING_STD

Controls whether standard library header files are processed as though the compiled code were written as follows:


     using namespace std; 
     #include <header> 

These qualifiers are provided for compatibility for users who do not want to qualify use of each standard library name with std:: or put using namespace std; at the top of their sources.

/USING_STD turns implicit using namespace std on; this is the default when compiling /STANDARD=ARM, /STANDARD=MS, or /STANDARD=RELAXED.

/NOUSING_STD turns implicit using namespace std off; this is the default when compiling /STANDARD=STRICT_ANSI.

/ASSUME=[NO]STDNEW

Controls whether calls are generated to the ANSI or pre-ANSI implementation of the operator new() . On memory allocation failure, the ANSI implementation throws std::bad_alloc , while the pre-ANSI implementation returns 0.

/ASSUME=STDNEW generates calls to the ANSI new() implementation; this is the default when compiling with /STANDARD=RELAXED and /STANDARD=STRICT_ANSI.

/ASSUME=NOSTDNEW generates calls to the pre-ANSI new() implementation; this is the default when compiling with /STANDARD=ARM and /STANDARD=MS.

/ASSUME=[NO]GLOBAL_ARRAY_NEW

Controls whether calls to global array new and delete are generated as specified by ANSI. Pre-ANSI global array new generated calls to operator new() . According to ANSI, use of global array new generate calls to operator new()[] .

/ASSUME=GLOBAL_ARRAY_NEW generates calls to operator new()[] for global array new expressions such as new int[4] ; this is the default when compiling /STANDARD=RELAXED, /STANDARD=STRICT_ANSI, and /STANDARD=MS.

/ASSUME=NOGLOBAL_ARRAY_NEW generates calls to operator new() for global array new expressions such as new int[4] and preserves compatibility with Version 5.n; this is the default when compiling /STANDARD=ARM. .)

7.1 Important Compatibility Information

On Alpha systems, because the standardization process for the C++ Standard Library is not yet completed, HP cannot guarantee that this version of the library is compatible with any past or future releases. We ship the run-time portion of the library in object form, not in shareable form, to emphasize this situation. (ALPHA ONLY)

On I64 systems, the standard library is distributed as a system shareable image SYS$LIBRARY:CXXL$RWRTL.EXE, and also in object form in the system object library STARLET.OLB. (I64 ONLY)

The following sections describe specific compatibility issues.

7.1.1 /[NO]USING_STD Compiler Compatibility Qualifier

All standard library names in HP C++ are inside the namespace std . Typically you would qualify each standard library name with std:: or put using namespace std; at the top of your source file.

To make things easier for existing users, using namespace std; is included in a file provided with every standard library header when you are in ARM, MS, or RELAXED compiler modes. This is not the default in STRICT_ANSI mode.

The compiler supplied qualifiers /NOUSING_STD and /USING_STD can be used to override the default. /NOUSING_STD turns the implicit using namespace std off; /USING_STD turns it on.

7.1.2 Pre-ANSI/ANSI Iostreams Compatibility

The C++ Standard Library offers support for the standard iostream library based on the C++ International Standard. As defined by the standard, iostream classes are in the new header files <iostream> , <ostream> , <istream> , and so on (no .h or .hxx extension).

For backward compatibility, the pre-ANSI iostream library is still provided. The two libraries exhibit subtle differences and incompatibilities.

Users can choose which version (ANSI or pre-ANSI) of iostreams they want to use; either version of iostreams can be integrated seamlessly with the new Standard Library and string functionality.

To accomplish this goal, macros called __USE_STD_IOSTREAM and
__NO_USE_STD_IOSTREAM are provided. If you do not set these macros explicitly, the default in ARM, MS, and RELAXED modes is to use the pre-ANSI iostream library. In STRICT_ANSI mode, the default is to use the ANSI iostream library.

Note that for the most part, support for pre-ANSI iostreams is contained in headers with .h or .hxx extensions. This is not the case for iostream.h/iostream.hxx , fstream.h/fstream.hxx , strstream.h/strstream.hxx , and iomanip.h/iomanip.hxx . In these cases, the iostream library provided is controlled solely by the /STANDARD compilation choice and use of __USE_STD_IOSTREAM/__NO_USE_STD_IOSTREAM .

You override the default by defining __USE_STD_IOSTREAM or
__NO_USE_STD_IOSTREAM on either the command line or in your source code.

In ARM, MS, and RELAXED modes, specify use of the ANSI iostreams in one of the following ways:

  • Enter /DEFINE=(__USE_STD_IOSTREAM) on the command line.
  • Put the following in your source file before any include files:


    #ifndef __USE_STD_IOSTREAM 
    #define __USE_STD_IOSTREAM 
    #endif 
    

In STRICT_ANSI mode, specify use of the pre-ANSI iostreams in one of the following ways:

  • Enter /DEFINE=(__NO__USE_STD_IOSTREAM) on the command line.
  • Put the following in your source file before any include files:


    #ifndef __NO_USE_STD_IOSTREAM 
    #define __NO_USE_STD_IOSTREAM 
    #endif 
    

You receive a #error warning if

  • you compile in a mode indicating you want ANSI behavior; that is, /STANDARD=STRICT_ANSI,
  • you enter a header with a .h or .hxx (for example, #include <iostream.h> ).

You can avoid the error by compiling with /DEFINE=(__NO_USE_STD_IOSTREAM).

Many of the other headers, <string> for example, make use of the iostream classes. The default version of iostreams that is automatically included when you include one of these headers depends on the mode you compile in and the setting of the macros __USE_STD_IOSTREAM and __NO_USE_STD_IOSTREAM as described earlier.

Because the standard locale class and the standard iostream class are so closely tied, you cannot use the standard locale class with the pre-ANSI iostream classes. If you want to use locale, you must use the ANSI iostream classes.

It is possible to use the pre-ANSI and the ANSI iostream library in the same source file, because all the standard iostream names (that is, cout , cin , and so on) are in namespace std , and all the pre-ANSI names are in the global namespace. This is not recommended, though, because there is no guarantee of stream objects being the same size or, for example, of ::cout being in sync with std::cout .

Nevertheless, if you want to combine them, you must recognize that the underlying ANSI iostream is called iostream_stdimpl.hxx and that the pre_ANSI header is called iostream_impl.hxx . The following example shows how to include a pre-ANSI header before and ANSI header:


  #include <stdlib.h> 
  #undef __USE_STD_IOSTREAM 
  #include <iostream_impl.hxx> 
  #define __USE_STD_IOSTREAM 
  #include <iostream_stdimpl.hxx> 
 
  int main() 
  { 
    std::string s("abc"); 
    ::cout << "abc" << endl;         // pre-standard iostreams 
    std::cout << "abc" << std::endl; // standard iostreams 
    return EXIT_SUCCESS; 
  } 

If you include an ANSI iostreams header before a pre-ANSI iostreams header, follow these steps:

  1. Compile your source using /NOUSING_STD.
  2. Use the __USE_STD_IOSTREAM macro as shown in the following example. You must define __USE_STD_IOSTREAM at the end of your include file list so that the template definition files (the .cc files) are included in the correct mode.


      // Compile this with /nousing_std 
      #include <stdlib.h> 
      #define __USE_STD_IOSTREAM 
      #include <iostream_stdimpl.hxx> 
      #undef __USE_STD_IOSTREAM 
      #include <iostream_impl.hxx> 
      #define __USE_STD_IOSTREAM // so the template definition files are ok 
     
      int main() 
      { 
        std::string s("abc"); 
        ::cout << "abc" << endl; // pre-standard iostreams 
        std::cout << "abc" << std::endl; // standard iostreams 
        return EXIT_SUCCESS; 
      } 
    

7.1.3 Support for pre-ANSI and ANSI operator new()

The Standard C++ Library supports the ANSI implementation of the operator new() as well as the pre-ANSI implementation of operator new() . The ANSI implementation throws std::bad_alloc on memory allocation failures.

The pre-ANSI implementation of the operator new() returns 0 on memory allocation failures. Because the ANSI behavior is incompatible with pre-ANSI applications, a compile time qualifier has been added (/ASSUME=[NO]STDNEW) to control whether calls to ANSI new() or pre-ANSI new are generated.

The following examples show how ANSI versus pre-ANSI new() check for memory allocation. First, here is an ANSI new() check for memory allocation failure:


            try { 
                myobjptr = new (myobjptr); 
            } 
            catch (std::bad_alloc e) { 
                cout << e.what() << endl; 
            }; 

The following example shows a pre-ANSI new() check for memory allocation failure:


            if ((myobjptr = new (myobjptr)) == 0) 
                call_failure_routine(); 

When upgrading pre-ANSI new() code to work with the C++ Standard Library you also can use the nothrow version of ANSI new() . To do so in the pre-ANSI example, you could recode it as follows:


            if ((myobjptr = new (myobjptr, nothrow)) == 0) 
                 call_failure_routine(); 

Two command line qualifiers are available in the compiler to control whether calls are generated to the ANSI or pre-ANSI implementation of operator new() :

  • Use the /ASSUME=STDNEW qualifier to generate calls to the ANSI new() implementation.
  • Use the /ASSUME=NOSTDNEW qualifier to generate calls to the pre-ANSI new() implementation. You can override global new() by declaring your own functions.

When compiling with /STANDARD=RELAXED or /STANDARD=STRICT_ANSI, /ASSUME=STDNEW is the default.

When compiling with /STANDARD=ARM and /STANDARD=MS, /ASSUME=NOSTDNEW is the default. The compiler defines the macro __STDNEW when the /ASSUME=STDNEW qualifier is specified.

7.1.4 Overriding operator new() (ALPHA ONLY)

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

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

Compiling with /ASSUME=STDNEW

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


          #include <new> 
    ... 
    using namespace std; 
     
    // Redefine global operator new(), 
    // entry point into C++ Standard Library based on 
    // compiling /assume=stdnew.  This also overrides user 
    // calls to operator new(). 
    void *operator new(size_t size) throw(std::bad_alloc) { 
      printf("in my global new\n"); 
      ... 
      void *p = malloc(size); 
      return(p); 
    } 
     
    // redefine global operator delete() 
    void operator delete(void  *ptr) throw() { 
      free (ptr); 
    } 
     
    // entry point into C++ Class Library 
    #ifdef __MODEL_ANSI 
    extern "C" void *__7__nw__FUi(size_t size) { 
    #else  // __MODEL_ARM 
    extern "C" void *__nw__XUi(size_t size) { 
    #endif 
      printf("in my new\n"); 
      return ::operator new(size); 
    } 
    

Compiling with /ASSUME=NOSTDNEW

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


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

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


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

    where AVMS_NOSYSSHR.OPT is:


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

    Linking /NOSYSSHR is the only way to override calls to new() and delete() in the C++ Class Library and C++ Standard Library.
    If the set_new_handler() function is referenced when overriding operator new() and delete() , "multiply defined" linker warnings will result. To remove these warnings, the set_new_handler() function must also be overridden. Using set_new_handler() when the operator new() and delete() functions are being overridden, requires that the set_new_handler() function be defined in terms of the user provided operator new() and delete() functions.

7.1.5 Overriding operator new() (I64 ONLY)

Overriding operators new and delete has been simplified on I64 systems. If user code overrides any of the new and delete operators, the compiler and library picks up the overridden versions without any other changes to the source code or the command line. Changes such as those described for Alpha systems in Section 7.1.4 are unnecessary and will not work on I64 systems.

7.1.6 Support for Global array new and delete Operators

HP C++ Version 6.n and higher fully supports the array new and delete operators as described in the ANSI standard. Previous versions did not.

You might therefore encounter a compatibility problem if you have overridden the run-time library's operator new() with your own version.

For example:


#include <stdlib.h> 
#include <iostream.h> 
 
inline void* operator new(size_t s) { 
 cout << "called my operator new" << endl; 
 return 0; 
} 
 
int main() { 
 new int;    // ok, this still calls your own 
 new int[4]; // In V6.0 calls the C++ library's operator new[] 
        return EXIT_SUCCESS; 
} 

In older versions, both new int and new int[4] would generate a call to operator new() (they would just be asking for different sizes). With the current compiler, new int still generates a call to operator new() . However, new int[4] generates a call to operator new()[] . This means that if you still want to override the library's operator new you must do one of the following:

  1. Provide your own definition of operator new()[] .
  2. Use the /ASSUME=NOGLOBAL_ARRAY_NEW qualifier.

The /ASSUME=NOGLOBAL_ARRAY_NEW qualifier converts all expressions such as new int[4] to calls to the global operator new() , thus preserving compatibility with older compiler versions.

Note that this qualifier has no effect on class-specific array operator new and delete ; it affects only the global operators.

When compiling with /STANDARD=RELAXED or /STANDARD=STRICT_ANSI, and /STANDARD=MS modes, /ASSUME=GLOBAL_ARRAY_NEW is the default.

When compiling with /STANDARD=ARM, /ASSUME=NOGLOBAL_ARRAY_NEW is the default. A macro __GLOBAL_ARRAY_NEW is predefined by the compiler when /ASSUME=GLOBAL_ARRAY_NEW is used.

7.1.7 IOStreams Expects Default Floating-Point Format

The C++ standard library IOStreams expects floating-point values in the default floating-point format for each platform: G_FLOAT on Alpha systems and IEEE on I64 systems. Using standard library IOStreams for processing floating-point values in a different format (for example, in a program compiled /FLOAT=IEEE on Alpha or /FLOAT=G_FLOAT on I64) is not supported. The C++ class library does not have this restriction.

7.2 How to Build Programs Using the C++ Standard Library

Building programs that use the C++ Standard Library requires the following changes in usage of the C++ compiler and linker commands:

  • The CXX command line no longer needs to include the /ASSUME=NOHEADER_TYPE_DEFAULT qualifier because this is now the default.
    Similarly, the command line no longer needs to include the /TEMPLATE=AUTO qualifier because the compiler performs automatic template instantiation by default.
  • On Alpha systems, to link a program that uses the C++ Standard Library, you must use the CXXLINK command in place of the LINK command. The CXXLINK command continues the automatic template instantiation process, includes the Standard Library run-time support (SYS$LIBRARY:LIBCXXSTD.OLB) at link time, and creates the final image. See Section 1.3 for more details. (ALPHA ONLY)
    On I64 systems, to link a program that uses the C++ Standard Library, you must use either the CXXLINK facility or OpenVMS Linker. See Section 1.4 for more details. (I64 ONLY)
    For example, to build a program called prog.cxx that uses the Standard Library, you can use the following commands:


    $ CXX  prog.cxx 
    $ CXXLINK prog.obj 
    

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.

7.3 Optional Switch to Control Buffering (ALPHA ONLY)

The inplace_merge , stable_sort , and stable_partition algorithms require the use of a temporary buffer. Two methods are available for allocating this buffer:

  • Preallocate 16K bytes of space on the stack.
  • Allocate the required amount of storage dynamically.

By default, the current HP C++ Standard Library makes use of the preallocated buffer, which avoids the overhead of run-time allocation. If your application requires a buffer that exceeds 16K, it cannot take advantage of this default.

If you are concerned with minimizing the use of stack space in your program, or if your application requires a buffer that exceeds 16K, define the __DEC_DYN_ALLOC macro to enable dynamic buffering. Do this by adding the following to your compile command line:


/DEFINE=__DEC_DYN_ALLOC 

7.4 Enhanced Compile-time Performance of ANSI Iostreams

To speed the compile-time performance of programs that use the standard iostream and locale components, the Standard Library includes many common template instantiations of these components

To force programs to create instantiations at compile-time (for example, if you want to debug them and thus need them to be compiled with the /DEBUG qualifier), define the macro __FORCE_INSTANTIATIONS (ALPHA ONLY) on the command line by specifying /DEFINE=(__FORCE_INSTANTIATIONS). This definition suppresses the #pragma do_not_instantiate directives in the headers so that the compiler creates the instantiations in your repository directory.

You must then specify the /REPOSITORY= qualifier to force the compiler to link your instantiations instead of those in the Standard Library.

7.5 Using RMS Attributes with iostreams

The standard library class fstream constructors amd open() member function do not support different RMS attributes, for example, creating a stream-lf file.

To work around this restriction, use the C library creat() or open() call, which returns a file descriptor, and then use the fstream constructor, which accepts a file descriptor as its argument. For example:


 
#define __USE_STD_IOSTREAM 
#include <fstream> 
 
int main() 
{ 
  int fp; 
 
  // use either creat or open 
  //if ( !(fp= creat("output_file.test", 0, "rfm=stmlf")) ) 
 
  if ( !(fp= open("output_file.test", O_WRONLY | O_CREAT | O_TRUNC , 0, 
"rfm=stmlf")) ) 
    perror("open"); 
 
  ofstream output_file(fp); // use special constructor, which takes 
                            // a file descriptor as argument 
  // ... 
} 
 

Note that this coding is not allowed if you compile with /STANDARD=STRICT_ANSI, because the constructor in the example is an extension to the C++ standard interface.

7.6 Upgrading from the Class Library to the Standard Library

The following discussion guides you through upgrading the Class Library code to use the Standard Library, specifically replacing the vector and stack classes in the vector.hxx header file to the Standard Library vector and stack classes.

7.6.1 Upgrading from the Class Library Vector to the Standard Library Vector

To change your code from using the Class Library vector to the Standard Library vector, consider the following actions:

  • Change the name of your #include statement from <vector.h> or <vector.hxx> to <vector> .
  • Remove the vectordeclare and vectorimplement declarations from your code.
  • Change all vector(type) declarations to vector<type> . For example, vector(int) vi should become vector<int> vi .
  • The following member functions are replaced in the Standard Library:
    Nonstandard Vector Function Standard Library Vector Function
    elem(int index) operator[](size_t index)
    (no bounds checking)
    operator[](int index) at(size_t index)
    (bounds checking)
    setsize(int newsize) resize(size_t newsize)
  • When copying vectors of unequal lengths, note that the Standard Library vector has a different behavior as follows:
    When using the Standard Library vector, if the target vector is smaller than the source vector, the target vector automatically increases to accommodate the additional elements.
    The Class Library vector displays an error and aborts when this situation occurs.
  • Note that another difference in behavior occurs when you specify a negative index for a vector.
    The Class Library vector class detects the negative specification and issues an error message. However, the Standard Library vector silently converts the negative value to a large positive value, because indices are represented as type size_t (unsigned int) rather than int .
  • When an out-of-bounds error occurs, the Class Library vector prints an error message and aborts, whereas the Standard Library vector throws an out-of-range object.

7.6.2 Upgrading from the Class Library Stack to the Standard Library Stack

To change your code from using the existing stack to the Standard Library stack, consider the following actions:

  • Change the name of your #include statement from <stack.h> or <stack.hxx> to <stack> .
  • Remove the stackdeclare and stackimplement declarations from your code.
  • Change all stack(type) declarations to stack<type, deque<type> > . For example, stack(int) si should become stack<int, deque<int> > si .
  • Do not specify an initial size for a Standard Library stack. The stack must start out empty and grow dynamically (as you push and pop).
  • The following member functions are not supported or have different semantics:
    Class Library Stack Standard Library Stack
    size_used() Does not exist because the size() function always is equal to the size_used() function.
    full() Does not exist because the stack always is full.
    pop() Does not return the popped element. To simulate Class Library behavior, first obtain the element as the return type from the top() function and then call the pop() function. For example, change int i=s.pop(); to the following:
    int i=s.top();
    
    s.pop();
  • The Standard Library stack differs from the Class Library stack in the way errors are detected. Unlike the nonstandard stack, you cannot overflow a Standard Library stack because space is allocated dynamically as you push elements onto the stack.

7.6.3 Upgrading from the Class Library String Package Code

The Standard Library basic_string can replace the Class Library String Package.

The following list guides you through upgrading nonstandard code to use the Standard Library basic_string :

  • Change #include <string.h> or #include <string.hxx> to #include <string> .
  • Change all declarations of String to string (uppercase S to lowercase s).
  • On Alpha systems, when compiling with the __DEC_STRING_COMPATIBILITY macro defined, the String Package allowed assignment of a string directly to a char * ; however, the basic_string library does not allow this. You can assign the string's const char* representation using the c_str() or data() basic_string member functions. For example:


    string s("abc"); 
    char* cp = s; // not allowed 
    const char* cp = s.data(); // ok 
    

    The state of the string is undefined if the result of data() is cast to a non- const char* and then the value of that char* is changed.

  • The String Package member functions upper() and lower() are not in the basic_string library. You can write these functions as nonmember functions, as follows:


    template <class charT, class traits, class Allocator> 
    inline 
    basic_string<charT, traits, Allocator> 
    upper(const basic_string<charT,traits, Allocator>& str) { 
            basic_string<charT, traits, Allocator> newstr(str); 
            for (size_t index = 0; index < str.length(); index++) 
                    if (islower(str[index])) 
                            newstr[index] = toupper(str[index]);  
            return newstr; 
    } 
     
    template <class charT, class traits, class Allocator> 
    inline 
    basic_string<charT, traits, Allocator> 
    lower(const basic_string<charT,traits, Allocator>& str) { 
            basic_string<charT, traits, Allocator> newstr(str); 
            for (size_t index = 0; index < str.length(); index++) 
                    if (isupper(str[index])) 
                            newstr[index] = tolower(str[index]);  
            return newstr; 
    } 
    

    Then instead of calling upper() and lower() as member functions of the basic_string , pass the string as an argument. For example:


    s2 = s1.upper(); // does not compile 
    s2 = upper(s1); // ok 
    

  • The String Package match() member function does not exist. Equivalent functionality exists in the Standard Library algorithm mismatch() , although using it is more complicated. For example:


    string s1("abcdef"); 
    string s2("abcdgf"); 
    assert(s1.match(s2)==4); // does not compile 
    pair<string::iterator,string::iterator> p(0,0); // ok 
    p=mismatch(s1.begin(),s1.end(),s2.begin()); 
    assert(p.first-s1.begin()==4); 
    string s3 = s1; 
    p=mismatch(s1.begin(),s1.end(),s3.begin()); 
    assert(p.first == s1.end()); // everything matched 
    

  • The String Package index() member function does not exist. The basic_string library equivalent is find() .
  • The String Package constructor that takes two positional parameters (a start and end position) and constructs a new string does not exist. It is replaced in the basic_string library with the member function substr() . For example:


    string s1("abcde"); 
    string s2 = s1(1,3); // does not compile 
    string s2 = s1.substr(1,3); // ok 
    

  • Many previously undetected run-time errors now throw standard exceptions in the String library.

7.6.4 Upgrading from the Class Library Complex to the ANSI Complex Class

Note

On I64 systems, the Class Library Complex package has been removed, so upgrading to the Standard Library complex class is the only option on this platform. (I64 ONLY)

This section explains how to upgrade from the pre-ANSI complex library to the current standard complex library.

In the pre-ANSI library, complex objects are not templatized. In the ANSI library, complex objects are templatized on the type of the real and imaginary parts. The pre-ANSI library assumes the type is double, whereas the ANSI library provides specializations for float, double, and long double as well as allowing users to specialize on their own floating point types.

Mathematical error checking is not supported in the ANSI library. Users who rely on detection of underflow, overflow, and divide by zero should continue using the pre-ANSI complex library.

The following is a detailed list of important changes:

  • Change #include <complex.h> or #include <complex.hxx> to #include <complex> .
  • Change all declarations of complex to complex<double> , for example:


    complex c; 
    

    Change to:


    complex<double> c;  
    

  • The polar() function no longer supplies a default value of 0 for the second argument. Users will have to explicitly add it to any calls that have only one argument, for example:


    complex c; 
    c = polar(c); // get polar 
    

    Change to:


    complex<double> c; 
    c = polar(c,0.0); 
    

  • If you are calling a mathematical function or mathematical operator that takes scalars as arguments ( polar() for example), then you must adjust the arguments you pass in to be the same type as the complex template parameter type. For example, you would have to change:


    complex c = polar(0,0); 
    complex c2 = c+1; 
    

    Change to:


    complex<double> c = polar(0.0,0.0); // 0.0 is double 
    complex<double> c2= c + 1.0; // 1.0 is double 
    

  • The complex_zero variable is not declared in the complex header file. If you want to use it, you will have to declare it yourself. For example, add the following to the top of your source file:


    static const complex<double> complex_zero(0.0,0.0); 
    

  • The sqr() and arg1() functions are gone. If you want to continue to use them, you should define them in one of your own headers, using the following definitions:


    template <class T> 
    inline complex<T> sqr(const complex<T>& a) 
    { 
        T r_val(real(a)); 
        T i_val(imag(a)); 
        return complex<T> 
        (r_val * r_val - 
         i-val * i_val, 
         2 * r_val * -_val); 
    } 
    template <class T> 
    inline T arg1(const complex<T>& a) 
     
    { 
        T val = arg(a); 
     
        if(val > -M_PI && val <= M_PI) 
            return val; 
     
        if(val > M_PI) 
            return val - (2*M_PI); 
     
        // val <= -PI 
        return val + (2*M_PI); 
    } 
    

  • The pow(complex, int) function is no longer provided. You must use pow(complex<double>, double) . This means changing calls such as:


    pow(c,1); 
    

    Change to:


    pow(c,1.0); 
    

    This might yield different results. If the function previously was underflowing or overflowing, it might not continue to happen.

  • The complex output operator (<<) does not insert a space between the comma and the imaginary part. If you want the space, you would need to print the real and imaginary parts separately, adding your own comma and space; that is:


    complex<double> c; 
    cout << "(" << c.real() << ", " << c.imag() << ")"; // add extra space 
    

  • The complex input operator (>>) does not raise an Objection if bad input is detected; it instead sets input stream's state to ios::failbit .
  • Floating point overflow, underflow, and divide by zero do not set errno and will cause undefined behavior. Complex error checking and error notification is planned for a subsequent release.
  • You should no longer need to link your program explicitly with the complex library. It is automatically linked in as part of the Standard Library. However, you must still explicitly link in the C math library, as shown in the following example:


    #include <stdlib.h> 
    #include <complex> 
     
    int main() { 
            complex<double> c1(1,1), c2(3.14,3.14); 
            cout << "c2/c1: " << c2/c1 << endl; 
            return EXIT_SUCCESS; 
            % cxx example.cxx #error 
            % cxx example.cxx -1m #okay 
    } 
    

7.6.5 Upgrading from the Pre-ANSI iostream library to the HP C++ Standard Library

This section explains how to upgrade from the pre-ANSI iostream library to the ANSI iostream library. In this section, pre-ANSI iostreams refers to versions of the iostream library found in the Class Library; ANSI iostreams refers to versions found in the HP C++ Standard Library.

There are a number of differences between the pre-ANSI and ANSI iostream library. One major difference between the pre-ANSI and ANSI iostream library is that the ANSI library is templatized on the object input/output on which operations are being performed. In the pre-ANSI library, iostreams has no templates. The ANSI library also provides specializations for char and wchar_t .

Important differences are as follows:

  • With the current compiler, you access the pre-ANSI iostream library by default in non strict_ansi compiler modes. You can control the version of iostreams you use with the __USE_STD_IOSTREAM and __NO_USE_STD_IOSTREAM macros. If you want to use the ANSI iostream library, do either of the following:
    Enter /DEFINE=(__USE_STD_IOSTREAM) on the command line.
    Put the following in your source file before any include files:


    #ifndef __USE_STD_IOSTREAM) 
    #define __USE_STD_IOSTREAM) 
    #endif 
    

  • Header names are different in the ANSI library, so to use ANSI iostreams, change the iostreams headers you include as follows:
    From To
    #include <iostream.h>
    #include <iostream.hxx>
    #include <iostream>
    #include <fstream.h>
    #include <fstream.hxx>
    #include <fstream>
    #include <strstream.h>
    #include <strstream.hxx>
    #include <strstream>
    #include <iomanip.h>
    #include <iomanip.hxx>
    #include <iomanip>
  • All Standard Library names in the ANSI iostream library are in namespace std . Typically you would qualify each Standard Library name with std:: or put using namespace std; at the top of your source file.
    To facilitate upgrading in all but STRICT_ANSI mode, using namespace std; is set by default. In STRICT_ANSI mode, after including an ANSI iostream header, you must qualify each name inside namespace std individually or do


          using namespace std; 
    

  • In the pre-ANSI iostream library, including <iomanip.h> or <strstream.h> gave you access to cout , cin , and cerr . To access the predefined streams with the ANSI iostream library, make the following changes:
    change
    #include <iomanip.h>
    to
    #include <iomanip>
    #include <iostream>
    #include using namespace std;
    change
    #include <strstream.h>
    to
    #include <strstream>
    #include <iostream>
    using namespace std;
  • The istream::ipfx , istream::isfx , ostream::opfx , ostream::osfx do not exist in the ANSI iostreams. Their functionality is provided by the sentry class found in basic_istream and basic_ostream , respectively.
    Common prefix code is provided by the sentry's constructor. Common suffix code is provided by the sentry's destructor. As a result, calls to ipfx() , isfx() , opfx() , and osfx() have their functionality replaced by construction and destruction of std::istream::sentry objects and std::ostream::sentry object respectively. For example:


    #include <iostream.hxx>           |  #include <iostream.hxx> 
    void func (istream &is)           |  void func (ostream &os) 
    {                                 |  { 
       if (is.ipfx())                 |     if (os.opfx()) 
           ...                        |         ... 
       is.isfx();                     |     os.osfx(); 
    }                                 |  } 
                                      | 
    Would be coded as:                |  Would be coded as: 
                                      | 
    #include <iostream>               |  #include <literal>(<iostream>) 
    void func (istream &is)           |  void func (ostream &os) 
    {                                 |  { 
       istream::sentry ipfx(is);      |     ostream::sentry opfx(os); 
       if (ipfx)                      |     if (opfx) 
          ...                         |        ... 
       //is.isfx(); implicit in dtor  |     //os.osfx(); implicit in dtor 
    }                                 |   } 
    

  • The following macros from the pre-ANSI <iomanip.h> are no longer available in <iomanip> :


    SMANIP, IMANIP, OMANIP, IOMANIP, 
    SAPP,   IAPP,   OAPP,   IOAPP, 
    SMANIPREF, IMANIPREF, OMANIPREF, IOMANIPREF, 
    SAPPREF, IAPPREF, OAPPREF, IOAPPREF 
    

    You can add them yourself, but their use will not be portable.

  • The streambuf::stossc() function, which advances the get pointer forward by one character in a stream buffer, is not available in the ANSI iostream library. You can make use of the std::streambuf::sbumpc() function to move the get pointer forward one place. This function returns the character it moved past. These two functions are not exactly equivalent---if the get pointer is already beyond the end, stossc() does nothing, and sbumpc() returns EOF.


         istream &extract(istream &is) 
         { 
            ... 
            is.rdbuf()->stossc(); 
         } 
    

  • ios::bitalloc() is no longer available in the ANSI iostream library.
  • The filebuf constructors have changed in the ANSI iostream library. The pre-ANSI filebuf class contained three constructors:


        class filebuf : public streambuf 
        { 
           filebuf(); 
           filebuf(int fd); 
           filebuf(int fd, char * p, int len); 
           ... 
        } 
    

    In the ANSI iostream library, filebuf is a typedef for basic_filebuf<char> , and the C++ Working Paper defines one filebuf constructor:


        basic_filebuf(); 
    

    To facilitate backward compatibility, the ANSI iostream library does provide basic_filebuf(int fd) as an extension. However, the use of extensions is not portable.
    For example, consider the filebuf constructors in the following pre-ANSI iostream library program:


    #include <fstream.hxx> 
     
    int main () { 
        int fd = 1; 
        const int BUFLEN = 1024; 
        char buf [BUFLEN]; 
        filebuf fb(fd,buf,BUFLEN); 
        filebuf fb1(fd); 
        return 0; 
    } 
    

    To be strictly ANSI conforming, you would need to recode as follows:


      filebuf fb(fd,buf,BUFLEN); as filebuf fb();  and 
      filebuf fb1(fd); as filebuf fb1(); 
    

    If you want to make use of the ANSI iostream filebuf(fd) extension, you could recode:


      filebuf fb(fd,buf,BUFLEN); as filebuf fb(fd);  and 
      filebuf fb1(fd); as filebuf fb1(fd); 
    

  • The ANSI iostream library contains support for the filebuf::fd() function, which returns the file descriptor for the filebuf object and EOF if the filebuf object is closed as a nonportable extension. This function is not supported under the /STANDARD=STRICT_ANSI compiler mode.
  • The following functions are not defined in the ANSI iostream library. They are provided in the ANSI iostream library for backward compatibility only. Their use is not portable.


        ifstream::ifstream(int fd); 
        ifstream::ifstream(int fd, char *p, int len) 
        ofstream::ofstream(int fd); 
        ofstream::ofstream(int fd, char *p, int len); 
        fstream::fstream(int fd); 
        fstream::fstream(int fd, char *p, int len); 
    

  • The following attach functions, which attach, respectively, a filebuf , fstream , ofstream , and ifstream to a file are not available in the ANSI iostream library:


       filebuf::attach(int); 
       fstream::attach(int); 
       ifstream::attach(int);   
       ofstream::attach(int); 
    

    If you do not want to make use of ANSI iostream library extensions, you must recode the use of attach as follows:
    Change from:


    #include <fstream.hxx>                        
    #include <stdio.h>                             
    #include <fcntl.h>                             
    int main () {                                  
        int fd;                                    
        fd = open("t27.in",O_RDWR | O_CREAT, 0644); 
        ifstream ifs;                              
        ifs.attach(fd);                            
        fd = creat("t28.out",0644);                
        ofstream of;                                
        of.attach(fd);                             
        return 0;                                  
    } 
    

    To:


    #include <fstream> 
    int main () { 
        ifstream ifs("t27.in", ios::in | ios::out); 
        ofstream ofs("t28.out"); 
        return 0; 
    } 
    

  • The ios enumerators for controlling the opening of files, ios::nocreate and ios::noreplace , are not available in the ANSI iostream library.
  • The istream_withassign and ostream_withassign classes are not available in the ANSI iostream library.
  • In the ANSI iostream library ios_base::width() applies to all formatted inserters including operator << (char) . This means that the stream width specified by either the manipulator setw() or the ios_base::width() member function will apply padding to the next output item even if it is a char.
    This was not the case in the pre-ANSI iostream library, where width() applied to all formatted inserters except the char inserter. The reasons for the change (to allow ostream::operator<<(char) to do formatting) are:
    1. It allows operator<< functions to do formatting consistently.
    2. It allows operator<<(char) and put(char) (formatted and unformatted operations on char ) to have different functionality.

    Consider the following example:


    #ifdef __USE_STD_IOSTREAM 
    #include <iostream> 
    #include <iomanip> 
    #else 
    #include <iostream.hxx> 
    #include <iomanip.hxx> 
    #endif 
    int main () { 
        cout.width(10); 
        cout.fill('^'); 
        cout << 'x' << '\n'; 
        cout << '[' << setw(10) << 'x' << ']' << endl; 
        return 0; 
    } 
    

    In the ANSI iostream library the output is:


    ^^^^^^^^^x 
    [^^^^^^^^^x] 
    

    In the pre-ANSI iostream library the output is:


    x 
    [x]^^^^^^^^^ 
    

  • In the pre-ANSI iostream library, printing signed char * or a unsigned char * printed the address of the string. In the ANSI iostream library the string is printed. Consider the following example:


    #ifdef __USE_STD_IOSTREAM 
    #include <iostream> 
    #else 
    #include <iostream.hxx> 
    #endif 
     
    int main () { 
        char * cs = (char *) "Hello"; 
        signed char *ss = (signed char *) "world"; 
        unsigned char *us = (unsigned char *) "again"; 
     
        cout << cs << " " << ss << " " << us << endl; 
        return 0; 
    } 
    

    The output in the ANSI iostream library is:


    Hello world again 
    

    The output in the pre-ANSI iostream library is:


    Hello 0x120001748 0x120001740 
    

    To obtain output equivalent to the pre-ANSI iostreams, you might do the following:


    cout << hex << showbase << (long) ss << " " 
         << (long) us << endl; 
    

  • In the pre-ANSI iostream library printing a signed char prints its integer value. In the ANSI iostream library printing a signed char prints it as a character. Consider the following example:


    #ifdef __USE_STD_IOSTREAM 
    #include <iostream> 
    #else 
    #include <iostream.hxx> 
    #endif 
     
    int main () { 
        signed char c = (signed char) 'c'; 
        cout << c << endl; 
        return 0; 
    } 
    

    The output in the ANSI iostream library is:


    c 
    

    The output in the pre-ANSI iostream library is:


    99 
    

    To obtain output equivalent to the pre-ANSI iostreams, you must do the following:


    cout << (long) c << endl; 
    

  • In the ANSI iostream library, reading invalid floating point input (where invalid input is caused by no digits following the letter e or E and an optional sign) from a stream sets failbit to flag this error state. In the pre-ANSI iostream library, these type of error conditions might not be detected. Consider this program fragment:


        double i; 
        cin >> i; 
        cout << cin.rdstate() << ' ' << i << endl; 
    

    On the input: 123123e
    The output in the ANSI iostream library is:


    4 2.65261e-314          // failbit set 
    

    The output in the pre-ANSI iostream library is:


    0 123123                // goodbit set 
    

  • In the ANSI iostream library, reading integer input (which is truncated as the result of a conversion operation) from a stream sets failbit to flag this overflow condition. In the pre-ANSI iostream library, these types of conditions might not be detected. Consider this program fragment:


        int i; 
        cin >> i; 
        cout << cin.rdstate() << ' ' << i << endl; 
    

    On the input: 9999999999999999
    The output in the ANSI iostream library is:


    4  1874919423       // failbit set 
    

    The output in the pre-ANSI iostream library is:


    0  1874919423       // failbit not set 
    

    In the ANSI iostream library, reading -0 from a stream into an unsigned int outputs 0; this was not the case with the pre-ANSI iostream library. Consider the following:


       unsigned int ui; 
       cin >> ui; 
       cout << cin.rdstate() << ' ' << ui << endl; 
    

    On the input: -0
    The output in the ANSI iostream library is:


    0 0 
    

  • In the ANSI iostream library, the istream::getline() function extracts characters and stores them into successive locations of an array whose first element is designated by s. If fewer than n characters are input, failbit is set. This was not the case in the pre-ANSI iostream library. Consider the following:


    #include <stdlib.h> 
    int main() 
    { 
            char buffer[10]; 
            cin.getline (buffer,10); 
            cout << cin.rdstate() << ' ' << buffer << endl; 
            return EXIT_SUCCESS; 
    } 
    

    With input of: 1234567890
    The output in the ANSI iostream library is:


    4 123456789 
    

    The output in the pre-ANSI iostream library is:


    0 123456789 
    

  • When printing addresses, the ANSI library does not print a leading "0x" to indicate a hexadecimal base. The pre-ANSI library did. Consider the following:


    #include <stdlib.h> 
    #include <iostream> 
    int main() 
    { 
    double d; 
    int i; 
            void *p = (void *) &d; 
            int *pi = &i; 
            cout << (void *) 0 << ' ' << p << ' ' pi << endl; 
            return EXIT_SUCCESS; 
    } 
    

    The output in the ANSI iostream library is:


    0 11fffe7a0 11fffe798 
    

    The output in the pre-ANSI iostream library is:


    0x0 0x11fffdc40 0x11fffdc38 
    

  • basic_filebuf::setbuf is a protected member function in the ANSI iostream library. Therefore, the following longer compiles:


    #include <stdlib.h> 
    int main() { 
       filebuf fb; 
       ... 
       fb.setbuf(0,0); 
       return EXIT_SUCCESS; 
    } 
    

  • In the ANSI iostream library, the Standard C++ streams are synchronized with the Standard C streams by default. Calling sync_with_stdio() with false allows the Standard C++ streams to operate independently of the Standard C streams. In the pre-ANSI iostream library the Standard C++ streams are not synchronized with the Standard C streams by default.
    You notice the consequences of this change if you redirect the output of a program using the Standard C++ streams to a log file by entering the following commands at the DCL prompt:


    $ define sys$output t.out
    $ run program
    $ deassign sys$output
    

    For example, if you write something like this using ANSI iostreams:


    #ifndef __USE_STD_IOSTREAM 
    #define __USE_STD_IOSTREAM 
    #endif 
    #include <iostream> 
    void main () { 
        int s = 5; 
        cout << "i" << s; 
    } 
    

    and if you redirect the output to a log file using the commands shown in the example, the log file contains two records:


    i 
    5     
    

    If you write something like this using pre-ANSI iostreams:


    #include <iostream.hxx> 
    void main () { 
        int s = 5; 
        cout << "i" << s; 
    } 
    

    and if you redirect the output to a log file using the commands shown in the example, the log file contains one record: i5 .
    To obtain the Pre-ANSI iostreams behavior with ANSI iostreams, you can use either of the following workarounds:

    • Redirect your output to a file by entering the following commands:


      $ define/user sys$output t.out
      $ run program
      

      The output of the log file, t.out , contains one record: i5 .

    • Recode your program so that the Standard C++ streams operate independently of the Standard C streams. Do this by calling sync_with_stdio() with a false argument as follows:


      #include <stdlib.h> 
      #ifndef __USE_STD_IOSTREAM 
      #   define __USE_STD_IOSTREAM 
      #endif 
      #include <iostream> 
      int main () { 
          ios_base::sync_with_stdio(false); 
          int s = 5; 
          cout << "i" << s; 
          return EXIT_SUCCESS 
      } 
      

      If you now redirect the output to a log file, the log file contains one record: i5 .


Previous Next Contents Index

Privacy statement Using this site means you accept its terms
© 2007 Hewlett-Packard Development Company, L.P.