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

 

HP C++

HP C++
Using HP C++ for Tru64 UNIX and Linux Alpha


Previous Contents Index


Appendix A
Class Library Restrictions

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

Note also that the task package is not supported on the Linux Alpha platform and will soon be retired from the Tru64 UNIX platform.

The following restrictions apply for the C++ Class Library:

  • Conflict with redefinition of clear()
    If your program includes both <curses.h> and <iostream.hxx> , HP C++ might fail to compile your program because clear() is defined by both header files. In <curses.h> , clear() is defined as a macro whereas in <iostream.hxx> clear() is defined as a member function.
    Workarounds:
    If your program does not use either clear() or uses the <curses.h> clear() , include the <iostream.hxx> header first, followed by <curses.h> .
    If your program uses the ios::clear() function, undefine the clear() macro directly after the #include <curses.h> statement.
  • Because of a bug in the task package, if you are using that package and you compiled your application with HP C++ Version 6.n, your application may encounter runtime errors such as segmentation faults. To avoid these problems, recompile your application specifying the -preempt_symbol option. For more information about the -preempt_symbol option, see the cxx(1) reference page.
  • Use of clog() and the iostream package's clog
    A single application is restricted from using both the math library function clog() and the iostream package's clog object. This restriction is necessary because libm and libcxx each contain a definition for the global symbol clog and these definitions are incompatible.
    For example, consider a program that makes use of the iostream clog object:


         #include <stdlib.h> 
         #include <iostream.hxx> 
         int main() 
         { 
             clog << "abc"; 
             return EXIT_SUCCESS; 
         } 
    

    If you link with the math library first as:


         cxx clog.cxx -lm -lcxx 
    

    Executing the program results in a segmentation fault. The compiler links against shared object libraries by default. Identical symbols in subsequent object libraries are resolved to the first definition by the symbol preemption feature. So in this case use of clog from iostreams is resolved to the definition in libm.
    If you link -non_shared with the math library first as:


        cxx clog.cxx -non_shared -lm -lcxx 
    

    The linker gives a multiply defined message similar to the following:


        ld: 
        /usr/lib/cmplrs/cxx/libcxx.a(iostream_globals.o): clog: multiply defined 
    

    In this case, if you link with the Class Library first, the program executes correctly. As described earlier, the compiler links against shared object libraries by default. Identical symbols in subsequent object libraries are resolved to the first definition by the symbol preemption feature. So in this case use of clog from iostreams is resolved to the definition in libcxx :


         cxx clog.cxx -lcxx -lm 
    

    Therefore, applications that reference either of the clog symbols should not include both -lcxx and -lm on their ld command line.

  • Displacing global operator new in C++ Standard Library/Class Library
    If a C++ program defines a global operator new() that is intended to displace the version used by the C++ Standard Library, it must be compiled with the compiler command line switch -stdnew . If a C++ program defines a global operator new() which is intended to displace the version used by the C++ Class Library, it must be compiled with the compiler command line switch -nostdnew .
  • Restrictions on printing some cases of bool/wchar_t Types with pre-ANSI Library
    Objects of a class which contain a user defined conversion operator to either bool or wchar_t can not be output directly with cout when including <iostream.h> . For example, the following program will give compilation errors indicating that more than one operator "<<" matches these operands:


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

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


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

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


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

  • The Class Library does not include support for 128-bit long doubles.
  • The Class Library has many non-reserved names that are declared in the global namespace. Using any name that that includes the prefixes cxxl_ or decc$ or any of the following names (except as they are intended to be used from the Class Library) at global scope can lead to unpredictable results and should be avoided:
    Mutex String InternalMutex
    Stopwatch iostream ostream
    istream ostream_withassign istream_withassign
    iostream_withassign Iostream_init fstream
    ifstream ofstream streambuf
    strstream ios cout
    cin clog cerr
    lock unlock setfill
    resetiosflags dec hex
    oct endl ends flush
    ws setw smanip_*
    imanip_* omanip_* iomanip_*
    smanipref_* imanipref_* omainpref_*
    iomanipref_* vector stack
    Messages Objection setprecision
    setiosfill    

    If linking with complex: complex
    If linking with task:
    task object sched
    timer qhead qtail
    randint urand erand
    Interrupt_handler histogram  
  • The C++ class library IOStreams does not support denormalized IEEE numbers. The workaround is to to use libc functions like printf and scanf instead.


Previous Next Contents Index

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