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