What is the uClibc++ library?
The uClibc++ library is my implementation of the C++ standard library. It is designed for use in embedded systems.
Under what license is uClibc++ released?
uClibc++ is released under the GNU LGPL. 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.
How to I use uClibc++?
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).
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.
Why doesn't your library support feature X
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)
What if I *really* want feature X
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.
What is the difference between uClibc++ and Embedded C++
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:
What are the differences between uClibc++ and a typical C++ library implementation?
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:
Most of the differences are trivial for all but the most bizzare cases. Let me know if you run into any problems.
Why use a deque for map?
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.
How big is uClibc++?
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.
Is the code ISO compliant?
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.
What compilers does uClibc++ work with?
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.
Why don't you support locales?
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.
How do I use the library?
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!
How can I contribute to the library
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 possible.
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 better.
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?