C++ Run-Time Library: cxxrt

cxxrt is free software under the same rules as SGI STL (see http://www.sgi.com/Technology/STL/). Actually, most of this library is actually SGI STL: In addition to the components implemented by SGI STL, this library provides templatized IOStreams, the locales library, and the forwarding headers for the C library putting the C names into namespace std. This basically makes up the complete standard C++ library built on top of a standard C library.

Please sent comments, problem reports, suggestions, etc. to dietmar.kuehl@claas-solutions.de.

Current Version

cxxct-1.0 (download).

Supported Platforms

The code is only tested using gcc-2.95 on a Linux platform. However, it should be possible to port it to other compilers since no gcc specific extensions are used. Porting to other platforms might be more problematic because a C library with at least some support for Amendment 1 is necessary. Also, one file uses the POSIX functions to access files (but this can easily be changed). In any case, it is planned to port this implementations to other platforms, too.

Installation

Currently, there is no automated installation, mainly because the code is ready to do some testing and potentially even for real work if people are prepared to hunt bugs in the library (although it is hoped that commonly used components are mostly bug free) but it is probably not ready for general use. However, to use the code, you need to unpack and compile a library which can be done using the following steps (where has to be replace by the respective version of the library):
    gunzip cxxrt-.tgz
    tar xvf cxxrt-.tar
    cd cxxrt-
    ./configure
    make
  
This process should create the library libcxxrt.a in the directory cxxrt-. It will probably only work correctly if GNU make is used. To compile your code with cxxrt, you have to direct the preprocessor to look for headers in the directory cxxrt- using the -I option and you have to link with libcxxrt.a to create an executable probably using the -L option to tell the linker where to find the library.

You also need a basic C++ library shipping with your compiler for the stuff from the language support library (all compilers I have seen ship at least with this library). Notably for gcc you need to create this library with support for namespace std enabled (either -fhonor-std or -fnew-abi; if you choose the former, you need to adjust the options used in the Makefile in the src directory: the default is -fnew-abi). To get the corresponding library you can either fiddle with the options when installing gcc or you can use the stuff from the directory cxxrt-/basic: The makefile in this directory uses the code from the gcc distribution (the location for this has to be edited in the Makefile) to create a library called libstd.a which contains the corresponding functions. After pointing to the correct directory, just type make.

Once you have compiled the cxxrt library and if necessary the language support library, you can test the library on your platform with the testsuite shipping with the library. Just type

    make check
  
in the directory cxxrt-. This uses dejagnu as test driver which has to be installed before you can run the test. Running this test will cause some expected failures which are due to missing implementations (see below).

Is This a Conforming Implementation

No, it is not. There are still components not yet implemented. However, the components missing are probably rarely used because they became available with other library only relatively recently. More precisely, some of the localization stuff is not yet completely implemented. It is implemented as far as it is needed to get the IOStream library running but not much more. There are some other functions also missing (eg. the extractors and inserters taking stream buffers as arguments) but most of the standard C++ library is up and running.

What is Still to be Done?

Here is a brief overview of what is to be done to make this a really useful library:
  • Getting the missing stuff implemented has clearly high priority.
  • Most of the stuff was just implemented to be conforming and is not at all optimized. There is large potential for optimization for some of the functions.
  • There is no support for a shared library yet. This yields relatively large executables.
  • There is no multi-threading support in the IOStreams and locales library yet.
  • Not everything is thoroughly tested by the current testsuite.
  • The executable size and the run-time of statically linked executables is not yet improved.
  • The documentation is rather incomplete.
The order in which the open issues will be resolved probably depends on requests received. My personal focus will probably soon turn to the executable size of statically linked executables to provide data for the performance working group of the standardization committee.

Why Should this Library be Used

So, it is still incomplete, not optimized, not mt-save, and probably buggy. Why should it still be used?

An advantage of this implementation over all implementations I have compared it with is that it compiles fairly fast (that is, at least the IOStream section). This is because the declaration and definitions of the IOStream and locales library are separated and the commonly used template instantiations are compiled into a library. This does not rule out the use of other instantiations but to use these, it is necessary to define the macros _CXXRT_IOSTREAM_IMPL and _CXXRT_LOCALE_IMPL before including any of the standard headers.

Another advantage of cxxrt is that this implementation causes only relatively few warnings even in highest warning mode. Other implementations normally produce large numbers of warning for the various headers.

The areas where there is no implementation yet are relatively rarely used and there is a fair chance that you will not run into features which are not yet implemented. If you happen to need an unimplemented feature or if you run into a bug, just contact me and I will try to fix the problem as soon as possible.

Where the code is too slow, it would be rather interesting to get test case to create benchmarks for use during optimizations. Some of the stuff is already fairly good and I'm convinced that I can get other areas also very fast. Currently I compare the IOStream implementation with the stdio implementation and consider the code to be fast if the IOStream version is faster than the equivalent stdio version. In some areas like formatting integers it is at least quite close (writing to /dev/null is faster than stdio, writing to a regular file is slower..).

For mt-savety of the IOStream and the locale library it would first be necessary to define what this is supposed to mean. The current implementation does not care about multi threading at all which is probably a bit too optimistic but exactly what is wanted for single threaded applications. I haven't yet decided on a strategy to get the code multi-threading save.

Future Plans

There are several implementations of the standard C++ library available. Currently I know of at least three commercial vendors (Dinkumware, Modena, RogueWave) which are already available and I know of two other free implementations under preparation (Cygnus, SGI). This is though competition. To stay in the competion, the plan is simply to provide the best implementation :-) Of course, what is best depends on the eye of the beholder. Here are the plans how to improve this implementation:
  • There are some tests how to reduce the executable size of a program using the standard C++ library, especially IOStreams. I managed to create a library resulting in a statically bound executable of the hello world program with a size of about 40k. On the same platform (Linux), a C version of hello world is about 140k. Although 40k is still too much (but the C++ library only contributes about 4k), optimizations like these can be interesting for platforms with low memory like eg. embedded systems.
  • Basically the same technique used to reduce the executable size can be used to improve the performance of certain parts of the standard C++ library. In addition to such optimizations, the library will in general be optimized mainly for speed. However, fast compile and link times are also a consideration.
  • For better integration with the C library, it is planned to create the C library on top of the C++ library. Normally, it is done the other way around and this will be retained as an installation option because it is often not possible to replace the C library (eg. because third party libraries are often only available for the C library shipping with the system). However, creating eg. stdio using IOStreams would make it possible to write to arbitrary destinations using 'fprintf()'.
  • There are some ideas to support different use options to get a variaty of different versions eg. with debug support (similar to Safe-STL), different levels of multi-threading support, minimum space usage, or maximum speed. The idea is to place the different versions into different namespaces and have the namespace std use the requested definitions.
Most of these issues will be addressed after completing the library. However, if you are interested in a specific feature please contact me, to potentially shift the priority.

Bugs

Please sent problem reports to dietmar.kuehl@claas-solutions.de. Note that each problem report might be turned into a test case which will be distributed by future versions of the library unless you cleary state that you do not want this. In this case it will be used only internally as a test case. However, any code in problem reports should be short and demonstrate only the problem. Before submitting a problem report, please look at http://www.claas-solutions.de/cxxrt/bugs.html to find out whether the problem is already known (potentially, there is even a fix already available). Here is a brief guide what should be in a bug report:
  • Name and e-mail address. If you do not want your name or e-mail address to appear in the case or in the list of open bugs, say so. Even if you don't want your e-mail address to appear, a valid e-mail address is important to get a patch back to you and potentially to get additional information.
  • The version of the library and the platform (operating system, C++ compiler, C library) used.
  • A brief description of the problem, if possible with reference to the corresponding section in the standard document (ISO 14882).
  • Short, self contained code reproducing the problem and, if applicable, the received and the expected output.
  • If possible, a suggestion how to fix the problem.
Do not hesitate to sent problem reports even if you cannot provide all the information asked above! Just try to make sure that the bug is indeed in the cxxrt library and try to provide as acurate information as possible. Problem reports are very important because it is often hard to foresee all potential uses of a library but once a test case is available it is normally relatively easy to fix problems with unexpected uses. Thus, all problem reports are welcome!

If problem reports are received which turn out to be problems with the SGI STL part of the library, these will be forwarded to the maintainer of this library: It is not intended at all that cxxrt becomes a branch of SGI STL and future releases of SGI STL will be integrated with cxxrt library (unless the permission on the use of the corresponding software is changed). Since some changes to the SGI STL were necessary to integrate it with the IOStreams and locales library, it is distributed with cxxrt.

Support

Contact dietmar.kuehl@claas-solutions.de for information on support of cxxrt. If possible, please indicate what kind of support you want.

Download

The latest releases and snapshots are available from http://www.claas-solutions.de/cxxrt/download.html.