MIPSpro C and C++ compilers support directives based on the OpenMP C/C++ Application Program Interface (API) standard. Programs that use these directives are portable and can be compiled by other compilers that support the OpenMP standard.

To enable recognition of the OpenMP directives, specify -mp on the cc or CC command line.

In addition to directives, the OpenMP C/C++ API describes several library functions and environment variables. Information on the library functions can be found on the omp_lock(3), omp_nested(3), and omp_threads(3) man pages. Information on the environment variables can be found on the pe_environ(5) man page.

See the MIPSpro C and C++ Pragmas manual for definitions and details about how to use the OpenMP #pragma directives.

The N32 and 64 compilers implement the array variants of operators new and delete from the draft C++ standard. All calls to allocate and deallocate arrays of objects using new Classname[n] and delete[] Classname go through operators new[] and delete[], respectively, instead of the operators new and delete. This implies the following:

---

Note: If you do not protect these declarations under a macro like the one described in the introduction to this section, you will get compiler errors with the O32 compiler.

---

There is a built-in bool type in the 64 and N32 MIPSpro compilers (but not in the O32 compiler). The keywords true and false are now keywords when bool is supported as a built-in type, having values that are the bool equivalent of 1 and 0, respectively.

To take advantage of this type, which is portable between O32 and the MIPSpro compilers, you can declare a bool type for O32 as follows:

#ifndef _BOOL
/* bool not predefined */
typedef unsigned char bool;
static const bool false = 0;
static const bool true = 1;
#endif /* _BOOL */

The macro _BOOL is predefined to be 1 when the bool keyword is supported.

---

Note: The -LANG:bool=off option in the N32 and 64 compilers can be used to disable the built-in bool, true, and false keywords (in case you have already used any of these identifiers in your program), making it behave like the O32 compiler in this regard.

---

The type wchar_t is a keyword and built-in type in the two MIPSpro compilers. It is analogous to the wchar_t type defined in stddef.h. In fact, this file can be safely included into an N32 or 64 compile and will not interfere with the built-in wchar_t. When the compiler supports wchar_t, it also defines a macro called _WCHAR_T; this allows you to write code that is portable across the O32 and the two MIPSpro compilers.

For instance, you can now read and write wchar_t types directly. They will not be read and written as long types, but will actually be read and written as multi-byte characters during the execution of the program.

Because the built-in wchar_t is considered a distinct type, not a synonym for int or long, there is the potential for problems. For example, consider what happens if you attempt to pass a built-in wchar_t to a function that is overloaded on other integral types, but not specifically on wchar_t, as in the following example:

extern void foo(int);
extern void foo(long);

wchar_t w;
foo(w);    // OK in -o32, ERROR in -n32/-64

// The fix is to declare a variant for wchar_t, but only when
// __EDG_ABI_COMPATIBILITY_VERSION >= 229:
extern void foo(int);
extern void foo(long);
#if __EDG_ABI_COMPATIBILITY_VERSION >= 229
extern void foo(wchar_t);
#endif

If you do not #ifdef it this way, the O32 compiler will indicate that foo(long) has already been declared. This happens because in O32, wchar_t is a synonym for long.

The -LANG:wchar_t=off option can be used to disable recognition of the wchar_t keyword.

Exception handling is on by default in the MIPSpro 7.x compilers in the N32 and 64 modes; it can be turned off by using the -LANG:exceptions=off option. It is also supported in the O32 compiler by using the -exceptions flag. The exception handling constructs of C++ permit you to write code that detects an abnormal execution state of the program and take appropriate action. For instance, if a garbage collector runs out of memory to allocate, the routine may signal an exception that can be handled by displaying an appropriate message and possibly increasing the allocatable heap size.

The Silicon Graphics C++ compilers provide mechanisms for catching (handling) exceptions in a different scope than the scope where they were raised. The implementation of exceptions ensures that there is no appreciable performance penalty for programs that do not throw exceptions.

The following example illustrates the basic syntactic constructs used in exception handling (try, throw, and catch):

void allocator() {
    ...
    if OutOfSpace()
      throw MemOverflowError();
    ...
}

main() {
    ...
    try { // Wrapper for code that may throw exceptions
      mem * = allocator();
      ...
    }

    catch (MemOverflowError) { // Exception handler
      cout << "Exception during allocate.";
      ...
    }
    ...
}

The allocator function raises an exception if it runs out of space. In the main program, the call to allocator() is enclosed within a try block, a program region where exceptions may be raised by throw. If an exception is raised in the call to allocator(), then control shifts to the catch clause which catches the memory overflow error and does suitable error handling.

The syntax of a try and catch block combination is as follows:

try {
    ...
}

// Catch exceptions of int thrown in the try block above
catch (int ) {
    ...
}

// Catch exceptions of float thrown in the try block above
catch(float ) {
    ...
}

// Catch ALL exceptions
catch(...) {
    ...
}

A try block can be followed by zero or more catch blocks. If no exceptions are raised during the execution of a try block, control shifts to immediately after the last catch block. If an exception is raised, that is to say an object is thrown, during the execution of a try block, then the catch block whose type specification matches the type of the thrown object is chosen and control transfers to that handler. The block headed by the catch(...) statement catches all exceptions.

This feature is available only in 7.0 and later versions of the two MIPSpro compilers. C++ provides static type checking, which helps detect compile-time type errors. However, there are situations in which the type of an object may be known only at run time and it becomes necessary to provide some form of type safety. Specifically, given a pointer to an object of a base class, you may want to determine whether it is, in fact, a pointer to an object of a specific derived class of that base class. Consider the following example:

class base {
    public:
      virtual ~base() {};
}
Class derived : base {
    public:
      void ctor() {};
}

You may want to write a function that takes as argument a pointer to base, and calls ctor() only if that pointer is in fact a pointer to derived. To do this, you need a mechanism for determining whether a pointer to a given base class is in fact a pointer to a derived class. You can do this by using the dynamic-cast facility of C++:

f(base *pb) {
    if (derived *pd = dynamic_cast <derived *> (pb))
      pd -> ctor();
    ...
}

If the pointer pb is actually pointing to an object of the derived class rather than of the base class, the dynamic_cast operation returns the pointer. Otherwise, dynamic_cast returns 0.

In addition to dynamic_cast, C++ also provides an operator typeid which determines the exact type of an object. This operator returns a reference to a standard library type called type_info, which represents the type name of its argument.

There are three other ABI changes: