C++ Development

5.3 C++ Language and Library Support

In this section we describe some of the VxWorks-specific aspects of our C++ implementation. To learn more about the C++ language and the Standard libraries consult any standard C++ reference (a good one is Stroustrup, The C++ Programming Language, Third Edition). For documentation on the GNU implementation of the Iostream library see

5.3.1 Language Features

We support many but not all of the new language features contained in the recently approved ANSI C++ Standard. Tornado 2.0 has support for exception handling and run-time type information, as well as improved template support. We do not yet support the namespace feature although the compiler will accept (and ignore) references to the std namespace.

Exception Handling

Our C++ compiler supports multithread safe exception handling by default. To turn off exception handling support use the -fno-exceptions compiler flag.

Using Exceptions

You may have code which was designed around the pre-exception model of C++ compilation. Your calls to new may check the returned pointer for a failure value of zero, for example. If you are worried that the exception handling enhancements in this release will not compile your code correctly, you could adhere to the following simple rules:

Use new (nothrow).

Do not explicitly turn on exceptions in your Iostream objects.

Do not use string objects or wrap them in "try { } catch (...) { }" blocks.

These rules derive from the following observations:

The GNU Iostream does not throw unless IO_THROW is defined when the library is built and exceptions are explicitly enabled for the particular Iostream object in use. The default is no exceptions. Exceptions have to be explicitly turned on for each iostate flag that wants to throw.

The STL does not throw except in some methods in the basic_string class (of which string is a specialization).

Exception Handling Overhead

To support destruction of automatic objects during stack-unwinding the compiler must insert house-keeping code into any function that creates an automatic (stack based) object with a destructor.

Below are some of the costs of exception handling as measured on a PowerPC 604 target (BSP mv2604); counts are in executed instructions. 1,235 instructions are executed to execute a "throw 1" and the associated "catch (...)". There are 14 "extra" instructions to register and deregister automatic variables and temporary objects with destructors and 29 "extra" instructions per non-inlined function for exception-handling setup if any exception handling is used in the function. Finally, the implementation executes 947 "extra" instructions upon encountering the first exception-handling construct (try, catch, throw, or registration of an auto variable or temporary).

                            first time   normal case 
void test()  {          // 3+29         3+29 
    throw 1;            // 1235         1235     total time to printf 
} 
 
void doit() {           // 3+29+947     3+29 
    try {               // 22           22 
        test();         // 1            1 
    } catch (...) { 
        printf("Hi\n"); 
    } 
} 
 
struct A { ~A( ) { } }; 
 
void local_var ( ) {   //               3+29 
    A a;               //               14 
}                     //              4

-fno-exceptions can be used to turn exception handling off. Doing so will reduce the overheads back to classical C++.

Unhandled Exceptions

As required by the Standard, an uncaught exception will eventually lead to a call to terminate( ). The default behavior of this function is to suspend the offending task and log a warning message to the console. You may install your own termination handler by calling set_terminate( ) (defined in the header file exception).

Run-Time Type Information (RTTI)

This feature is turned on by default and adds a small overhead to any C++ program containing classes with virtual functions. If you do not need this feature you may turn it off using -fno-rtti.

5.3.2 Standard Template Library (STL)

The Standard Template library consists of a small run-time component (which may be configured into your kernel by selecting INCLUDE_CPLUS_STL for inclusion in the project facility VxWorks view) and a set of header files.

Our STL port is VxWorks thread safe at the class level. This means that the client has to provide explicit locking if two tasks want to use the same container object. (For example, this could be done by using a semaphore; for details, see 2.4.3 Semaphores.) However two different objects of the same STL container class may be accessed concurrently.

Iostream Library

This library is configured into VxWorks by selecting INCLUDE_CPLUS_IOSTREAMS for inclusion in the project facility VxWorks view; see 5.2.4 Configuration Constants.

The Iostream library header files reside in the standard VxWorks header file directory, installDir/target/h. To use this library, include one or more of the header files after the vxWorks.h header in the appropriate modules of your application. The most frequently used header file is iostream.h, but others are available; see a C++ reference such as Stroustrup for information.

The standard Iostream objects (cin, cout, cerr, and clog) are global: that is, they are not private to any given task. They are correctly initialized regardless of the number of tasks or modules that reference them and they may safely be used across multiple tasks that have the same definitions of stdin, stdout, and stderr. However they cannot safely be used in the case that different tasks have different standard i/o file-descriptors; in this case, the responsibility for mutual exclusion rests with the application.

The effect of private standard Iostream objects can be simulated by creating a new Iostream object of the same class as the standard Iostream object (for example, cin is an istream_withassign), and assigning to it a new filebuf object tied to the appropriate file descriptor. The new filebuf and Iostream objects are private to the calling task, ensuring that no other task can accidentally corrupt them.

ostream my_out (new filebuf (1));            /* 1 == STDOUT */  
istream my_in (new filebuf (0), &my_out);    /* 0 == STDIN;  
                                               * TIE to my_out */

For complete details on the Iostreams library, see the online manual The GNU C++ Iostream Library.

String and Complex Number Classes

These classes are part of the new Standard C++ library. They may be configured into the kernel by selecting INCLUDE_CPLUS_STRING and INCLUDE_CPLUS_COMPLEX for inclusion in the project facility VxWorks view. You may optionally include I/O facilities for these classes by selecting INCLUDE_CPLUS_STRING_IO and INCLUDE_CPLUS_COMPLEX_IO.

NOTE: Tornado 2.0 C++ support does not include support for multi-byte strings. This includes certain classes which are part of the tools.h++ portion of the Wind Foundation Classes.