1 |
424 |
jeremybenn |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
2 |
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
3 |
|
|
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design Notes</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><meta name="keywords" content=" ISO C++ , library " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A. Contributing" /><link rel="prev" href="documentation_style.html" title="Documentation Style" /><link rel="next" href="appendix_porting.html" title="Appendix B. Porting and Maintenance" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design Notes</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="documentation_style.html">Prev</a> </td><th width="60%" align="center">Appendix A.
|
4 |
|
|
Contributing
|
5 |
|
|
|
6 |
|
|
</th><td width="20%" align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr></table><hr /></div><div class="sect1" title="Design Notes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.design_notes"></a>Design Notes</h2></div></div></div><p>
|
7 |
|
|
</p><div class="literallayout"><p><br />
|
8 |
|
|
<br />
|
9 |
|
|
The Library<br />
|
10 |
|
|
-----------<br />
|
11 |
|
|
<br />
|
12 |
|
|
This paper is covers two major areas:<br />
|
13 |
|
|
<br />
|
14 |
|
|
- Features and policies not mentioned in the standard that<br />
|
15 |
|
|
the quality of the library implementation depends on, including<br />
|
16 |
|
|
extensions and "implementation-defined" features;<br />
|
17 |
|
|
<br />
|
18 |
|
|
- Plans for required but unimplemented library features and<br />
|
19 |
|
|
optimizations to them.<br />
|
20 |
|
|
<br />
|
21 |
|
|
Overhead<br />
|
22 |
|
|
--------<br />
|
23 |
|
|
<br />
|
24 |
|
|
The standard defines a large library, much larger than the standard<br />
|
25 |
|
|
C library. A naive implementation would suffer substantial overhead<br />
|
26 |
|
|
in compile time, executable size, and speed, rendering it unusable<br />
|
27 |
|
|
in many (particularly embedded) applications. The alternative demands<br />
|
28 |
|
|
care in construction, and some compiler support, but there is no<br />
|
29 |
|
|
need for library subsets.<br />
|
30 |
|
|
<br />
|
31 |
|
|
What are the sources of this overhead? There are four main causes:<br />
|
32 |
|
|
<br />
|
33 |
|
|
- The library is specified almost entirely as templates, which<br />
|
34 |
|
|
with current compilers must be included in-line, resulting in<br />
|
35 |
|
|
very slow builds as tens or hundreds of thousands of lines<br />
|
36 |
|
|
of function definitions are read for each user source file.<br />
|
37 |
|
|
Indeed, the entire SGI STL, as well as the dos Reis valarray,<br />
|
38 |
|
|
are provided purely as header files, largely for simplicity in<br />
|
39 |
|
|
porting. Iostream/locale is (or will be) as large again.<br />
|
40 |
|
|
<br />
|
41 |
|
|
- The library is very flexible, specifying a multitude of hooks<br />
|
42 |
|
|
where users can insert their own code in place of defaults.<br />
|
43 |
|
|
When these hooks are not used, any time and code expended to<br />
|
44 |
|
|
support that flexibility is wasted.<br />
|
45 |
|
|
<br />
|
46 |
|
|
- Templates are often described as causing to "code bloat". In<br />
|
47 |
|
|
practice, this refers (when it refers to anything real) to several<br />
|
48 |
|
|
independent processes. First, when a class template is manually<br />
|
49 |
|
|
instantiated in its entirely, current compilers place the definitions<br />
|
50 |
|
|
for all members in a single object file, so that a program linking<br />
|
51 |
|
|
to one member gets definitions of all. Second, template functions<br />
|
52 |
|
|
which do not actually depend on the template argument are, under<br />
|
53 |
|
|
current compilers, generated anew for each instantiation, rather<br />
|
54 |
|
|
than being shared with other instantiations. Third, some of the<br />
|
55 |
|
|
flexibility mentioned above comes from virtual functions (both in<br />
|
56 |
|
|
regular classes and template classes) which current linkers add<br />
|
57 |
|
|
to the executable file even when they manifestly cannot be called.<br />
|
58 |
|
|
<br />
|
59 |
|
|
- The library is specified to use a language feature, exceptions,<br />
|
60 |
|
|
which in the current gcc compiler ABI imposes a run time and<br />
|
61 |
|
|
code space cost to handle the possibility of exceptions even when<br />
|
62 |
|
|
they are not used. Under the new ABI (accessed with -fnew-abi),<br />
|
63 |
|
|
there is a space overhead and a small reduction in code efficiency<br />
|
64 |
|
|
resulting from lost optimization opportunities associated with<br />
|
65 |
|
|
non-local branches associated with exceptions.<br />
|
66 |
|
|
<br />
|
67 |
|
|
What can be done to eliminate this overhead? A variety of coding<br />
|
68 |
|
|
techniques, and compiler, linker and library improvements and<br />
|
69 |
|
|
extensions may be used, as covered below. Most are not difficult,<br />
|
70 |
|
|
and some are already implemented in varying degrees.<br />
|
71 |
|
|
<br />
|
72 |
|
|
Overhead: Compilation Time<br />
|
73 |
|
|
--------------------------<br />
|
74 |
|
|
<br />
|
75 |
|
|
Providing "ready-instantiated" template code in object code archives<br />
|
76 |
|
|
allows us to avoid generating and optimizing template instantiations<br />
|
77 |
|
|
in each compilation unit which uses them. However, the number of such<br />
|
78 |
|
|
instantiations that are useful to provide is limited, and anyway this<br />
|
79 |
|
|
is not enough, by itself, to minimize compilation time. In particular,<br />
|
80 |
|
|
it does not reduce time spent parsing conforming headers.<br />
|
81 |
|
|
<br />
|
82 |
|
|
Quicker header parsing will depend on library extensions and compiler<br />
|
83 |
|
|
improvements. One approach is some variation on the techniques<br />
|
84 |
|
|
previously marketed as "pre-compiled headers", now standardized as<br />
|
85 |
|
|
support for the "export" keyword. "Exported" template definitions<br />
|
86 |
|
|
can be placed (once) in a "repository" -- really just a library, but<br />
|
87 |
|
|
of template definitions rather than object code -- to be drawn upon<br />
|
88 |
|
|
at link time when an instantiation is needed, rather than placed in<br />
|
89 |
|
|
header files to be parsed along with every compilation unit.<br />
|
90 |
|
|
<br />
|
91 |
|
|
Until "export" is implemented we can put some of the lengthy template<br />
|
92 |
|
|
definitions in #if guards or alternative headers so that users can skip<br />
|
93 |
|
|
over the full definitions when they need only the ready-instantiated<br />
|
94 |
|
|
specializations.<br />
|
95 |
|
|
<br />
|
96 |
|
|
To be precise, this means that certain headers which define<br />
|
97 |
|
|
templates which users normally use only for certain arguments<br />
|
98 |
|
|
can be instrumented to avoid exposing the template definitions<br />
|
99 |
|
|
to the compiler unless a macro is defined. For example, in<br />
|
100 |
|
|
<string>, we might have:<br />
|
101 |
|
|
<br />
|
102 |
|
|
template <class _CharT, ... > class basic_string {<br />
|
103 |
|
|
... // member declarations<br />
|
104 |
|
|
};<br />
|
105 |
|
|
... // operator declarations<br />
|
106 |
|
|
<br />
|
107 |
|
|
#ifdef _STRICT_ISO_<br />
|
108 |
|
|
# if _G_NO_TEMPLATE_EXPORT<br />
|
109 |
|
|
# include <bits/std_locale.h> // headers needed by definitions<br />
|
110 |
|
|
# ...<br />
|
111 |
|
|
# include <bits/string.tcc> // member and global template definitions.<br />
|
112 |
|
|
# endif<br />
|
113 |
|
|
#endif<br />
|
114 |
|
|
<br />
|
115 |
|
|
Users who compile without specifying a strict-ISO-conforming flag<br />
|
116 |
|
|
would not see many of the template definitions they now see, and rely<br />
|
117 |
|
|
instead on ready-instantiated specializations in the library. This<br />
|
118 |
|
|
technique would be useful for the following substantial components:<br />
|
119 |
|
|
string, locale/iostreams, valarray. It would *not* be useful or<br />
|
120 |
|
|
usable with the following: containers, algorithms, iterators,<br />
|
121 |
|
|
allocator. Since these constitute a large (though decreasing)<br />
|
122 |
|
|
fraction of the library, the benefit the technique offers is<br />
|
123 |
|
|
limited.<br />
|
124 |
|
|
<br />
|
125 |
|
|
The language specifies the semantics of the "export" keyword, but<br />
|
126 |
|
|
the gcc compiler does not yet support it. When it does, problems<br />
|
127 |
|
|
with large template inclusions can largely disappear, given some<br />
|
128 |
|
|
minor library reorganization, along with the need for the apparatus<br />
|
129 |
|
|
described above.<br />
|
130 |
|
|
<br />
|
131 |
|
|
Overhead: Flexibility Cost<br />
|
132 |
|
|
--------------------------<br />
|
133 |
|
|
<br />
|
134 |
|
|
The library offers many places where users can specify operations<br />
|
135 |
|
|
to be performed by the library in place of defaults. Sometimes<br />
|
136 |
|
|
this seems to require that the library use a more-roundabout, and<br />
|
137 |
|
|
possibly slower, way to accomplish the default requirements than<br />
|
138 |
|
|
would be used otherwise.<br />
|
139 |
|
|
<br />
|
140 |
|
|
The primary protection against this overhead is thorough compiler<br />
|
141 |
|
|
optimization, to crush out layers of inline function interfaces.<br />
|
142 |
|
|
Kuck & Associates has demonstrated the practicality of this kind<br />
|
143 |
|
|
of optimization.<br />
|
144 |
|
|
<br />
|
145 |
|
|
The second line of defense against this overhead is explicit<br />
|
146 |
|
|
specialization. By defining helper function templates, and writing<br />
|
147 |
|
|
specialized code for the default case, overhead can be eliminated<br />
|
148 |
|
|
for that case without sacrificing flexibility. This takes full<br />
|
149 |
|
|
advantage of any ability of the optimizer to crush out degenerate<br />
|
150 |
|
|
code.<br />
|
151 |
|
|
<br />
|
152 |
|
|
The library specifies many virtual functions which current linkers<br />
|
153 |
|
|
load even when they cannot be called. Some minor improvements to the<br />
|
154 |
|
|
compiler and to ld would eliminate any such overhead by simply<br />
|
155 |
|
|
omitting virtual functions that the complete program does not call.<br />
|
156 |
|
|
A prototype of this work has already been done. For targets where<br />
|
157 |
|
|
GNU ld is not used, a "pre-linker" could do the same job.<br />
|
158 |
|
|
<br />
|
159 |
|
|
The main areas in the standard interface where user flexibility<br />
|
160 |
|
|
can result in overhead are:<br />
|
161 |
|
|
<br />
|
162 |
|
|
- Allocators: Containers are specified to use user-definable<br />
|
163 |
|
|
allocator types and objects, making tuning for the container<br />
|
164 |
|
|
characteristics tricky.<br />
|
165 |
|
|
<br />
|
166 |
|
|
- Locales: the standard specifies locale objects used to implement<br />
|
167 |
|
|
iostream operations, involving many virtual functions which use<br />
|
168 |
|
|
streambuf iterators.<br />
|
169 |
|
|
<br />
|
170 |
|
|
- Algorithms and containers: these may be instantiated on any type,<br />
|
171 |
|
|
frequently duplicating code for identical operations.<br />
|
172 |
|
|
<br />
|
173 |
|
|
- Iostreams and strings: users are permitted to use these on their<br />
|
174 |
|
|
own types, and specify the operations the stream must use on these<br />
|
175 |
|
|
types.<br />
|
176 |
|
|
<br />
|
177 |
|
|
Note that these sources of overhead are _avoidable_. The techniques<br />
|
178 |
|
|
to avoid them are covered below.<br />
|
179 |
|
|
<br />
|
180 |
|
|
Code Bloat<br />
|
181 |
|
|
----------<br />
|
182 |
|
|
<br />
|
183 |
|
|
In the SGI STL, and in some other headers, many of the templates<br />
|
184 |
|
|
are defined "inline" -- either explicitly or by their placement<br />
|
185 |
|
|
in class definitions -- which should not be inline. This is a<br />
|
186 |
|
|
source of code bloat. Matt had remarked that he was relying on<br />
|
187 |
|
|
the compiler to recognize what was too big to benefit from inlining,<br />
|
188 |
|
|
and generate it out-of-line automatically. However, this also can<br />
|
189 |
|
|
result in code bloat except where the linker can eliminate the extra<br />
|
190 |
|
|
copies.<br />
|
191 |
|
|
<br />
|
192 |
|
|
Fixing these cases will require an audit of all inline functions<br />
|
193 |
|
|
defined in the library to determine which merit inlining, and moving<br />
|
194 |
|
|
the rest out of line. This is an issue mainly in chapters 23, 25, and<br />
|
195 |
|
|
27. Of course it can be done incrementally, and we should generally<br />
|
196 |
|
|
accept patches that move large functions out of line and into ".tcc"<br />
|
197 |
|
|
files, which can later be pulled into a repository. Compiler/linker<br />
|
198 |
|
|
improvements to recognize very large inline functions and move them<br />
|
199 |
|
|
out-of-line, but shared among compilation units, could make this<br />
|
200 |
|
|
work unnecessary.<br />
|
201 |
|
|
<br />
|
202 |
|
|
Pre-instantiating template specializations currently produces large<br />
|
203 |
|
|
amounts of dead code which bloats statically linked programs. The<br />
|
204 |
|
|
current state of the static library, libstdc++.a, is intolerable on<br />
|
205 |
|
|
this account, and will fuel further confused speculation about a need<br />
|
206 |
|
|
for a library "subset". A compiler improvement that treats each<br />
|
207 |
|
|
instantiated function as a separate object file, for linking purposes,<br />
|
208 |
|
|
would be one solution to this problem. An alternative would be to<br />
|
209 |
|
|
split up the manual instantiation files into dozens upon dozens of<br />
|
210 |
|
|
little files, each compiled separately, but an abortive attempt at<br />
|
211 |
|
|
this was done for <string> and, though it is far from complete, it<br />
|
212 |
|
|
is already a nuisance. A better interim solution (just until we have<br />
|
213 |
|
|
"export") is badly needed.<br />
|
214 |
|
|
<br />
|
215 |
|
|
When building a shared library, the current compiler/linker cannot<br />
|
216 |
|
|
automatically generate the instantiations needed. This creates a<br />
|
217 |
|
|
miserable situation; it means any time something is changed in the<br />
|
218 |
|
|
library, before a shared library can be built someone must manually<br />
|
219 |
|
|
copy the declarations of all templates that are needed by other parts<br />
|
220 |
|
|
of the library to an "instantiation" file, and add it to the build<br />
|
221 |
|
|
system to be compiled and linked to the library. This process is<br />
|
222 |
|
|
readily automated, and should be automated as soon as possible.<br />
|
223 |
|
|
Users building their own shared libraries experience identical<br />
|
224 |
|
|
frustrations.<br />
|
225 |
|
|
<br />
|
226 |
|
|
Sharing common aspects of template definitions among instantiations<br />
|
227 |
|
|
can radically reduce code bloat. The compiler could help a great<br />
|
228 |
|
|
deal here by recognizing when a function depends on nothing about<br />
|
229 |
|
|
a template parameter, or only on its size, and giving the resulting<br />
|
230 |
|
|
function a link-name "equate" that allows it to be shared with other<br />
|
231 |
|
|
instantiations. Implementation code could take advantage of the<br />
|
232 |
|
|
capability by factoring out code that does not depend on the template<br />
|
233 |
|
|
argument into separate functions to be merged by the compiler.<br />
|
234 |
|
|
<br />
|
235 |
|
|
Until such a compiler optimization is implemented, much can be done<br />
|
236 |
|
|
manually (if tediously) in this direction. One such optimization is<br />
|
237 |
|
|
to derive class templates from non-template classes, and move as much<br />
|
238 |
|
|
implementation as possible into the base class. Another is to partial-<br />
|
239 |
|
|
specialize certain common instantiations, such as vector<T*>, to share<br />
|
240 |
|
|
code for instantiations on all types T. While these techniques work,<br />
|
241 |
|
|
they are far from the complete solution that a compiler improvement<br />
|
242 |
|
|
would afford.<br />
|
243 |
|
|
<br />
|
244 |
|
|
Overhead: Expensive Language Features<br />
|
245 |
|
|
-------------------------------------<br />
|
246 |
|
|
<br />
|
247 |
|
|
The main "expensive" language feature used in the standard library<br />
|
248 |
|
|
is exception support, which requires compiling in cleanup code with<br />
|
249 |
|
|
static table data to locate it, and linking in library code to use<br />
|
250 |
|
|
the table. For small embedded programs the amount of such library<br />
|
251 |
|
|
code and table data is assumed by some to be excessive. Under the<br />
|
252 |
|
|
"new" ABI this perception is generally exaggerated, although in some<br />
|
253 |
|
|
cases it may actually be excessive.<br />
|
254 |
|
|
<br />
|
255 |
|
|
To implement a library which does not use exceptions directly is<br />
|
256 |
|
|
not difficult given minor compiler support (to "turn off" exceptions<br />
|
257 |
|
|
and ignore exception constructs), and results in no great library<br />
|
258 |
|
|
maintenance difficulties. To be precise, given "-fno-exceptions",<br />
|
259 |
|
|
the compiler should treat "try" blocks as ordinary blocks, and<br />
|
260 |
|
|
"catch" blocks as dead code to ignore or eliminate. Compiler<br />
|
261 |
|
|
support is not strictly necessary, except in the case of "function<br />
|
262 |
|
|
try blocks"; otherwise the following macros almost suffice:<br />
|
263 |
|
|
<br />
|
264 |
|
|
#define throw(X)<br />
|
265 |
|
|
#define try if (true)<br />
|
266 |
|
|
#define catch(X) else if (false)<br />
|
267 |
|
|
<br />
|
268 |
|
|
However, there may be a need to use function try blocks in the<br />
|
269 |
|
|
library implementation, and use of macros in this way can make<br />
|
270 |
|
|
correct diagnostics impossible. Furthermore, use of this scheme<br />
|
271 |
|
|
would require the library to call a function to re-throw exceptions<br />
|
272 |
|
|
from a try block. Implementing the above semantics in the compiler<br />
|
273 |
|
|
is preferable.<br />
|
274 |
|
|
<br />
|
275 |
|
|
Given the support above (however implemented) it only remains to<br />
|
276 |
|
|
replace code that "throws" with a call to a well-documented "handler"<br />
|
277 |
|
|
function in a separate compilation unit which may be replaced by<br />
|
278 |
|
|
the user. The main source of exceptions that would be difficult<br />
|
279 |
|
|
for users to avoid is memory allocation failures, but users can<br />
|
280 |
|
|
define their own memory allocation primitives that never throw.<br />
|
281 |
|
|
Otherwise, the complete list of such handlers, and which library<br />
|
282 |
|
|
functions may call them, would be needed for users to be able to<br />
|
283 |
|
|
implement the necessary substitutes. (Fortunately, they have the<br />
|
284 |
|
|
source code.)<br />
|
285 |
|
|
<br />
|
286 |
|
|
Opportunities<br />
|
287 |
|
|
-------------<br />
|
288 |
|
|
<br />
|
289 |
|
|
The template capabilities of C++ offer enormous opportunities for<br />
|
290 |
|
|
optimizing common library operations, well beyond what would be<br />
|
291 |
|
|
considered "eliminating overhead". In particular, many operations<br />
|
292 |
|
|
done in Glibc with macros that depend on proprietary language<br />
|
293 |
|
|
extensions can be implemented in pristine Standard C++. For example,<br />
|
294 |
|
|
the chapter 25 algorithms, and even C library functions such as strchr,<br />
|
295 |
|
|
can be specialized for the case of static arrays of known (small) size.<br />
|
296 |
|
|
<br />
|
297 |
|
|
Detailed optimization opportunities are identified below where<br />
|
298 |
|
|
the component where they would appear is discussed. Of course new<br />
|
299 |
|
|
opportunities will be identified during implementation.<br />
|
300 |
|
|
<br />
|
301 |
|
|
Unimplemented Required Library Features<br />
|
302 |
|
|
---------------------------------------<br />
|
303 |
|
|
<br />
|
304 |
|
|
The standard specifies hundreds of components, grouped broadly by<br />
|
305 |
|
|
chapter. These are listed in excruciating detail in the CHECKLIST<br />
|
306 |
|
|
file.<br />
|
307 |
|
|
<br />
|
308 |
|
|
17 general<br />
|
309 |
|
|
18 support<br />
|
310 |
|
|
19 diagnostics<br />
|
311 |
|
|
20 utilities<br />
|
312 |
|
|
21 string<br />
|
313 |
|
|
22 locale<br />
|
314 |
|
|
23 containers<br />
|
315 |
|
|
24 iterators<br />
|
316 |
|
|
25 algorithms<br />
|
317 |
|
|
26 numerics<br />
|
318 |
|
|
27 iostreams<br />
|
319 |
|
|
Annex D backward compatibility<br />
|
320 |
|
|
<br />
|
321 |
|
|
Anyone participating in implementation of the library should obtain<br />
|
322 |
|
|
a copy of the standard, ISO 14882. People in the U.S. can obtain an<br />
|
323 |
|
|
electronic copy for US$18 from ANSI's web site. Those from other<br />
|
324 |
|
|
countries should visit http://www.iso.org/ to find out the location<br />
|
325 |
|
|
of their country's representation in ISO, in order to know who can<br />
|
326 |
|
|
sell them a copy.<br />
|
327 |
|
|
<br />
|
328 |
|
|
The emphasis in the following sections is on unimplemented features<br />
|
329 |
|
|
and optimization opportunities.<br />
|
330 |
|
|
<br />
|
331 |
|
|
Chapter 17 General<br />
|
332 |
|
|
-------------------<br />
|
333 |
|
|
<br />
|
334 |
|
|
Chapter 17 concerns overall library requirements.<br />
|
335 |
|
|
<br />
|
336 |
|
|
The standard doesn't mention threads. A multi-thread (MT) extension<br />
|
337 |
|
|
primarily affects operators new and delete (18), allocator (20),<br />
|
338 |
|
|
string (21), locale (22), and iostreams (27). The common underlying<br />
|
339 |
|
|
support needed for this is discussed under chapter 20.<br />
|
340 |
|
|
<br />
|
341 |
|
|
The standard requirements on names from the C headers create a<br />
|
342 |
|
|
lot of work, mostly done. Names in the C headers must be visible<br />
|
343 |
|
|
in the std:: and sometimes the global namespace; the names in the<br />
|
344 |
|
|
two scopes must refer to the same object. More stringent is that<br />
|
345 |
|
|
Koenig lookup implies that any types specified as defined in std::<br />
|
346 |
|
|
really are defined in std::. Names optionally implemented as<br />
|
347 |
|
|
macros in C cannot be macros in C++. (An overview may be read at<br />
|
348 |
|
|
<http://www.cantrip.org/cheaders.html>). The scripts "inclosure"<br />
|
349 |
|
|
and "mkcshadow", and the directories shadow/ and cshadow/, are the<br />
|
350 |
|
|
beginning of an effort to conform in this area.<br />
|
351 |
|
|
<br />
|
352 |
|
|
A correct conforming definition of C header names based on underlying<br />
|
353 |
|
|
C library headers, and practical linking of conforming namespaced<br />
|
354 |
|
|
customer code with third-party C libraries depends ultimately on<br />
|
355 |
|
|
an ABI change, allowing namespaced C type names to be mangled into<br />
|
356 |
|
|
type names as if they were global, somewhat as C function names in a<br />
|
357 |
|
|
namespace, or C++ global variable names, are left unmangled. Perhaps<br />
|
358 |
|
|
another "extern" mode, such as 'extern "C-global"' would be an<br />
|
359 |
|
|
appropriate place for such type definitions. Such a type would<br />
|
360 |
|
|
affect mangling as follows:<br />
|
361 |
|
|
<br />
|
362 |
|
|
namespace A {<br />
|
363 |
|
|
struct X {};<br />
|
364 |
|
|
extern "C-global" { // or maybe just 'extern "C"'<br />
|
365 |
|
|
struct Y {};<br />
|
366 |
|
|
};<br />
|
367 |
|
|
}<br />
|
368 |
|
|
void f(A::X*); // mangles to f__FPQ21A1X<br />
|
369 |
|
|
void f(A::Y*); // mangles to f__FP1Y<br />
|
370 |
|
|
<br />
|
371 |
|
|
(It may be that this is really the appropriate semantics for regular<br />
|
372 |
|
|
'extern "C"', and 'extern "C-global"', as an extension, would not be<br />
|
373 |
|
|
necessary.) This would allow functions declared in non-standard C headers<br />
|
374 |
|
|
(and thus fixable by neither us nor users) to link properly with functions<br />
|
375 |
|
|
declared using C types defined in properly-namespaced headers. The<br />
|
376 |
|
|
problem this solves is that C headers (which C++ programmers do persist<br />
|
377 |
|
|
in using) frequently forward-declare C struct tags without including<br />
|
378 |
|
|
the header where the type is defined, as in<br />
|
379 |
|
|
<br />
|
380 |
|
|
struct tm;<br />
|
381 |
|
|
void munge(tm*);<br />
|
382 |
|
|
<br />
|
383 |
|
|
Without some compiler accommodation, munge cannot be called by correct<br />
|
384 |
|
|
C++ code using a pointer to a correctly-scoped tm* value.<br />
|
385 |
|
|
<br />
|
386 |
|
|
The current C headers use the preprocessor extension "#include_next",<br />
|
387 |
|
|
which the compiler complains about when run "-pedantic".<br />
|
388 |
|
|
(Incidentally, it appears that "-fpedantic" is currently ignored,<br />
|
389 |
|
|
probably a bug.) The solution in the C compiler is to use<br />
|
390 |
|
|
"-isystem" rather than "-I", but unfortunately in g++ this seems<br />
|
391 |
|
|
also to wrap the whole header in an 'extern "C"' block, so it's<br />
|
392 |
|
|
unusable for C++ headers. The correct solution appears to be to<br />
|
393 |
|
|
allow the various special include-directory options, if not given<br />
|
394 |
|
|
an argument, to affect subsequent include-directory options additively,<br />
|
395 |
|
|
so that if one said<br />
|
396 |
|
|
<br />
|
397 |
|
|
-pedantic -iprefix $(prefix) \<br />
|
398 |
|
|
-idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \<br />
|
399 |
|
|
-iwithprefix -I g++-v3/ext<br />
|
400 |
|
|
<br />
|
401 |
|
|
the compiler would search $(prefix)/g++-v3 and not report<br />
|
402 |
|
|
pedantic warnings for files found there, but treat files in<br />
|
403 |
|
|
$(prefix)/g++-v3/ext pedantically. (The undocumented semantics<br />
|
404 |
|
|
of "-isystem" in g++ stink. Can they be rescinded? If not it<br />
|
405 |
|
|
must be replaced with something more rationally behaved.)<br />
|
406 |
|
|
<br />
|
407 |
|
|
All the C headers need the treatment above; in the standard these<br />
|
408 |
|
|
headers are mentioned in various chapters. Below, I have only<br />
|
409 |
|
|
mentioned those that present interesting implementation issues.<br />
|
410 |
|
|
<br />
|
411 |
|
|
The components identified as "mostly complete", below, have not been<br />
|
412 |
|
|
audited for conformance. In many cases where the library passes<br />
|
413 |
|
|
conformance tests we have non-conforming extensions that must be<br />
|
414 |
|
|
wrapped in #if guards for "pedantic" use, and in some cases renamed<br />
|
415 |
|
|
in a conforming way for continued use in the implementation regardless<br />
|
416 |
|
|
of conformance flags.<br />
|
417 |
|
|
<br />
|
418 |
|
|
The STL portion of the library still depends on a header<br />
|
419 |
|
|
stl/bits/stl_config.h full of #ifdef clauses. This apparatus<br />
|
420 |
|
|
should be replaced with autoconf/automake machinery.<br />
|
421 |
|
|
<br />
|
422 |
|
|
The SGI STL defines a type_traits<> template, specialized for<br />
|
423 |
|
|
many types in their code including the built-in numeric and<br />
|
424 |
|
|
pointer types and some library types, to direct optimizations of<br />
|
425 |
|
|
standard functions. The SGI compiler has been extended to generate<br />
|
426 |
|
|
specializations of this template automatically for user types,<br />
|
427 |
|
|
so that use of STL templates on user types can take advantage of<br />
|
428 |
|
|
these optimizations. Specializations for other, non-STL, types<br />
|
429 |
|
|
would make more optimizations possible, but extending the gcc<br />
|
430 |
|
|
compiler in the same way would be much better. Probably the next<br />
|
431 |
|
|
round of standardization will ratify this, but probably with<br />
|
432 |
|
|
changes, so it probably should be renamed to place it in the<br />
|
433 |
|
|
implementation namespace.<br />
|
434 |
|
|
<br />
|
435 |
|
|
The SGI STL also defines a large number of extensions visible in<br />
|
436 |
|
|
standard headers. (Other extensions that appear in separate headers<br />
|
437 |
|
|
have been sequestered in subdirectories ext/ and backward/.) All<br />
|
438 |
|
|
these extensions should be moved to other headers where possible,<br />
|
439 |
|
|
and in any case wrapped in a namespace (not std!), and (where kept<br />
|
440 |
|
|
in a standard header) girded about with macro guards. Some cannot be<br />
|
441 |
|
|
moved out of standard headers because they are used to implement<br />
|
442 |
|
|
standard features. The canonical method for accommodating these<br />
|
443 |
|
|
is to use a protected name, aliased in macro guards to a user-space<br />
|
444 |
|
|
name. Unfortunately C++ offers no satisfactory template typedef<br />
|
445 |
|
|
mechanism, so very ad-hoc and unsatisfactory aliasing must be used<br />
|
446 |
|
|
instead.<br />
|
447 |
|
|
<br />
|
448 |
|
|
Implementation of a template typedef mechanism should have the highest<br />
|
449 |
|
|
priority among possible extensions, on the same level as implementation<br />
|
450 |
|
|
of the template "export" feature.<br />
|
451 |
|
|
<br />
|
452 |
|
|
Chapter 18 Language support<br />
|
453 |
|
|
----------------------------<br />
|
454 |
|
|
<br />
|
455 |
|
|
Headers: <limits> <new> <typeinfo> <exception><br />
|
456 |
|
|
C headers: <cstddef> <climits> <cfloat> <cstdarg> <csetjmp><br />
|
457 |
|
|
<ctime> <csignal> <cstdlib> (also 21, 25, 26)<br />
|
458 |
|
|
<br />
|
459 |
|
|
This defines the built-in exceptions, rtti, numeric_limits<>,<br />
|
460 |
|
|
operator new and delete. Much of this is provided by the<br />
|
461 |
|
|
compiler in its static runtime library.<br />
|
462 |
|
|
<br />
|
463 |
|
|
Work to do includes defining numeric_limits<> specializations in<br />
|
464 |
|
|
separate files for all target architectures. Values for integer types<br />
|
465 |
|
|
except for bool and wchar_t are readily obtained from the C header<br />
|
466 |
|
|
<limits.h>, but values for the remaining numeric types (bool, wchar_t,<br />
|
467 |
|
|
float, double, long double) must be entered manually. This is<br />
|
468 |
|
|
largely dog work except for those members whose values are not<br />
|
469 |
|
|
easily deduced from available documentation. Also, this involves<br />
|
470 |
|
|
some work in target configuration to identify the correct choice of<br />
|
471 |
|
|
file to build against and to install.<br />
|
472 |
|
|
<br />
|
473 |
|
|
The definitions of the various operators new and delete must be<br />
|
474 |
|
|
made thread-safe, which depends on a portable exclusion mechanism,<br />
|
475 |
|
|
discussed under chapter 20. Of course there is always plenty of<br />
|
476 |
|
|
room for improvements to the speed of operators new and delete.<br />
|
477 |
|
|
<br />
|
478 |
|
|
<cstdarg>, in Glibc, defines some macros that gcc does not allow to<br />
|
479 |
|
|
be wrapped into an inline function. Probably this header will demand<br />
|
480 |
|
|
attention whenever a new target is chosen. The functions atexit(),<br />
|
481 |
|
|
exit(), and abort() in cstdlib have different semantics in C++, so<br />
|
482 |
|
|
must be re-implemented for C++.<br />
|
483 |
|
|
<br />
|
484 |
|
|
Chapter 19 Diagnostics<br />
|
485 |
|
|
-----------------------<br />
|
486 |
|
|
<br />
|
487 |
|
|
Headers: <stdexcept><br />
|
488 |
|
|
C headers: <cassert> <cerrno><br />
|
489 |
|
|
<br />
|
490 |
|
|
This defines the standard exception objects, which are "mostly complete".<br />
|
491 |
|
|
Cygnus has a version, and now SGI provides a slightly different one.<br />
|
492 |
|
|
It makes little difference which we use.<br />
|
493 |
|
|
<br />
|
494 |
|
|
The C global name "errno", which C allows to be a variable or a macro,<br />
|
495 |
|
|
is required in C++ to be a macro. For MT it must typically result in<br />
|
496 |
|
|
a function call.<br />
|
497 |
|
|
<br />
|
498 |
|
|
Chapter 20 Utilities<br />
|
499 |
|
|
---------------------<br />
|
500 |
|
|
Headers: <utility> <functional> <memory><br />
|
501 |
|
|
C header: <ctime> (also in 18)<br />
|
502 |
|
|
<br />
|
503 |
|
|
SGI STL provides "mostly complete" versions of all the components<br />
|
504 |
|
|
defined in this chapter. However, the auto_ptr<> implementation<br />
|
505 |
|
|
is known to be wrong. Furthermore, the standard definition of it<br />
|
506 |
|
|
is known to be unimplementable as written. A minor change to the<br />
|
507 |
|
|
standard would fix it, and auto_ptr<> should be adjusted to match.<br />
|
508 |
|
|
<br />
|
509 |
|
|
Multi-threading affects the allocator implementation, and there must<br />
|
510 |
|
|
be configuration/installation choices for different users' MT<br />
|
511 |
|
|
requirements. Anyway, users will want to tune allocator options<br />
|
512 |
|
|
to support different target conditions, MT or no.<br />
|
513 |
|
|
<br />
|
514 |
|
|
The primitives used for MT implementation should be exposed, as an<br />
|
515 |
|
|
extension, for users' own work. We need cross-CPU "mutex" support,<br />
|
516 |
|
|
multi-processor shared-memory atomic integer operations, and single-<br />
|
517 |
|
|
processor uninterruptible integer operations, and all three configurable<br />
|
518 |
|
|
to be stubbed out for non-MT use, or to use an appropriately-loaded<br />
|
519 |
|
|
dynamic library for the actual runtime environment, or statically<br />
|
520 |
|
|
compiled in for cases where the target architecture is known.<br />
|
521 |
|
|
<br />
|
522 |
|
|
Chapter 21 String<br />
|
523 |
|
|
------------------<br />
|
524 |
|
|
Headers: <string><br />
|
525 |
|
|
C headers: <cctype> <cwctype> <cstring> <cwchar> (also in 27)<br />
|
526 |
|
|
<cstdlib> (also in 18, 25, 26)<br />
|
527 |
|
|
<br />
|
528 |
|
|
We have "mostly-complete" char_traits<> implementations. Many of the<br />
|
529 |
|
|
char_traits<char> operations might be optimized further using existing<br />
|
530 |
|
|
proprietary language extensions.<br />
|
531 |
|
|
<br />
|
532 |
|
|
We have a "mostly-complete" basic_string<> implementation. The work<br />
|
533 |
|
|
to manually instantiate char and wchar_t specializations in object<br />
|
534 |
|
|
files to improve link-time behavior is extremely unsatisfactory,<br />
|
535 |
|
|
literally tripling library-build time with no commensurate improvement<br />
|
536 |
|
|
in static program link sizes. It must be redone. (Similar work is<br />
|
537 |
|
|
needed for some components in chapters 22 and 27.)<br />
|
538 |
|
|
<br />
|
539 |
|
|
Other work needed for strings is MT-safety, as discussed under the<br />
|
540 |
|
|
chapter 20 heading.<br />
|
541 |
|
|
<br />
|
542 |
|
|
The standard C type mbstate_t from <cwchar> and used in char_traits<><br />
|
543 |
|
|
must be different in C++ than in C, because in C++ the default constructor<br />
|
544 |
|
|
value mbstate_t() must be the "base" or "ground" sequence state.<br />
|
545 |
|
|
(According to the likely resolution of a recently raised Core issue,<br />
|
546 |
|
|
this may become unnecessary. However, there are other reasons to<br />
|
547 |
|
|
use a state type not as limited as whatever the C library provides.)<br />
|
548 |
|
|
If we might want to provide conversions from (e.g.) internally-<br />
|
549 |
|
|
represented EUC-wide to externally-represented Unicode, or vice-<br />
|
550 |
|
|
versa, the mbstate_t we choose will need to be more accommodating<br />
|
551 |
|
|
than what might be provided by an underlying C library.<br />
|
552 |
|
|
<br />
|
553 |
|
|
There remain some basic_string template-member functions which do<br />
|
554 |
|
|
not overload properly with their non-template brethren. The infamous<br />
|
555 |
|
|
hack akin to what was done in vector<> is needed, to conform to<br />
|
556 |
|
|
23.1.1 para 10. The CHECKLIST items for basic_string marked 'X',<br />
|
557 |
|
|
or incomplete, are so marked for this reason.<br />
|
558 |
|
|
<br />
|
559 |
|
|
Replacing the string iterators, which currently are simple character<br />
|
560 |
|
|
pointers, with class objects would greatly increase the safety of the<br />
|
561 |
|
|
client interface, and also permit a "debug" mode in which range,<br />
|
562 |
|
|
ownership, and validity are rigorously checked. The current use of<br />
|
563 |
|
|
raw pointers as string iterators is evil. vector<> iterators need the<br />
|
564 |
|
|
same treatment. Note that the current implementation freely mixes<br />
|
565 |
|
|
pointers and iterators, and that must be fixed before safer iterators<br />
|
566 |
|
|
can be introduced.<br />
|
567 |
|
|
<br />
|
568 |
|
|
Some of the functions in <cstring> are different from the C version.<br />
|
569 |
|
|
generally overloaded on const and non-const argument pointers. For<br />
|
570 |
|
|
example, in <cstring> strchr is overloaded. The functions isupper<br />
|
571 |
|
|
etc. in <cctype> typically implemented as macros in C are functions<br />
|
572 |
|
|
in C++, because they are overloaded with others of the same name<br />
|
573 |
|
|
defined in <locale>.<br />
|
574 |
|
|
<br />
|
575 |
|
|
Many of the functions required in <cwctype> and <cwchar> cannot be<br />
|
576 |
|
|
implemented using underlying C facilities on intended targets because<br />
|
577 |
|
|
such facilities only partly exist.<br />
|
578 |
|
|
<br />
|
579 |
|
|
Chapter 22 Locale<br />
|
580 |
|
|
------------------<br />
|
581 |
|
|
Headers: <locale><br />
|
582 |
|
|
C headers: <clocale><br />
|
583 |
|
|
<br />
|
584 |
|
|
We have a "mostly complete" class locale, with the exception of<br />
|
585 |
|
|
code for constructing, and handling the names of, named locales.<br />
|
586 |
|
|
The ways that locales are named (particularly when categories<br />
|
587 |
|
|
(e.g. LC_TIME, LC_COLLATE) are different) varies among all target<br />
|
588 |
|
|
environments. This code must be written in various versions and<br />
|
589 |
|
|
chosen by configuration parameters.<br />
|
590 |
|
|
<br />
|
591 |
|
|
Members of many of the facets defined in <locale> are stubs. Generally,<br />
|
592 |
|
|
there are two sets of facets: the base class facets (which are supposed<br />
|
593 |
|
|
to implement the "C" locale) and the "byname" facets, which are supposed<br />
|
594 |
|
|
to read files to determine their behavior. The base ctype<>, collate<>,<br />
|
595 |
|
|
and numpunct<> facets are "mostly complete", except that the table of<br />
|
596 |
|
|
bitmask values used for "is" operations, and corresponding mask values,<br />
|
597 |
|
|
are still defined in libio and just included/linked. (We will need to<br />
|
598 |
|
|
implement these tables independently, soon, but should take advantage<br />
|
599 |
|
|
of libio where possible.) The num_put<>::put members for integer types<br />
|
600 |
|
|
are "mostly complete".<br />
|
601 |
|
|
<br />
|
602 |
|
|
A complete list of what has and has not been implemented may be<br />
|
603 |
|
|
found in CHECKLIST. However, note that the current definition of<br />
|
604 |
|
|
codecvt<wchar_t,char,mbstate_t> is wrong. It should simply write<br />
|
605 |
|
|
out the raw bytes representing the wide characters, rather than<br />
|
606 |
|
|
trying to convert each to a corresponding single "char" value.<br />
|
607 |
|
|
<br />
|
608 |
|
|
Some of the facets are more important than others. Specifically,<br />
|
609 |
|
|
the members of ctype<>, numpunct<>, num_put<>, and num_get<> facets<br />
|
610 |
|
|
are used by other library facilities defined in <string>, <istream>,<br />
|
611 |
|
|
and <ostream>, and the codecvt<> facet is used by basic_filebuf<><br />
|
612 |
|
|
in <fstream>, so a conforming iostream implementation depends on<br />
|
613 |
|
|
these.<br />
|
614 |
|
|
<br />
|
615 |
|
|
The "long long" type eventually must be supported, but code mentioning<br />
|
616 |
|
|
it should be wrapped in #if guards to allow pedantic-mode compiling.<br />
|
617 |
|
|
<br />
|
618 |
|
|
Performance of num_put<> and num_get<> depend critically on<br />
|
619 |
|
|
caching computed values in ios_base objects, and on extensions<br />
|
620 |
|
|
to the interface with streambufs.<br />
|
621 |
|
|
<br />
|
622 |
|
|
Specifically: retrieving a copy of the locale object, extracting<br />
|
623 |
|
|
the needed facets, and gathering data from them, for each call to<br />
|
624 |
|
|
(e.g.) operator<< would be prohibitively slow. To cache format<br />
|
625 |
|
|
data for use by num_put<> and num_get<> we have a _Format_cache<><br />
|
626 |
|
|
object stored in the ios_base::pword() array. This is constructed<br />
|
627 |
|
|
and initialized lazily, and is organized purely for utility. It<br />
|
628 |
|
|
is discarded when a new locale with different facets is imbued.<br />
|
629 |
|
|
<br />
|
630 |
|
|
Using only the public interfaces of the iterator arguments to the<br />
|
631 |
|
|
facet functions would limit performance by forbidding "vector-style"<br />
|
632 |
|
|
character operations. The streambuf iterator optimizations are<br />
|
633 |
|
|
described under chapter 24, but facets can also bypass the streambuf<br />
|
634 |
|
|
iterators via explicit specializations and operate directly on the<br />
|
635 |
|
|
streambufs, and use extended interfaces to get direct access to the<br />
|
636 |
|
|
streambuf internal buffer arrays. These extensions are mentioned<br />
|
637 |
|
|
under chapter 27. These optimizations are particularly important<br />
|
638 |
|
|
for input parsing.<br />
|
639 |
|
|
<br />
|
640 |
|
|
Unused virtual members of locale facets can be omitted, as mentioned<br />
|
641 |
|
|
above, by a smart linker.<br />
|
642 |
|
|
<br />
|
643 |
|
|
Chapter 23 Containers<br />
|
644 |
|
|
----------------------<br />
|
645 |
|
|
Headers: <deque> <list> <queue> <stack> <vector> <map> <set> <bitset><br />
|
646 |
|
|
<br />
|
647 |
|
|
All the components in chapter 23 are implemented in the SGI STL.<br />
|
648 |
|
|
They are "mostly complete"; they include a large number of<br />
|
649 |
|
|
nonconforming extensions which must be wrapped. Some of these<br />
|
650 |
|
|
are used internally and must be renamed or duplicated.<br />
|
651 |
|
|
<br />
|
652 |
|
|
The SGI components are optimized for large-memory environments. For<br />
|
653 |
|
|
embedded targets, different criteria might be more appropriate. Users<br />
|
654 |
|
|
will want to be able to tune this behavior. We should provide<br />
|
655 |
|
|
ways for users to compile the library with different memory usage<br />
|
656 |
|
|
characteristics.<br />
|
657 |
|
|
<br />
|
658 |
|
|
A lot more work is needed on factoring out common code from different<br />
|
659 |
|
|
specializations to reduce code size here and in chapter 25. The<br />
|
660 |
|
|
easiest fix for this would be a compiler/ABI improvement that allows<br />
|
661 |
|
|
the compiler to recognize when a specialization depends only on the<br />
|
662 |
|
|
size (or other gross quality) of a template argument, and allow the<br />
|
663 |
|
|
linker to share the code with similar specializations. In its<br />
|
664 |
|
|
absence, many of the algorithms and containers can be partial-<br />
|
665 |
|
|
specialized, at least for the case of pointers, but this only solves<br />
|
666 |
|
|
a small part of the problem. Use of a type_traits-style template<br />
|
667 |
|
|
allows a few more optimization opportunities, more if the compiler<br />
|
668 |
|
|
can generate the specializations automatically.<br />
|
669 |
|
|
<br />
|
670 |
|
|
As an optimization, containers can specialize on the default allocator<br />
|
671 |
|
|
and bypass it, or take advantage of details of its implementation<br />
|
672 |
|
|
after it has been improved upon.<br />
|
673 |
|
|
<br />
|
674 |
|
|
Replacing the vector iterators, which currently are simple element<br />
|
675 |
|
|
pointers, with class objects would greatly increase the safety of the<br />
|
676 |
|
|
client interface, and also permit a "debug" mode in which range,<br />
|
677 |
|
|
ownership, and validity are rigorously checked. The current use of<br />
|
678 |
|
|
pointers for iterators is evil.<br />
|
679 |
|
|
<br />
|
680 |
|
|
As mentioned for chapter 24, the deque iterator is a good example of<br />
|
681 |
|
|
an opportunity to implement a "staged" iterator that would benefit<br />
|
682 |
|
|
from specializations of some algorithms.<br />
|
683 |
|
|
<br />
|
684 |
|
|
Chapter 24 Iterators<br />
|
685 |
|
|
---------------------<br />
|
686 |
|
|
Headers: <iterator><br />
|
687 |
|
|
<br />
|
688 |
|
|
Standard iterators are "mostly complete", with the exception of<br />
|
689 |
|
|
the stream iterators, which are not yet templatized on the<br />
|
690 |
|
|
stream type. Also, the base class template iterator<> appears<br />
|
691 |
|
|
to be wrong, so everything derived from it must also be wrong,<br />
|
692 |
|
|
currently.<br />
|
693 |
|
|
<br />
|
694 |
|
|
The streambuf iterators (currently located in stl/bits/std_iterator.h,<br />
|
695 |
|
|
but should be under bits/) can be rewritten to take advantage of<br />
|
696 |
|
|
friendship with the streambuf implementation.<br />
|
697 |
|
|
<br />
|
698 |
|
|
Matt Austern has identified opportunities where certain iterator<br />
|
699 |
|
|
types, particularly including streambuf iterators and deque<br />
|
700 |
|
|
iterators, have a "two-stage" quality, such that an intermediate<br />
|
701 |
|
|
limit can be checked much more quickly than the true limit on<br />
|
702 |
|
|
range operations. If identified with a member of iterator_traits,<br />
|
703 |
|
|
algorithms may be specialized for this case. Of course the<br />
|
704 |
|
|
iterators that have this quality can be identified by specializing<br />
|
705 |
|
|
a traits class.<br />
|
706 |
|
|
<br />
|
707 |
|
|
Many of the algorithms must be specialized for the streambuf<br />
|
708 |
|
|
iterators, to take advantage of block-mode operations, in order<br />
|
709 |
|
|
to allow iostream/locale operations' performance not to suffer.<br />
|
710 |
|
|
It may be that they could be treated as staged iterators and<br />
|
711 |
|
|
take advantage of those optimizations.<br />
|
712 |
|
|
<br />
|
713 |
|
|
Chapter 25 Algorithms<br />
|
714 |
|
|
----------------------<br />
|
715 |
|
|
Headers: <algorithm><br />
|
716 |
|
|
C headers: <cstdlib> (also in 18, 21, 26))<br />
|
717 |
|
|
<br />
|
718 |
|
|
The algorithms are "mostly complete". As mentioned above, they<br />
|
719 |
|
|
are optimized for speed at the expense of code and data size.<br />
|
720 |
|
|
<br />
|
721 |
|
|
Specializations of many of the algorithms for non-STL types would<br />
|
722 |
|
|
give performance improvements, but we must use great care not to<br />
|
723 |
|
|
interfere with fragile template overloading semantics for the<br />
|
724 |
|
|
standard interfaces. Conventionally the standard function template<br />
|
725 |
|
|
interface is an inline which delegates to a non-standard function<br />
|
726 |
|
|
which is then overloaded (this is already done in many places in<br />
|
727 |
|
|
the library). Particularly appealing opportunities for the sake of<br />
|
728 |
|
|
iostream performance are for copy and find applied to streambuf<br />
|
729 |
|
|
iterators or (as noted elsewhere) for staged iterators, of which<br />
|
730 |
|
|
the streambuf iterators are a good example.<br />
|
731 |
|
|
<br />
|
732 |
|
|
The bsearch and qsort functions cannot be overloaded properly as<br />
|
733 |
|
|
required by the standard because gcc does not yet allow overloading<br />
|
734 |
|
|
on the extern-"C"-ness of a function pointer.<br />
|
735 |
|
|
<br />
|
736 |
|
|
Chapter 26 Numerics<br />
|
737 |
|
|
--------------------<br />
|
738 |
|
|
Headers: <complex> <valarray> <numeric><br />
|
739 |
|
|
C headers: <cmath>, <cstdlib> (also 18, 21, 25)<br />
|
740 |
|
|
<br />
|
741 |
|
|
Numeric components: Gabriel dos Reis's valarray, Drepper's complex,<br />
|
742 |
|
|
and the few algorithms from the STL are "mostly done". Of course<br />
|
743 |
|
|
optimization opportunities abound for the numerically literate. It<br />
|
744 |
|
|
is not clear whether the valarray implementation really conforms<br />
|
745 |
|
|
fully, in the assumptions it makes about aliasing (and lack thereof)<br />
|
746 |
|
|
in its arguments.<br />
|
747 |
|
|
<br />
|
748 |
|
|
The C div() and ldiv() functions are interesting, because they are the<br />
|
749 |
|
|
only case where a C library function returns a class object by value.<br />
|
750 |
|
|
Since the C++ type div_t must be different from the underlying C type<br />
|
751 |
|
|
(which is in the wrong namespace) the underlying functions div() and<br />
|
752 |
|
|
ldiv() cannot be re-used efficiently. Fortunately they are trivial to<br />
|
753 |
|
|
re-implement.<br />
|
754 |
|
|
<br />
|
755 |
|
|
Chapter 27 Iostreams<br />
|
756 |
|
|
---------------------<br />
|
757 |
|
|
Headers: <iosfwd> <streambuf> <ios> <ostream> <istream> <iostream><br />
|
758 |
|
|
<iomanip> <sstream> <fstream><br />
|
759 |
|
|
C headers: <cstdio> <cwchar> (also in 21)<br />
|
760 |
|
|
<br />
|
761 |
|
|
Iostream is currently in a very incomplete state. <iosfwd>, <iomanip>,<br />
|
762 |
|
|
ios_base, and basic_ios<> are "mostly complete". basic_streambuf<> and<br />
|
763 |
|
|
basic_ostream<> are well along, but basic_istream<> has had little work<br />
|
764 |
|
|
done. The standard stream objects, <sstream> and <fstream> have been<br />
|
765 |
|
|
started; basic_filebuf<> "write" functions have been implemented just<br />
|
766 |
|
|
enough to do "hello, world".<br />
|
767 |
|
|
<br />
|
768 |
|
|
Most of the istream and ostream operators << and >> (with the exception<br />
|
769 |
|
|
of the op<<(integer) ones) have not been changed to use locale primitives,<br />
|
770 |
|
|
sentry objects, or char_traits members.<br />
|
771 |
|
|
<br />
|
772 |
|
|
All these templates should be manually instantiated for char and<br />
|
773 |
|
|
wchar_t in a way that links only used members into user programs.<br />
|
774 |
|
|
<br />
|
775 |
|
|
Streambuf is fertile ground for optimization extensions. An extended<br />
|
776 |
|
|
interface giving iterator access to its internal buffer would be very<br />
|
777 |
|
|
useful for other library components.<br />
|
778 |
|
|
<br />
|
779 |
|
|
Iostream operations (primarily operators << and >>) can take advantage<br />
|
780 |
|
|
of the case where user code has not specified a locale, and bypass locale<br />
|
781 |
|
|
operations entirely. The current implementation of op<</num_put<>::put,<br />
|
782 |
|
|
for the integer types, demonstrates how they can cache encoding details<br />
|
783 |
|
|
from the locale on each operation. There is lots more room for<br />
|
784 |
|
|
optimization in this area.<br />
|
785 |
|
|
<br />
|
786 |
|
|
The definition of the relationship between the standard streams<br />
|
787 |
|
|
cout et al. and stdout et al. requires something like a "stdiobuf".<br />
|
788 |
|
|
The SGI solution of using double-indirection to actually use a<br />
|
789 |
|
|
stdio FILE object for buffering is unsatisfactory, because it<br />
|
790 |
|
|
interferes with peephole loop optimizations.<br />
|
791 |
|
|
<br />
|
792 |
|
|
The <sstream> header work has begun. stringbuf can benefit from<br />
|
793 |
|
|
friendship with basic_string<> and basic_string<>::_Rep to use<br />
|
794 |
|
|
those objects directly as buffers, and avoid allocating and making<br />
|
795 |
|
|
copies.<br />
|
796 |
|
|
<br />
|
797 |
|
|
The basic_filebuf<> template is a complex beast. It is specified to<br />
|
798 |
|
|
use the locale facet codecvt<> to translate characters between native<br />
|
799 |
|
|
files and the locale character encoding. In general this involves<br />
|
800 |
|
|
two buffers, one of "char" representing the file and another of<br />
|
801 |
|
|
"char_type", for the stream, with codecvt<> translating. The process<br />
|
802 |
|
|
is complicated by the variable-length nature of the translation, and<br />
|
803 |
|
|
the need to seek to corresponding places in the two representations.<br />
|
804 |
|
|
For the case of basic_filebuf<char>, when no translation is needed,<br />
|
805 |
|
|
a single buffer suffices. A specialized filebuf can be used to reduce<br />
|
806 |
|
|
code space overhead when no locale has been imbued. Matt Austern's<br />
|
807 |
|
|
work at SGI will be useful, perhaps directly as a source of code, or<br />
|
808 |
|
|
at least as an example to draw on.<br />
|
809 |
|
|
<br />
|
810 |
|
|
Filebuf, almost uniquely (cf. operator new), depends heavily on<br />
|
811 |
|
|
underlying environmental facilities. In current releases iostream<br />
|
812 |
|
|
depends fairly heavily on libio constant definitions, but it should<br />
|
813 |
|
|
be made independent. It also depends on operating system primitives<br />
|
814 |
|
|
for file operations. There is immense room for optimizations using<br />
|
815 |
|
|
(e.g.) mmap for reading. The shadow/ directory wraps, besides the<br />
|
816 |
|
|
standard C headers, the libio.h and unistd.h headers, for use mainly<br />
|
817 |
|
|
by filebuf. These wrappings have not been completed, though there<br />
|
818 |
|
|
is scaffolding in place.<br />
|
819 |
|
|
<br />
|
820 |
|
|
The encapsulation of certain C header <cstdio> names presents an<br />
|
821 |
|
|
interesting problem. It is possible to define an inline std::fprintf()<br />
|
822 |
|
|
implemented in terms of the 'extern "C"' vfprintf(), but there is no<br />
|
823 |
|
|
standard vfscanf() to use to implement std::fscanf(). It appears that<br />
|
824 |
|
|
vfscanf but be re-implemented in C++ for targets where no vfscanf<br />
|
825 |
|
|
extension has been defined. This is interesting in that it seems<br />
|
826 |
|
|
to be the only significant case in the C library where this kind of<br />
|
827 |
|
|
rewriting is necessary. (Of course Glibc provides the vfscanf()<br />
|
828 |
|
|
extension.) (The functions related to exit() must be rewritten<br />
|
829 |
|
|
for other reasons.)<br />
|
830 |
|
|
<br />
|
831 |
|
|
<br />
|
832 |
|
|
Annex D<br />
|
833 |
|
|
-------<br />
|
834 |
|
|
Headers: <strstream><br />
|
835 |
|
|
<br />
|
836 |
|
|
Annex D defines many non-library features, and many minor<br />
|
837 |
|
|
modifications to various headers, and a complete header.<br />
|
838 |
|
|
It is "mostly done", except that the libstdc++-2 <strstream><br />
|
839 |
|
|
header has not been adopted into the library, or checked to<br />
|
840 |
|
|
verify that it matches the draft in those details that were<br />
|
841 |
|
|
clarified by the committee. Certainly it must at least be<br />
|
842 |
|
|
moved into the std namespace.<br />
|
843 |
|
|
<br />
|
844 |
|
|
We still need to wrap all the deprecated features in #if guards<br />
|
845 |
|
|
so that pedantic compile modes can detect their use.<br />
|
846 |
|
|
<br />
|
847 |
|
|
Nonstandard Extensions<br />
|
848 |
|
|
----------------------<br />
|
849 |
|
|
Headers: <iostream.h> <strstream.h> <hash> <rbtree><br />
|
850 |
|
|
<pthread_alloc> <stdiobuf> (etc.)<br />
|
851 |
|
|
<br />
|
852 |
|
|
User code has come to depend on a variety of nonstandard components<br />
|
853 |
|
|
that we must not omit. Much of this code can be adopted from<br />
|
854 |
|
|
libstdc++-v2 or from the SGI STL. This particularly includes<br />
|
855 |
|
|
<iostream.h>, <strstream.h>, and various SGI extensions such<br />
|
856 |
|
|
as <hash_map.h>. Many of these are already placed in the<br />
|
857 |
|
|
subdirectories ext/ and backward/. (Note that it is better to<br />
|
858 |
|
|
include them via "<backward/hash_map.h>" or "<ext/hash_map>" than<br />
|
859 |
|
|
to search the subdirectory itself via a "-I" directive.<br />
|
860 |
|
|
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="documentation_style.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Documentation Style </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix B.
|
861 |
|
|
Porting and Maintenance
|
862 |
|
|
|
863 |
|
|
</td></tr></table></div></body></html>
|