OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-dev/] [or1k-gcc/] [libstdc++-v3/] [doc/] [html/] [manual/] [source_design_notes.html] - Blame information for rev 742

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 742 jeremybenn 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
3 
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Design Notes</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"/><meta name="keywords" content="&#10;      ISO C++&#10;    , &#10;      library&#10;    "/><meta name="keywords" content="&#10;      ISO C++&#10;    , &#10;      runtime&#10;    , &#10;      library&#10;    "/><link rel="home" href="../index.html" title="The GNU C++ Library"/><link rel="up" href="appendix_contributing.html" title="Appendix A.  Contributing"/><link rel="prev" href="source_code_style.html" title="Coding 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 align="left"><a accesskey="p" href="source_code_style.html">Prev</a> </td><th width="60%" align="center">Appendix A. 
4 
  Contributing
5 
 
6 
</th><td align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr></table><hr/></div><div class="section" title="Design Notes"><div class="titlepage"><div><div><h2 class="title"><a id="contrib.design_notes"/>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 
    &lt;string&gt;, we might have:<br/>
101 
<br/>
102 
    template &lt;class _CharT, ... &gt; 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 &lt;bits/std_locale.h&gt;  // headers needed by definitions<br/>
110 
    #   ...<br/>
111 
    #   include &lt;bits/string.tcc&gt;  // 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 &amp; 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 &lt;string&gt; 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&lt;T*&gt;, 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 
    &lt;http://www.cantrip.org/cheaders.html&gt;). 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&lt;&gt; 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: &lt;limits&gt; &lt;new&gt; &lt;typeinfo&gt; &lt;exception&gt;<br/>
456 
    C headers: &lt;cstddef&gt; &lt;climits&gt; &lt;cfloat&gt;  &lt;cstdarg&gt; &lt;csetjmp&gt;<br/>
457 
    &lt;ctime&gt;   &lt;csignal&gt; &lt;cstdlib&gt; (also 21, 25, 26)<br/>
458 
<br/>
459 
    This defines the built-in exceptions, rtti, numeric_limits&lt;&gt;,<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&lt;&gt; 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 
    &lt;limits.h&gt;, 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 
    &lt;cstdarg&gt;, 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: &lt;stdexcept&gt;<br/>
488 
    C headers: &lt;cassert&gt; &lt;cerrno&gt;<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: &lt;utility&gt; &lt;functional&gt; &lt;memory&gt;<br/>
501 
    C header: &lt;ctime&gt; (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&lt;&gt; 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&lt;&gt; 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: &lt;string&gt;<br/>
525 
    C headers: &lt;cctype&gt; &lt;cwctype&gt; &lt;cstring&gt; &lt;cwchar&gt; (also in 27)<br/>
526 
    &lt;cstdlib&gt; (also in 18, 25, 26)<br/>
527 
<br/>
528 
    We have "mostly-complete" char_traits&lt;&gt; implementations. Many of the<br/>
529 
    char_traits&lt;char&gt; operations might be optimized further using existing<br/>
530 
    proprietary language extensions.<br/>
531 
<br/>
532 
    We have a "mostly-complete" basic_string&lt;&gt; 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 &lt;cwchar&gt; and used in char_traits&lt;&gt;<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&lt;&gt; 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&lt;&gt; 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 &lt;cstring&gt; are different from the C version.<br/>
569 
    generally overloaded on const and non-const argument pointers. For<br/>
570 
    example, in &lt;cstring&gt; strchr is overloaded. The functions isupper<br/>
571 
    etc. in &lt;cctype&gt; 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 &lt;locale&gt;.<br/>
574 
<br/>
575 
    Many of the functions required in &lt;cwctype&gt; and &lt;cwchar&gt; 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: &lt;locale&gt;<br/>
582 
    C headers: &lt;clocale&gt;<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 &lt;locale&gt; 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&lt;&gt;, collate&lt;&gt;,<br/>
595 
    and numpunct&lt;&gt; 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&lt;&gt;::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&lt;wchar_t,char,mbstate_t&gt; 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&lt;&gt;, numpunct&lt;&gt;, num_put&lt;&gt;, and num_get&lt;&gt; facets<br/>
610 
    are used by other library facilities defined in &lt;string&gt;, &lt;istream&gt;,<br/>
611 
    and &lt;ostream&gt;, and the codecvt&lt;&gt; facet is used by basic_filebuf&lt;&gt;<br/>
612 
    in &lt;fstream&gt;, 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&lt;&gt; and num_get&lt;&gt; 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&lt;&lt; would be prohibitively slow.  To cache format<br/>
625 
    data for use by num_put&lt;&gt; and num_get&lt;&gt; we have a _Format_cache&lt;&gt;<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: &lt;deque&gt; &lt;list&gt; &lt;queue&gt; &lt;stack&gt; &lt;vector&gt; &lt;map&gt; &lt;set&gt; &lt;bitset&gt;<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: &lt;iterator&gt;<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&lt;&gt; 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: &lt;algorithm&gt;<br/>
716 
    C headers: &lt;cstdlib&gt; (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: &lt;complex&gt; &lt;valarray&gt; &lt;numeric&gt;<br/>
739 
    C headers: &lt;cmath&gt;, &lt;cstdlib&gt; (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: &lt;iosfwd&gt; &lt;streambuf&gt; &lt;ios&gt; &lt;ostream&gt; &lt;istream&gt; &lt;iostream&gt;<br/>
758 
    &lt;iomanip&gt; &lt;sstream&gt; &lt;fstream&gt;<br/>
759 
    C headers: &lt;cstdio&gt; &lt;cwchar&gt; (also in 21)<br/>
760 
<br/>
761 
    Iostream is currently in a very incomplete state. &lt;iosfwd&gt;, &lt;iomanip&gt;,<br/>
762 
    ios_base, and basic_ios&lt;&gt; are "mostly complete". basic_streambuf&lt;&gt; and<br/>
763 
    basic_ostream&lt;&gt; are well along, but basic_istream&lt;&gt; has had little work<br/>
764 
    done. The standard stream objects, &lt;sstream&gt; and &lt;fstream&gt; have been<br/>
765 
    started; basic_filebuf&lt;&gt; "write" functions have been implemented just<br/>
766 
    enough to do "hello, world".<br/>
767 
<br/>
768 
    Most of the istream and ostream operators &lt;&lt; and &gt;&gt; (with the exception<br/>
769 
    of the op&lt;&lt;(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 &lt;&lt; and &gt;&gt;) 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&lt;&lt;/num_put&lt;&gt;::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 &lt;sstream&gt; header work has begun. stringbuf can benefit from<br/>
793 
    friendship with basic_string&lt;&gt; and basic_string&lt;&gt;::_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&lt;&gt; template is a complex beast. It is specified to<br/>
798 
    use the locale facet codecvt&lt;&gt; 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&lt;&gt; 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&lt;char&gt;, 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 &lt;cstdio&gt; 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: &lt;strstream&gt;<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 &lt;strstream&gt;<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: &lt;iostream.h&gt; &lt;strstream.h&gt; &lt;hash&gt; &lt;rbtree&gt;<br/>
850 
    &lt;pthread_alloc&gt; &lt;stdiobuf&gt; (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 
    &lt;iostream.h&gt;, &lt;strstream.h&gt;, and various SGI extensions such<br/>
856 
    as &lt;hash_map.h&gt;. 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 "&lt;backward/hash_map.h&gt;" or "&lt;ext/hash_map&gt;" 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 align="left"><a accesskey="p" href="source_code_style.html">Prev</a> </td><td align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr><tr><td align="left" valign="top">Coding Style </td><td align="center"><a accesskey="h" href="../index.html">Home</a></td><td align="right" valign="top"> Appendix B. 
861 
  Porting and Maintenance
862 
 
863 
</td></tr></table></div></body></html>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.