1<?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="&#10;      ISO C++&#10;    , &#10;      library&#10;    " /><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��������&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>;).��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 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>
864