summaryrefslogtreecommitdiff
path: root/faq.html
blob: 5d3509b8c621701caf4cdd34249bf19c1f159eac (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
	<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>
</head>
<body>
<H1>uClibc++</H1>
<div style="float: left; width: 150px;">
	<br><a href="index.html">Main</a>
	<br><a href="about.html">About</a>
	<br><a href="faq.html">FAQ</a>
	<br><a href="download.html">Download</a>
	<br><a href="status.html">Status</a>
	<br><a href="donate.html">Donate</a>
	<br><a href="contact.html">Contact</a>
</div>

<div style="float: left;">
	<H3>FAQ</H3>

	<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
		systems.

	<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:
		<ul>
			<li>namespaces</li>
			<li>templates</li>
			<li>exceptions</li>
			<li>rtti</li>
			<li>The STL</li>
			
		</ul>
	<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
		they are.

	<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:
		<ul>
			<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>
		</ul>
	<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 &gt; 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
		possible.
	<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
		better.
	<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?

</div>

</body>
</html>