<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" >
<meta name="keywords" content="linux, software, embedded, C++, development" >
<meta name="GENERATOR" content="nano" >
<link rel ="stylesheet" type="text/css" href="styles.css" >
<title>uClibc++ C++ library</title>
<div style="float: left; width: 150px;">
<div style="float: left;">
<P><B>What is the uClibc++ library?</B>
<P>The uClibc++ library is my implementation of the C++ standard library. It is designed for use in embedded
<P><B>Under what license is uClibc++ released?</B>
<P>uClibc++ is released under the <a href="http://www.gnu.org/licenses/lgpl.html">GNU LGPL</a>. I am also
making it available with custom licenses for a fee. Contact me for more information. Fees subject
to the project and the phase of the moon.
<P><B>How to I use uClibc++?</B>
<P>Simply download the source code, run make menuconfig, make, and make install. Optionally you can run make test
to ensure that the library is working correctly (I don't pass all of my own test suite as of yet - working on it).
<P>Once you have the library installed, you should be able to compile your c++ applications against it by specifying the
wrapper script as the C++ compiler to use, either on the command line or with environment variables.
<P><B>Why doesn't your library support feature X</B>
<P>There are two possible reasons. The first is that I simply haven't gotten around to writing it. How about
you write a conformance test for the feature and send it to me, and I'll implement the feature when I
get around to it. The second is that I have decided that this feature is inappropriate for an embedded
software/C++ library. As such, I have no plans to implement that feature at all (such as locales)
<P><B>What if I *really* want feature X</B>
<P>I program/consult for tuition and spending money. A.k.a. I'm relatively cheap to hire. Contact me and I'll
see what I can do to get you a custom version of the software with your required feature present.
<P><B>What is the difference between uClibc++ and <a href="http://www.caravan.net/ec2plus/">Embedded C++</a></B>
<P>Embedded C++ is a subset of C++. As such it is actually a different language which is missing a *large* number
of the cool features in C++ and it's associated library, such as:
<br>In my view, any one of the above is a good enough reason to use C++ over C (or EC++). As such, stripping
them out does not sit well with me. uClibc++ is designed to be used with a complete C++ compiler and
a C standard library. Few C library features are actually required, but it is just easier to say that
<P><B>What are the differences between uClibc++ and a typical C++ library implementation?</B>
<P>Firstly, all of the code was designed with size in mind, both code and memory. This means that
some design choices were made in order to conserve memory which may reduce performance.
The main differences are:
<li>No locale support at the C++ level</li>
<li>Map currently uses a deque instead of a tree structure</li>
<li>I/OStream library does not call locales</li>
<P>Most of the differences are trivial for all but the most bizzare cases. Let me know if you
run into any problems.
<P><B>Why use a deque for map?</B>
<P>A deque needs only 3 pointers and a size parameter (essentially 4 integers) to manage itself. Compare this
with at least 2 pointers per item for a tree. After two items, the memory overhead of the map already
outweighs that of the deque. Also, deque lookups may be faster as moving to the next level in the
search does not require indirection. On the down side, a deque does not resize cleanly like a map does.
It will use more memory than needed in buffering, and will occasionally need to copy all of the elements
to a new container for more free space. Inserts also execute in O(n) time instead of O(log(n)) time on a
deque unless they are to be added to the front or back of the deque, at which point they are inserted in
O(1)+ time. Lookups and updates are O(log(n)) on both systems. In the end, I thought that the memory
usage of the system outweighed the performance issues involved.
<P><B>How big is uClibc++?</B>
<P>If you are asking how big the source code is, it is about 500k, uncompressed. If you are asking how big the
binary is, that is system dependent. On my system (AMD Athlon) with maximum code expansion, the library is
about 100k when compiled with no optimization. When compiled with size optimization it drops to around 76k.
For best results, try it on your system.
<P><B>Is the code ISO compliant?</B>
<P>I believe that all of the library code is ISO compliant in terms of syntax. Since it is not complete, it is
not compliant in terms of content.
<P><B>What compilers does uClibc++ work with?</B>
<P>The library is written with and for GNU G++ version > 3.3.0. I am developing on a system using 3.3.3.
One of the biggest problems with C++ is the ABI used. I don't feel very comfortable implementing it
since much of the implementation is done inside the compiler. As such, the ABI code is copied from
GNU G++ headers or libraries, as appropriate. You are free to try and use a different C++ compiler.
<P><B>Why don't you support locales?</B>
<P>Locales are a really neat feature, but they are very large. My preliminary support for them was about 50k
before I chopped it out of the project. And at that point my implementation didn't do anything useful.
My rational for this was fairly straightforward: almost no embedded system is going to need locales.
If you are using a GUI toolkit, you most likely have better features for locale handling than will
be offered by the C++ standard. If you are using files on an embedded system (say for logging), the
character used as a decimal marker is pretty much irrelevant. It comes in handy only when you are
looking at doing output to the console, and an embedded system is more likely to use custom functions
for output than the console. Just face it: how often do you explicitly use locales when programming?
Probably not often.
<P><B>How do I use the library?</B>
<P>The library builds a wrapper script, g++-uc, which sets all of the required library calls to effectively
use the library. Though it doesn't cover all possibilities, it is sufficient to be able to compile
large applications like KDE. Simply use the wrapper script anywhere you would call g++ directly,
or override the CXX environment variable if calling scripts and compile away!
<P><B>How can I contribute to the library</B>
<P>First and foremost, attempt to compile your favorite C++ application against uClibc++ and test it. If it
works, let me know. If not, also let me know. Ideally, track the bug down to a particular cause and
submit a minimal example case which works under GNU libstdc++ but not uClibc++. Then see if it falls
under one of the categories above. Ex, if the problem is a lack of locale support, I'm not likely to
care. However, if it is an iostream issue than I will endeavor to resolve the problem as quickly as
<P>If you would like to become involved directly with the code then I am looking for implementations of a
comprehensive test suite. This will discover more and more bugs, making the library better and
<P>If you are truely sadistic, then I am in need of somebody to muck around with the internals of the
g++ compiler, strip out the exception and typeinfo internals of that code and replace it with
new and better uClibc++ code. Sounds like fun, doesn't it?