diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index f9542ec1daa..8a36129feae 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,10 @@ +2012-08-28 Benjamin Kosnik + + PR libstdc++/54102, part 2 + * doc/Makefile.am (XSL_HTML_STYLE): use xhtml, not html. + * doc/Makefile.in: Regenerate. + * doc/html/*: Same. + 2012-08-28 Benjamin Kosnik * doc/html/*: Regenerate. diff --git a/libstdc++-v3/doc/Makefile.am b/libstdc++-v3/doc/Makefile.am index b787200c5b8..5d807dcbab6 100644 --- a/libstdc++-v3/doc/Makefile.am +++ b/libstdc++-v3/doc/Makefile.am @@ -465,7 +465,7 @@ XSLT_PARAM = --param toc.section.depth 4 #XSL_STYLE_DIR = /usr/share/xml/docbook/stylesheet/docbook-xsl-ns #XSL_STYLE_DIR = /usr/share/sgml/docbook/xsl-ns-stylesheets XSL_FO_STYLE = $(XSL_STYLE_DIR)/fo/docbook.xsl -XSL_HTML_STYLE = $(XSL_STYLE_DIR)/html/chunk.xsl +XSL_HTML_STYLE = $(XSL_STYLE_DIR)/xhtml/chunk.xsl XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/html/docbook.xsl XSL_EPUB_STYLE = $(XSL_STYLE_DIR)/epub3/chunk.xsl XSL_LOCAL_STYLE = ${glibcxx_builddir}/doc/xsl/customization.xsl diff --git a/libstdc++-v3/doc/Makefile.in b/libstdc++-v3/doc/Makefile.in index 40272ef03a7..78bc7783f6f 100644 --- a/libstdc++-v3/doc/Makefile.in +++ b/libstdc++-v3/doc/Makefile.in @@ -517,7 +517,7 @@ XSLT_PARAM = --param toc.section.depth 4 #XSL_STYLE_DIR = /usr/share/xml/docbook/stylesheet/docbook-xsl-ns #XSL_STYLE_DIR = /usr/share/sgml/docbook/xsl-ns-stylesheets XSL_FO_STYLE = $(XSL_STYLE_DIR)/fo/docbook.xsl -XSL_HTML_STYLE = $(XSL_STYLE_DIR)/html/chunk.xsl +XSL_HTML_STYLE = $(XSL_STYLE_DIR)/xhtml/chunk.xsl XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/html/docbook.xsl XSL_EPUB_STYLE = $(XSL_STYLE_DIR)/epub3/chunk.xsl XSL_LOCAL_STYLE = ${glibcxx_builddir}/doc/xsl/customization.xsl diff --git a/libstdc++-v3/doc/html/api.html b/libstdc++-v3/doc/html/api.html index 9209f90be69..48692301254 100644 --- a/libstdc++-v3/doc/html/api.html +++ b/libstdc++-v3/doc/html/api.html @@ -1,20 +1,16 @@ -The GNU C++ Library API Reference
The GNU C++ Library API Reference
Prev  Next

The GNU C++ Library API Reference

Copyright © + + +The GNU C++ Library API Reference

The GNU C++ Library API Reference
Prev  Next

The GNU C++ Library API Reference

Copyright © 2008 , 2010 FSF -

+

The GNU C++ library sources have been specially formatted so that with the proper invocation of another tool (Doxygen), a set of indexed reference material can generated from the sources files @@ -60,4 +56,4 @@

In addition, a rendered set of man pages are available in the same location specified above. Start with C++Intro(3). -

Prev Up Next
 Home 
+

Prev Up Next
 Home 
diff --git a/libstdc++-v3/doc/html/bk02.html b/libstdc++-v3/doc/html/bk02.html index c517b9632cb..3863d067ae3 100644 --- a/libstdc++-v3/doc/html/bk02.html +++ b/libstdc++-v3/doc/html/bk02.html @@ -1,7 +1,3 @@ -
Prev   Next

Table of Contents

The GNU C++ Library API Reference
Prev   Next
Backwards Compatibility Home The GNU C++ Library API Reference
+ + +
Prev   Next

Table of Contents

The GNU C++ Library API Reference
Prev   Next
Backwards Compatibility Home The GNU C++ Library API Reference
diff --git a/libstdc++-v3/doc/html/bk03.html b/libstdc++-v3/doc/html/bk03.html index b5680730c1c..a00ca967b51 100644 --- a/libstdc++-v3/doc/html/bk03.html +++ b/libstdc++-v3/doc/html/bk03.html @@ -1,7 +1,3 @@ -
Prev   Next

Table of Contents

Frequently Asked Questions
Prev   Next
The GNU C++ Library API Reference Home Frequently Asked Questions
+ + +
Prev   Next

Table of Contents

Frequently Asked Questions
Prev   Next
The GNU C++ Library API Reference Home Frequently Asked Questions
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html index 1c7ee04bfb0..b06604317f4 100644 --- a/libstdc++-v3/doc/html/faq.html +++ b/libstdc++-v3/doc/html/faq.html @@ -1,14 +1,10 @@ -Frequently Asked Questions
Frequently Asked Questions
Prev  

Frequently Asked Questions

Copyright © + + +Frequently Asked Questions

Frequently Asked Questions
Prev  

Frequently Asked Questions

Copyright © 2008, 2010 FSF -

1.1. +

1.1. What is libstdc++?
1.2. Why should I use libstdc++? @@ -95,7 +91,7 @@ What's an ABI and why is it so messy?
7.8. How do I make std::vector<T>::capacity() == std::vector<T>::size? -
1.1. +
1.1. What is libstdc++?
1.2. Why should I use libstdc++? @@ -109,9 +105,9 @@ What happened to the older libg++? I need that!
1.7. What if I have more questions? -

1.1.

+

1.1.

What is libstdc++? -

+

The GNU Standard C++ Library v3 is an ongoing project to implement the ISO 14882 Standard C++ library as described in chapters 17 through 27 and annex D. For those who want to see @@ -119,9 +115,9 @@ bleeding-edge code, the up-to-date source is available over anonymous SVN, and can even be browsed over the web. -

1.2.

+

1.2.

Why should I use libstdc++? -

+

The completion of the ISO C++ standardization gave the C++ community a powerful set of reuseable tools in the form of the C++ Standard Library. However, all existing C++ implementations are @@ -145,9 +141,9 @@ vector<>, iostreams, and algorithms.) Programmers will no longer need to “roll their own” nor be worried about platform-specific incompatibilities. -

1.3.

+

1.3.

Who's in charge of it? -

+

The libstdc++ project is contributed to by several developers all over the world, in the same way as GCC or the Linux kernel. Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper, @@ -159,15 +155,15 @@ archives, is open to everyone. You can read instructions for doing so on the homepage. If you have questions, ideas, code, or are just curious, sign up! -

1.4.

+

1.4.

When is libstdc++ going to be finished? -

+

Nathan Myers gave the best of all possible answers, responding to a Usenet article asking this question: Sooner, if you help. -

1.5.

+

1.5.

How do I contribute to the effort? -

+

Here is a page devoted to this topic. Subscribing to the mailing list (see above, or the homepage) is a very good idea if you have something to @@ -176,17 +172,17 @@ anybody who is willing to help write documentation, for example, or has found a bug in code that we all thought was working and is willing to provide details, is more than welcome! -

1.6.

+

1.6.

What happened to the older libg++? I need that! -

+

The most recent libg++ README states that libg++ is no longer being actively maintained. It should not be used for new projects, and is only being kicked along to support older code.

More information in the backwards compatibility documentation -

1.7.

+

1.7.

What if I have more questions? -

+

If you have read the README file, and your question remains unanswered, then just ask the mailing list. At present, you do not need to be subscribed to the list to send a message to it. More @@ -205,19 +201,19 @@ How is that different from the GNU {Lesser,Library} GPL?

2.4. I see. So, what restrictions are there on programs that use the library? -

2.1.

+

2.1.

What are the license terms for libstdc++? -

+

See our license description for these and related questions. -

2.2.

+

2.2.

So any program which uses libstdc++ falls under the GPL? -

+

No. The special exception permits use of the library in proprietary applications. -

2.3.

+

2.3.

How is that different from the GNU {Lesser,Library} GPL? -

+

The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there's no way to make that work with C++, where @@ -225,9 +221,9 @@ are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL. -

2.4.

+

2.4.

I see. So, what restrictions are there on programs that use the library? -

+

None. We encourage such programs to be released as open source, but we won't punish you or sue you if you choose otherwise.

3.1. How do I install libstdc++? @@ -238,8 +234,8 @@ What's libsupc++?
3.6. This library is HUGE! -

3.1.

How do I install libstdc++? -

+

3.1.

How do I install libstdc++? +

Often libstdc++ comes pre-installed as an integral part of many existing GNU/Linux and Unix systems, as well as many embedded development tools. It may be necessary to install extra @@ -251,8 +247,8 @@ documentation for detailed instructions. You may wish to browse those files ahead of time to get a feel for what's required. -

3.2.

How does one get current libstdc++ sources? -

+

3.2.

How does one get current libstdc++ sources? +

Libstdc++ sources for all official releases can be obtained as part of the GCC sources, available from various sites and mirrors. A full list of @@ -276,8 +272,8 @@ For more information see SVN details. -

3.3.

How do I know if it works? -

+

3.3.

How do I know if it works? +

Libstdc++ comes with its own validation testsuite, which includes conformance testing, regression testing, ABI testing, and performance testing. Please consult the @@ -287,8 +283,8 @@ If you find bugs in the testsuite programs themselves, or if you think of a new test program that should be added to the suite, please write up your idea and send it to the list! -

3.4.

How do I insure that the dynamically linked library will be found? -

+

3.4.

How do I insure that the dynamically linked library will be found? +

Depending on your platform and library version, the error message might be similar to one of the following: 

@@ -321,9 +317,9 @@
     

     Using LD_LIBRARY_PATH is not always the best solution, Finding Dynamic or Shared
     Libraries in the manual gives some alternatives.
-

3.5.

+

3.5.

What's libsupc++? -

+

If the only functions from libstdc++.a which you need are language support functions (those listed in clause 18 of the @@ -338,9 +334,9 @@ using anything from the rest of the library, such as IOStreams or vectors, then you'll still need pieces from libstdc++.a. -

3.6.

+

3.6.

This library is HUGE! -

+

Usually the size of libraries on disk isn't noticeable. When a link editor (or simply “linker”) pulls things from a static archive library, only the necessary object files are copied @@ -385,9 +381,9 @@ Recent GNU/Linux glibc required?

4.8. Can't use wchar_t/wstring on FreeBSD -

4.1.

+

4.1.

Can libstdc++ be used with non-GNU compilers? -

+

Perhaps.

Since the goal of ISO Standardization is for all C++ @@ -405,9 +401,9 @@ been known to work with versions of the EDG C++ compiler, and vendor-specific proprietary C++ compilers such as the Intel ICC C++ compiler. -

4.2.

+

4.2.

No 'long long' type on Solaris? -

+

By default we try to support the C99 long long type. This requires that certain functions from your C library be present.

@@ -417,9 +413,9 @@ commonly reported platform affected was Solaris.

This has been fixed for libstdc++ releases greater than 3.0.3. -

4.3.

+

4.3.

_XOPEN_SOURCE and _GNU_SOURCE are always defined? -

On Solaris, g++ (but not gcc) always defines the preprocessor +

On Solaris, g++ (but not gcc) always defines the preprocessor macro _XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This is not an exhaustive list; other macros and other platforms are also affected.) @@ -446,15 +442,15 @@ quite a bit.

This method is something of a wart. We'd like to find a cleaner solution, but nobody yet has contributed the time. -

4.4.

+

4.4.

Mac OS X ctype.h is broken! How can I fix it? -

This is a long-standing bug in the OS X support. Fortunately, +

This is a long-standing bug in the OS X support. Fortunately, the patch is quite simple, and well-known. Here's a link to the solution. -

4.5.

+

4.5.

Threading is broken on i386? -

+

Support for atomic integer operations is/was broken on i386 platforms. The assembly code accidentally used opcodes that are only available on the i486 and later. So if you configured GCC @@ -462,9 +458,9 @@ on an i686, then you would encounter no problems. Only when actually running the code on a i386 will the problem appear.

This is fixed in 3.2.2. -

4.6.

+

4.6.

MIPS atomic operations -

+

The atomic locking routines for MIPS targets requires MIPS II and later. A patch went in just after the 3.3 release to make mips* use the generic implementation instead. You can also @@ -472,9 +468,9 @@

The mips*-*-linux* port continues to use the MIPS II routines, and more work in this area is expected. -

4.7.

+

4.7.

Recent GNU/Linux glibc required? -

When running on GNU/Linux, libstdc++ 3.2.1 (shared library version +

When running on GNU/Linux, libstdc++ 3.2.1 (shared library version 5.0.1) and later uses localization and formatting code from the system C library (glibc) version 2.2.5 which contains necessary bugfixes. Most GNU/Linux distros make more recent versions available now. @@ -483,9 +479,9 @@

The guideline is simple: the more recent the C++ library, the more recent the C library. (This is also documented in the main GCC installation instructions.) -

4.8.

+

4.8.

Can't use wchar_t/wstring on FreeBSD -

+

Older versions of FreeBSD's C library do not have sufficient support for wide character functions, and as a result the libstdc++ configury decides that wchar_t support should be @@ -502,9 +498,9 @@ Bugs in the ISO C++ language or library specification

5.3. Bugs in the compiler (gcc/g++) and not libstdc++ -

5.1.

+

5.1.

What works already? -

+

Short answer: Pretty much everything works except for some corner cases. Support for localization in locale may be incomplete on non-GNU @@ -516,9 +512,9 @@ C++98, TR1, and C++11. -

5.2.

+

5.2.

Bugs in the ISO C++ language or library specification -

+

Unfortunately, there are some.

For those people who are not part of the ISO Library Group @@ -531,9 +527,9 @@ If you think you've discovered a new bug that is not listed, please post a message describing your problem to the author of the library issues list or the Usenet group comp.lang.c++.moderated. -

5.3.

+

5.3.

Bugs in the compiler (gcc/g++) and not libstdc++ -

+

On occasion, the compiler is wrong. Please be advised that this happens much less often than one would think, and avoid jumping to conclusions. @@ -566,19 +562,19 @@ list::size() is O(n)!

6.9. Aw, that's easy to fix! -

6.1.

+

6.1.

Reopening a stream fails -

+

One of the most-reported non-bug reports. Executing a sequence like: -


-    #include <fstream>
-    ...
-    std::fstream  fs(“a_file”);
-    // .
-    // . do things with fs...
-    // .
-    fs.close();
-    fs.open(“a_new_file”);
+


+    #include <fstream>
+    ...
+    std::fstream  fs(“a_file”);
+    // .
+    // . do things with fs...
+    // .
+    fs.close();
+    fs.open(“a_new_file”);
    

All operations on the re-opened fs will fail, or at least act very strangely. Yes, they often will, especially if @@ -593,9 +589,9 @@ Update: for GCC 4.0 we implemented the resolution of DR #409 and open() now calls clear() on success! -

6.2.

+

6.2.

-Weffc++ complains too much -

+

Many warnings are emitted when -Weffc++ is used. Making libstdc++ -Weffc++-clean is not a goal of the project, for a few reasons. Mainly, that option tries to enforce @@ -605,9 +601,9 @@ We do, however, try to have libstdc++ sources as clean as possible. If you see some simple changes that pacify -Weffc++ without other drawbacks, send us a patch. -

6.3.

+

6.3.

Ambiguous overloads after including an old-style header -

+

Another problem is the rel_ops namespace and the template comparison operator functions contained therein. If they become visible in the same namespace as other comparison functions @@ -617,9 +613,9 @@ sums things up here. The collisions with vector/string iterator types have been fixed for 3.1. -

6.4.

+

6.4.

The g++-3 headers are not ours -

+

If you are using headers in ${prefix}/include/g++-3, or if the installed library's name looks like libstdc++-2.10.a or @@ -633,10 +629,10 @@ 'v'?). Starting with version 3.2 the headers are installed in ${prefix}/include/c++/${version} as this prevents headers from previous versions being found by mistake. -

6.5.

+

6.5.

Errors about *Concept and constraints in the STL -

+

If you see compilation errors containing messages about foo Concept and something to do with a constraints member function, then most @@ -650,28 +646,28 @@ checks, is available in the Diagnostics. chapter of the manual. -

6.6.

+

6.6.

Program crashes when using library code in a dynamically-loaded library -

+

If you are using the C++ library across dynamically-loaded objects, make certain that you are passing the correct options when compiling and linking: -


-    // compile your library components
-    g++ -fPIC -c a.cc
-    g++ -fPIC -c b.cc
-    ...
-    g++ -fPIC -c z.cc
-
-    // create your library
-    g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o
-
-    // link the executable
-    g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl
-    

6.7.

+


+    // compile your library components
+    g++ -fPIC -c a.cc
+    g++ -fPIC -c b.cc
+    ...
+    g++ -fPIC -c z.cc
+
+    // create your library
+    g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o
+
+    // link the executable
+    g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl
+    

6.7.

“Memory leaks” in containers -

+

A few people have reported that the standard containers appear to leak memory when tested with memory checkers such as valgrind. @@ -682,15 +678,15 @@ want to test the library for memory leaks please read Tips for memory leak hunting first. -

6.8.

+

6.8.

list::size() is O(n)! -

+

See the Containers chapter. -

6.9.

+

6.9.

Aw, that's easy to fix! -

+

If you have found a bug in the library and you think you have a working fix, then send it in! The main GCC site has a page on submitting @@ -721,9 +717,9 @@ What's an ABI and why is it so messy?

7.8. How do I make std::vector<T>::capacity() == std::vector<T>::size? -

7.1.

+

7.1.

string::iterator is not char*; vector<T>::iterator is not T* -

+

If you have code that depends on container<T> iterators being implemented as pointer-to-T, your code is broken. It's considered a feature, not a bug, that libstdc++ points this out. @@ -740,9 +736,9 @@ certain expressions to &*i. Future revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). -

7.2.

+

7.2.

What's next after libstdc++? -

+

Hopefully, not much. The goal of libstdc++ is to produce a fully-compliant, fully-portable Standard Library. After that, we're mostly done: there won't be any @@ -753,9 +749,9 @@ this effort is described in The C++ Library Technical Report 1. -

7.3.

+

7.3.

What about the STL from SGI? -

+

The STL from SGI, version 3.3, was the final merge of the STL codebase. The code in libstdc++ contains many fixes and changes, and @@ -776,13 +772,13 @@

The FAQ for SGI's STL (one jump off of their main page) is still recommended reading. -

7.4.

+

7.4.

Extensions and Backward Compatibility -

+

See the link on backwards compatibility and link on evolution. -

7.5.

+

7.5.

Does libstdc++ support TR1? -

+

Yes.

The C++ Standard Library Technical Report adds many new features to @@ -792,8 +788,8 @@

The implementation status of TR1 in libstdc++ can be tracked on the TR1 status page. -

7.6.

How do I get a copy of the ISO C++ Standard? -

+

7.6.

How do I get a copy of the ISO C++ Standard? +

Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee members. Non-members, or those who have not paid for the privilege of sitting on the committee @@ -811,9 +807,9 @@

The 2003 version of the standard (the 1998 version plus TC1) is available in print, ISBN 0-470-84674-7. -

7.7.

+

7.7.

What's an ABI and why is it so messy? -

+

ABI stands for “Application Binary Interface”. Conventionally, it refers to a great mass of details about how arguments are arranged on the call @@ -859,17 +855,17 @@ so they may later be changed. Deciding which, and implementing the decisions, must happen before you can reasonably document a candidate C++ ABI that encompasses the standard library. -

7.8.

+

7.8.

How do I make std::vector<T>::capacity() == std::vector<T>::size? -

+

The standard idiom for deallocating a vector<T>'s unused memory is to create a temporary copy of the vector and swap their contents, e.g. for vector<T> v -


-     std::vector<T>(v).swap(v);
+


+     std::vector<T>(v).swap(v);
    

The copy will take O(n) time and the swap is constant time.

See Shrink-to-fit strings for a similar solution for strings. -

Prev Up 
 Home 
+

Prev Up 
 Home 
diff --git a/libstdc++-v3/doc/html/index.html b/libstdc++-v3/doc/html/index.html index dec3001b5ed..fb6695185bb 100644 --- a/libstdc++-v3/doc/html/index.html +++ b/libstdc++-v3/doc/html/index.html @@ -1,10 +1,6 @@ -The GNU C++ Library
The GNU C++ Library
   Next

The GNU C++ Library

Short Contents

+ + +The GNU C++ Library

The GNU C++ Library
   Next

The GNU C++ Library

Short Contents

Copyright 2008, 2009, 2011 FSF @@ -25,7 +21,7 @@

  • API and Source Documentation

    • -

    Table of Contents

    The GNU C++ Library Manual
    I. +

    Table of Contents

    The GNU C++ Library Manual
    I. Introduction
    1. Status
    Implementation Status
    C++ 1998/2003
    Implementation Status
    Implementation Specific Behavior
    C++ 2011
    Implementation Specific Behavior
    C++ TR1
    Implementation Specific Behavior
    C++ TR 24733
    License
    The Code: GPL
    The Documentation: GPL, FDL
    Bugs
    Implementation Bugs
    Standard Bugs
    2. Setup
    Prerequisites
    Configure
    Make
    3. Using
    Command Options
    Headers
    Header Files
    Mixing Headers
    The C Headers and namespace std
    Precompiled Headers
    Macros
    Namespaces
    Available Namespaces
    namespace std
    Using Namespace Composition
    Linking
    Almost Nothing
    Finding Dynamic or Shared Libraries
    Concurrency
    Prerequisites
    Thread Safety
    Atomics
    IO
    Structure
    Defaults
    Future
    Alternatives
    Containers
    Exceptions
    Exception Safety
    Exception Neutrality
    Doing without
    Compatibility
    With C
    With POSIX thread cancellation
    Debugging Support
    Using g++
    Debug Versions of Library Binary Files
    Memory Leak Hunting
    Data Race Hunting
    Using gdb
    Tracking uncaught exceptions
    Debug Mode
    Compile Time Checking
    Profile-based Performance Analysis
    II. @@ -39,13 +35,13 @@
    Exceptions
    API Reference
    Adding Data to exception
    Concept Checking
    6. Utilities -
    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits
    7. +
    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits
    7. Strings
    String Classes
    Simple Transformations
    Case Sensitivity
    Arbitrary Character Types
    Tokenizing
    Shrink to Fit
    CString (MFC)
    8. Localization -
    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future
    9. +
    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future
    9. Containers
    Sequences
    list
    list::size() is O(n)
    vector
    Space Overhead Management
    Associative
    Insertion Hints
    bitset
    Size Variable
    Type String
    Interacting with C
    Containers vs. Arrays
    10. @@ -169,4 +165,4 @@ Support for C++11 dialect.
    D. GNU General Public License version 3 -
    E. GNU Free Documentation License
    The GNU C++ Library API Reference
    Frequently Asked Questions
       Next
       The GNU C++ Library Manual
    +
    E. GNU Free Documentation License
    The GNU C++ Library API Reference
    Frequently Asked Questions
       Next
       The GNU C++ Library Manual
    diff --git a/libstdc++-v3/doc/html/manual/abi.html b/libstdc++-v3/doc/html/manual/abi.html index b1ec7a46bde..678a2a40ea8 100644 --- a/libstdc++-v3/doc/html/manual/abi.html +++ b/libstdc++-v3/doc/html/manual/abi.html @@ -1,30 +1,10 @@ -ABI Policy and Guidelines
    ABI Policy and Guidelines
    Prev Appendix B.  + + +ABI Policy and Guidelines
    ABI Policy and Guidelines
    Prev Appendix B.  Porting and Maintenance - Next

    ABI Policy and Guidelines

    -

    The C++ Interface

    +

    		 Next

    ABI Policy and Guidelines

    +

    The C++ Interface

    C++ applications often depend on specific language support routines, say for throwing exceptions, or catching exceptions, and perhaps also depend on features in the C++ Standard Library. @@ -78,10 +58,10 @@ given compiler ABI. In a nutshell: To use a specific version of the C++ ABI, one must use a corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that implements the C++ ABI in question. -

    Versioning

    The C++ interface has evolved throughout the history of the GNU +

    Versioning

    The C++ interface has evolved throughout the history of the GNU C++ toolchain. With each release, various details have been changed so as to give distinct versions to the C++ interface. -

    Goals

    Extending existing, stable ABIs. Versioning gives subsequent +

    Goals

    Extending existing, stable ABIs. Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial @@ -95,7 +75,7 @@ binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.

    Allows multiple, incompatible ABIs to coexist at the same time. -

    History

    +

    History

    How can this complexity be managed? What does C++ versioning mean? Because library and compiler changes often make binaries compiled with one version of the GNU tools incompatible with binaries @@ -211,7 +191,7 @@ compatible. properly, they allow both the GNU C++ tools implementation, and programs using them, an evolving yet controlled development that maintains backward compatibility. -

    Prerequisites

    +

    Prerequisites

    Minimum environment that supports a versioned ABI: A supported dynamic linker, a GNU linker of sufficient vintage to understand demangled C++ name globbing (ld) or the Sun linker, a shared @@ -226,7 +206,7 @@ compatible. Most modern GNU/Linux and BSD versions, particularly ones using GCC 3.1 and later, will meet the requirements above, as does Solaris 2.5 and up. -

    Configuring

    +

    Configuring

    It turns out that most of the configure options that change default behavior will impact the mangled names of exported symbols, and thus impact versioning and compatibility. @@ -244,7 +224,7 @@ compatible. attempts to make sure that all the requirement for symbol versioning are in place. For more information, please consult acinclude.m4. -

    Checking Active

    +

    Checking Active

    When the GNU C++ library is being built with symbol versioning on, you should see the following at configure time for libstdc++: @@ -292,12 +272,12 @@ On Solaris 2, you can use pvs -r instead: libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);

    ldd -v works too, but is very verbose. -

    Allowed Changes

    +

    Allowed Changes

    The following will cause the library minor version number to increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5".

    1. Adding an exported global or static data member

    2. Adding an exported function, static or non-virtual member function

    3. Adding an exported symbol or symbols by additional instantiations

    Other allowed changes are possible. -

    Prohibited Changes

    +

    Prohibited Changes

    The following non-exhaustive list will cause the library major version number to increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.4.0.0". @@ -316,7 +296,7 @@ class in registers, the compiler will be forced to use memory. See the section on Function Calling Conventions and APIs of the C++ ABI documentation for further details. -

    Implementation

    1. +

    Implementation

    1. Separation of interface and implementation

      This is accomplished by two techniques that separate the API from @@ -364,7 +344,7 @@ exceptional symbols are allowed to be visible.

      CXXABI, select items are allowed to be visible.

  • Freezing the API

    Disallowed changes, as above, are not made on a stable release branch. Enforcement tends to be less strict with GNU extensions that -standard includes.

    • Testing

    Single ABI Testing

    +standard includes.

    Testing

    Single ABI Testing

    Testing for GNU C++ ABI changes is composed of two distinct areas: testing the C++ compiler (g++) for compiler changes, and testing the C++ library (libstdc++) for library changes. @@ -430,7 +410,7 @@ and other detailed data is not displayed with this flag.

    Perhaps there are other C++ ABI checkers. If so, please notify us. We'd like to know about them! -

    Multiple ABI Testing

    +

    Multiple ABI Testing

    A "C" application, dynamically linked to two shared libraries, liba, libb. The dependent library liba is a C++ shared library compiled with GCC 3.3, and uses io, exceptions, locale, etc. The dependent library @@ -493,7 +473,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. This resulting binary, when executed, will be able to safely use code from both liba, and the dependent libstdc++.so.6, and libb, with the dependent libstdc++.so.5. -

    Outstanding Issues

    +

    Outstanding Issues

    Some features in the C++ language make versioning especially difficult. In particular, compiler generated constructs such as implicit instantiations for templates, typeinfo information, and @@ -506,51 +486,51 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. 24660: versioning weak symbols in libstdc++

    19664: libstdc++ headers should have pop/push of the visibility around the declarations -

    Bibliography

    [biblio.abicheck] +

    Bibliography

    [biblio.abicheck] ABIcheck - .

    [biblio.cxxabi] + .

    [biblio.cxxabi] C++ ABI Summary - .

    + .

    Intel Compilers for Linux Compatibility with the GNU Compilers - .

    + .

    Linker and Libraries Guide (document 819-0690) - .

    + .

    Sun Studio 11: C++ Migration Guide (document 819-3689) - .

    + .

    How to Write Shared Libraries - . Ulrich Drepper.

    + . Ulrich Drepper.

    C++ ABI for the ARM Architecture - .

    + .

    Dynamic Shared Objects: Survey and Issues - . + . ISO C++ J16/06-0046 - . Benjamin Kosnik.

    + . Benjamin Kosnik.

    Versioning With Namespaces - . + . ISO C++ J16/06-0083 - . Benjamin Kosnik.

    + . Benjamin Kosnik.

    Binary Compatibility of Shared Libraries Implemented in C++ on GNU/Linux Systems - . + . SYRCoSE 2009 - . Pavel Shved. Denis Silakov.

    Prev Up Next
    Test Home API Evolution and Deprecation History
    + . Pavel Shved. Denis Silakov.

    Prev Up Next
    Test Home API Evolution and Deprecation History
    diff --git a/libstdc++-v3/doc/html/manual/algorithms.html b/libstdc++-v3/doc/html/manual/algorithms.html index bf3cee1d07f..726fdfb01c0 100644 --- a/libstdc++-v3/doc/html/manual/algorithms.html +++ b/libstdc++-v3/doc/html/manual/algorithms.html @@ -1,24 +1,14 @@ -Chapter 11.  Algorithms
    Chapter 11.  + + +Chapter 11.  Algorithms
    Chapter 11.  Algorithms
    Prev Part II.  Standard Contents -  Next

    Chapter 11.  +

    		 Next

    Chapter 11.  Algorithms - -

    Table of Contents

    Mutating
    swap
    Specializations

    + +

    Table of Contents

    Mutating
    swap
    Specializations

    The neatest accomplishment of the algorithms section is that all the work is done via iterators, not containers directly. This means two important things: @@ -52,7 +42,7 @@ to cause so much confusion. Once you get range into your head (it's not that hard, honest!), then the algorithms are a cakewalk. -

    Mutating

    swap

    Specializations

    If you call std::swap(x,y); where x and y are standard +

    Mutating

    swap

    Specializations

    If you call std::swap(x,y); where x and y are standard containers, then the call will automatically be replaced by a call to x.swap(y); instead.

    This allows member functions of each container class to take over, and @@ -62,7 +52,7 @@ fact use constant-time swaps.) This should not be surprising, since for two containers of the same type to swap contents, only some internal pointers to storage need to be exchanged. -

    Prev Up Next
    Chapter 10.  +

    Prev Up Next
    Chapter 10.  Iterators  Home Chapter 12.  diff --git a/libstdc++-v3/doc/html/manual/api.html b/libstdc++-v3/doc/html/manual/api.html index 0e791310ed3..f5eff465638 100644 --- a/libstdc++-v3/doc/html/manual/api.html +++ b/libstdc++-v3/doc/html/manual/api.html @@ -1,19 +1,11 @@ -API Evolution and Deprecation History
    API Evolution and Deprecation History
    Prev Appendix B.  + + +API Evolution and Deprecation History
    API Evolution and Deprecation History
    Prev Appendix B.  Porting and Maintenance - Next

    API Evolution and Deprecation History

    +

    		 Next

    API Evolution and Deprecation History

    A list of user-visible changes, in chronological order -

    3.0

    +

    3.0

    Extensions moved to include/ext.

    Include files from the SGI/HP sources that pre-date the ISO standard @@ -22,7 +14,7 @@ the include/backward directory and a deprecated wa is added that notifies on inclusion (-Wno-deprecated deactivates the warning.)

    Deprecated include backward/strstream added.

    Removal of include builtinbuf.h, indstream.h, parsestream.h, PlotFile.h, SFile.h, stdiostream.h, and stream.h. -

    3.1

    +

    3.1

    Extensions from SGI/HP moved from namespace std to namespace __gnu_cxx. As part of this, the following @@ -34,7 +26,7 @@ Extensions to basic_filebuf introduced: ext/rb_tree.

    Removal of ext/tree, moved to backward/tree.h. -

    3.2

    +

    3.2

    Symbol versioning introduced for shared library.

    Removal of include backward/strstream.h.

    Allocator changes. Change __malloc_alloc to malloc_allocator and __new_alloc to new_allocator.

    For GCC releases from 2.95 through the 3.1 series, defining __USE_MALLOC on the gcc command line would change the default allocation strategy to instead use malloc and @@ -44,8 +36,8 @@ Removal of ext/tree, moved to GLIBCXX_FORCE_NEW in the environment, see the mt allocator chapter for details. -

    Error handling in iostreams cleaned up, made consistent.

    3.3

    -

    3.4

    +

    Error handling in iostreams cleaned up, made consistent.

    3.3

    +

    3.4

    Large file support.

    Extensions for generic characters and char_traits added in ext/pod_char_traits.h. @@ -86,11 +78,11 @@ _Alloc_traits have been removed. __alloc to select an underlying allocator that satisfied memory allocation requests. The selection of this underlying allocator was not user-configurable. -

    Table B.6. Extension Allocators

    Allocator (3.4)Header (3.4)Allocator (3.[0-3])Header (3.[0-3])
    __gnu_cxx::new_allocator<T>ext/new_allocator.hstd::__new_allocmemory
    __gnu_cxx::malloc_allocator<T>ext/malloc_allocator.hstd::__malloc_alloc_template<int>memory
    __gnu_cxx::debug_allocator<T>ext/debug_allocator.hstd::debug_alloc<T>memory
    __gnu_cxx::__pool_alloc<T>ext/pool_allocator.hstd::__default_alloc_template<bool,int>memory
    __gnu_cxx::__mt_alloc<T>ext/mt_allocator.h
    __gnu_cxx::bitmap_allocator<T>ext/bitmap_allocator.h

    Releases after gcc-3.4 have continued to add to the collection +

    Table B.6. Extension Allocators

    Allocator (3.4)Header (3.4)Allocator (3.[0-3])Header (3.[0-3])
    __gnu_cxx::new_allocator<T>ext/new_allocator.hstd::__new_allocmemory
    __gnu_cxx::malloc_allocator<T>ext/malloc_allocator.hstd::__malloc_alloc_template<int>memory
    __gnu_cxx::debug_allocator<T>ext/debug_allocator.hstd::debug_alloc<T>memory
    __gnu_cxx::__pool_alloc<T>ext/pool_allocator.hstd::__default_alloc_template<bool,int>memory
    __gnu_cxx::__mt_alloc<T>ext/mt_allocator.h
    __gnu_cxx::bitmap_allocator<T>ext/bitmap_allocator.h

    Releases after gcc-3.4 have continued to add to the collection of available allocators. All of these new allocators are standard-style. The following table includes details, along with the first released version of GCC that included the extension allocator. -

    Table B.7. Extension Allocators Continued

    AllocatorIncludeVersion
    __gnu_cxx::array_allocator<T>ext/array_allocator.h4.0.0
    __gnu_cxx::throw_allocator<T>ext/throw_allocator.h4.2.0

    +

    Table B.7. Extension Allocators Continued

    AllocatorIncludeVersion
    __gnu_cxx::array_allocator<T>ext/array_allocator.h4.0.0
    __gnu_cxx::throw_allocator<T>ext/throw_allocator.h4.2.0

    Debug mode first appears.

    Precompiled header support PCH support. @@ -100,7 +92,7 @@ Macro guard for changed, from _GLIBCPP_ to ext/stdio_sync_filebuf.h added.

    Extension ext/demangle.h added. -

    4.0

    +

    4.0

    TR1 features first appear.

    @@ -109,14 +101,14 @@ Extension allocator ext/array_allocator.h added. Extension codecvt specializations moved to ext/codecvt_specializations.h.

    Removal of ext/demangle.h. -

    4.1

    +

    4.1

    Removal of cassert from all standard headers: now has to be explicitly included for std::assert calls.

    Extensions for policy-based data structures first added. New includes, types, namespace pb_assoc.

    Extensions for typelists added in ext/typelist.h.

    Extension for policy-based basic_string first added: __gnu_cxx::__versa_string in ext/vstring.h. -

    4.2

    +

    4.2

    Default visibility attributes applied to namespace std. Support for -fvisibility.

    TR1 random, complex, and C compatibility headers added.

    Extensions for concurrent programming consolidated into ext/concurrence.h and ext/atomicity.h, @@ -131,7 +123,7 @@ types, namespace moved to __pb_ds. std::__debug and extensions in namespace __gnu_cxx::__debug.

    Extensions added: ext/typelist.h and ext/throw_allocator.h. -

    4.3

    +

    4.3

    C++0X features first appear.

    TR1 regex and cmath's mathematical special function added. @@ -163,7 +155,7 @@ Parallel mode first appears. PCH binary files no longer installed. Instead, the source files are installed.

    Namespace pb_ds moved to __gnu_pb_ds. -

    4.4

    +

    4.4

    C++0X features.

    • @@ -218,7 +210,7 @@ and ext/extptr_allocator.h. Support for non-standard pointer types has been added to vector and forward_list. -

    4.5

    +

    4.5

    C++0X features.

    • @@ -248,4 +240,4 @@ The default behavior for comparing typeinfo names changed, so in typeinfo, __GXX_MERGED_TYPEINFO_NAMES now defaults to zero.

      Extensions modified: ext/throw_allocator.h. -

    Prev Up Next
    ABI Policy and Guidelines Home Backwards Compatibility
    +

    Prev Up Next
    ABI Policy and Guidelines Home Backwards Compatibility
    diff --git a/libstdc++-v3/doc/html/manual/appendix_contributing.html b/libstdc++-v3/doc/html/manual/appendix_contributing.html index 7175f75865f..1e285745d38 100644 --- a/libstdc++-v3/doc/html/manual/appendix_contributing.html +++ b/libstdc++-v3/doc/html/manual/appendix_contributing.html @@ -1,27 +1,19 @@ -Appendix A.  Contributing
    Appendix A.  + + +Appendix A.  Contributing
    Appendix A.  Contributing
    Prev Part IV.  Appendices - Next

    +

    		 Next

    Contributing - -

    Table of Contents

    Contributor Checklist
    Reading
    Assignment
    Getting Sources
    Submitting Patches
    Directory Layout and Source Conventions
    Coding Style
    Bad Identifiers
    By Example
    Design Notes

    + +

    Table of Contents

    Contributor Checklist
    Reading
    Assignment
    Getting Sources
    Submitting Patches
    Directory Layout and Source Conventions
    Coding Style
    Bad Identifiers
    By Example
    Design Notes

    The GNU C++ Library follows an open development model. Active contributors are assigned maintainer-ship responsibility, and given write access to the source repository. First time contributors should follow this procedure: -

    Contributor Checklist

    Reading

    • +

      Contributor Checklist

      Reading

      • Get and read the relevant sections of the C++ language specification. Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee @@ -56,7 +48,7 @@ And last but certainly not least, read the library-specific information found in Porting and Maintenance. -

      Assignment

      +

    Assignment

    Small changes can be accepted without a copyright assignment form on file. New code and additions to the library need completed copyright assignment form on file at the FSF. Note: your employer may be required @@ -83,10 +75,10 @@ requesting an assignment form from , please cc the libstdc++ maintainer above so that progress can be monitored. -

    Getting Sources

    +

    Getting Sources

    Getting write access (look for "Write after approval") -

    Submitting Patches

    +

    Submitting Patches

    Every patch must have several pieces of information before it can be properly evaluated. Ideally (and to ensure the fastest possible response from the maintainers) it would have all of these pieces: @@ -119,6 +111,6 @@ mail message and send it to libstdc++@gcc.gnu.org. All patches and related discussion should be sent to the libstdc++ mailing list. -

    Prev Up Next
    Part IV.  +

    Prev Up Next
    Part IV.  Appendices  Home Directory Layout and Source Conventions
    diff --git a/libstdc++-v3/doc/html/manual/appendix_free.html b/libstdc++-v3/doc/html/manual/appendix_free.html index 48ec0932562..7a95fef18bc 100644 --- a/libstdc++-v3/doc/html/manual/appendix_free.html +++ b/libstdc++-v3/doc/html/manual/appendix_free.html @@ -1,21 +1,13 @@ -Appendix C.  Free Software Needs Free Documentation
    Appendix C.  + + +Appendix C.  Free Software Needs Free Documentation
    Appendix C.  Free Software Needs Free Documentation
    Prev Part IV.  Appendices - Next

    +

    		 Next

    Free Software Needs Free Documentation - +

    The biggest deficiency in free operating systems is not in the software--it is the lack of good free manuals that we can include in @@ -129,6 +121,6 @@ prefer copylefted manuals to non-copylefted ones. that lists free books available from other publishers].

    Copyright © 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA

    Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this -notice is preserved.

    Report any problems or suggestions to .

    Prev Up Next
    Backwards Compatibility Home Appendix D.  +notice is preserved.

    Report any problems or suggestions to .

    Prev Up Next
    Backwards Compatibility Home Appendix D.  GNU General Public License version 3
    diff --git a/libstdc++-v3/doc/html/manual/appendix_gfdl.html b/libstdc++-v3/doc/html/manual/appendix_gfdl.html index d0c92d09f35..89632971f42 100644 --- a/libstdc++-v3/doc/html/manual/appendix_gfdl.html +++ b/libstdc++-v3/doc/html/manual/appendix_gfdl.html @@ -1,18 +1,14 @@ -Appendix E. GNU Free Documentation License
    Appendix E. GNU Free Documentation License
    Prev Part IV.  + + +Appendix E. GNU Free Documentation License
    Appendix E. GNU Free Documentation License
    Prev Part IV.  Appendices - Next

    GNU Free Documentation License

    Version 1.3, 3 November 2008

    +

    		 Next

    GNU Free Documentation License

    Version 1.3, 3 November 2008

    Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.

    Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. -

    +

    0. PREAMBLE

    The purpose of this License is to make a manual, textbook, or other @@ -35,7 +31,7 @@ for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. -

    +

    1. APPLICABILITY AND DEFINITIONS

    This License applies to any manual or other work, in any medium, that @@ -124,7 +120,7 @@ but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. -

    +

    2. VERBATIM COPYING

    You may copy and distribute the Document in any medium, either @@ -139,7 +135,7 @@

    You may also lend copies, under the same conditions stated above, and you may publicly display copies. -

    +

    3. COPYING IN QUANTITY

    If you publish printed copies (or copies in media that commonly have @@ -173,7 +169,7 @@ It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. -

    +

    4. MODIFICATIONS

    You may copy and distribute a Modified Version of the Document under the @@ -273,7 +269,7 @@ The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. -

    +

    5. COMBINING DOCUMENTS

    You may combine the Document with other documents released under this @@ -298,7 +294,7 @@ Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements”. -

    +

    6. COLLECTIONS OF DOCUMENTS

    You may make a collection consisting of the Document and other documents @@ -311,7 +307,7 @@ it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. -

    +

    7. AGGREGATION WITH INDEPENDENT WORKS

    A compilation of the Document or its derivatives with other separate and @@ -329,7 +325,7 @@ bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. -

    +

    8. TRANSLATION

    Translation is considered a kind of modification, so you may distribute @@ -348,7 +344,7 @@ “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. -

    +

    9. TERMINATION

    You may not copy, modify, sublicense, or distribute the Document except as @@ -374,7 +370,7 @@ License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it. -

    +

    10. FUTURE REVISIONS OF THIS LICENSE

    The Free Software Foundation may publish new, revised versions of the GNU @@ -394,7 +390,7 @@ can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document. -

    +

    11. RELICENSING

    “Massive Multiauthor Collaboration Site” (or “MMC @@ -423,7 +419,7 @@ The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing. -

    +

    ADDENDUM: How to use this License for your documents

    To use this License in a document you have written, include a copy of the @@ -448,6 +444,6 @@ being LIST, and with the Back-Cover Texts being LIST.

    recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. -

    Prev Up Next
    Appendix D.  +

    Prev Up Next
    Appendix D.  GNU General Public License version 3  Home 
    diff --git a/libstdc++-v3/doc/html/manual/appendix_gpl.html b/libstdc++-v3/doc/html/manual/appendix_gpl.html index 136d59cfd1c..0965c585c03 100644 --- a/libstdc++-v3/doc/html/manual/appendix_gpl.html +++ b/libstdc++-v3/doc/html/manual/appendix_gpl.html @@ -1,14 +1,10 @@ -Appendix D.  GNU General Public License version 3
    Appendix D.  + + +Appendix D.  GNU General Public License version 3
    Appendix D.  GNU General Public License version 3
    Prev Part IV.  Appendices - Next

    +

    		 Next

    GNU General Public License version 3

    Version 3, 29 June 2007 @@ -18,7 +14,7 @@

    Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. -

    +

    Preamble

    The GNU General Public License is a free, copyleft @@ -82,9 +78,9 @@

    The precise terms and conditions for copying, distribution and modification follow. -

    +

    TERMS AND CONDITIONS -

    +

    0. Definitions.

    “This License” refers to version 3 of the GNU @@ -126,7 +122,7 @@ License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. -

    +

    1. Source Code.

    The “source code” for a work means the preferred form of the @@ -166,7 +162,7 @@ automatically from other parts of the Corresponding Source.

    The Corresponding Source for a work in source code form is that same work. -

    +

    2. Basic Permissions.

    All rights granted under this License are granted for the term of copyright @@ -191,7 +187,7 @@ Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. -

    +

    3. Protecting Users’ Legal Rights From Anti-Circumvention Law.

    No covered work shall be deemed part of an effective technological measure @@ -206,7 +202,7 @@ the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures. -

    +

    4. Conveying Verbatim Copies.

    You may convey verbatim copies of the Program’s source code as you @@ -219,7 +215,7 @@

    You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. -

    +

    5. Conveying Modified Source Versions.

    You may convey a work based on the Program, or the modifications to produce @@ -255,7 +251,7 @@ or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. -

    +

    6. Conveying Non-Source Forms.

    You may convey a covered work in object code form under the terms of @@ -350,7 +346,7 @@ (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying. -

    +

    7. Additional Terms.

    “Additional permissions” are terms that supplement the terms of @@ -414,7 +410,7 @@ Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. -

    +

    8. Termination.

    You may not propagate or modify a covered work except as expressly provided @@ -440,7 +436,7 @@ License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. -

    +

    9. Acceptance Not Required for Having Copies.

    You are not required to accept this License in order to receive or run a @@ -451,7 +447,7 @@ These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. -

    +

    10. Automatic Licensing of Downstream Recipients.

    Each time you convey a covered work, the recipient automatically receives a @@ -476,7 +472,7 @@ or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. -

    +

    11. Patents.

    A “contributor” is a copyright holder who authorizes use under @@ -543,7 +539,7 @@ Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. -

    +

    12. No Surrender of Others’ Freedom.

    If conditions are imposed on you (whether by court order, agreement or @@ -555,7 +551,7 @@ to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. -

    +

    13. Use with the GNU Affero General Public License.

    Notwithstanding any other provision of this License, you have permission to @@ -566,7 +562,7 @@ requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. -

    +

    14. Revised Versions of this License.

    The Free Software Foundation may publish revised and/or new versions of the @@ -591,7 +587,7 @@ Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version. -

    +

    15. Disclaimer of Warranty.

    THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE @@ -602,7 +598,7 @@ THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. -

    +

    16. Limitation of Liability.

    IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL @@ -614,7 +610,7 @@ PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. -

    +

    17. Interpretation of Sections 15 and 16.

    If the disclaimer of warranty and limitation of liability provided above @@ -623,9 +619,9 @@ waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. -

    +

    END OF TERMS AND CONDITIONS -

    +

    How to Apply These Terms to Your New Programs

    If you develop a new program, and you want it to be of the greatest possible @@ -681,7 +677,7 @@ under certain conditions; type ‘show c’ for det proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html. -

    Prev Up Next
    Appendix C.  +

    Prev Up Next
    Appendix C.  Free Software Needs Free Documentation  Home Appendix E. GNU Free Documentation License
    diff --git a/libstdc++-v3/doc/html/manual/appendix_porting.html b/libstdc++-v3/doc/html/manual/appendix_porting.html index 175d509d2f9..781e35ec9dc 100644 --- a/libstdc++-v3/doc/html/manual/appendix_porting.html +++ b/libstdc++-v3/doc/html/manual/appendix_porting.html @@ -1,22 +1,14 @@ -Appendix B.  Porting and Maintenance
    Appendix B.  + + +Appendix B.  Porting and Maintenance
    Appendix B.  Porting and Maintenance
    Prev Part IV.  Appendices - Next

    +

    		 Next

    Porting and Maintenance - -

    Table of Contents

    Configure and Build Hacking
    Prerequisites
    Overview: What Comes from Where
    Storing Information in non-AC files (like configure.host)
    Coding and Commenting Conventions
    The acinclude.m4 layout
    GLIBCXX_ENABLE, the --enable maker
    Writing and Generating Documentation
    Introduction
    Generating Documentation
    Doxygen
    Prerequisites
    Generating the Doxygen Files
    Markup
    Docbook
    Prerequisites
    Generating the DocBook Files
    Editing and Validation
    File Organization and Basics
    Markup By Example
    Porting to New Hardware or Operating Systems
    Operating System
    CPU
    Character Types
    Thread Safety
    Numeric Limits
    Libtool
    Test
    Organization
    Directory Layout
    Naming Conventions
    Running the Testsuite
    Basic
    Variations
    Permutations
    Writing a new test case
    Test Harness and Utilities
    Dejagnu Harness Details
    Utilities
    Special Topics
    + +

    Table of Contents

    Configure and Build Hacking
    Prerequisites
    Overview: What Comes from Where
    Storing Information in non-AC files (like configure.host)
    Coding and Commenting Conventions
    The acinclude.m4 layout
    GLIBCXX_ENABLE, the --enable maker
    Writing and Generating Documentation
    Introduction
    Generating Documentation
    Doxygen
    Prerequisites
    Generating the Doxygen Files
    Markup
    Docbook
    Prerequisites
    Generating the DocBook Files
    Editing and Validation
    File Organization and Basics
    Markup By Example
    Porting to New Hardware or Operating Systems
    Operating System
    CPU
    Character Types
    Thread Safety
    Numeric Limits
    Libtool
    Test
    Organization
    Directory Layout
    Naming Conventions
    Running the Testsuite
    Basic
    Variations
    Permutations
    Writing a new test case
    Test Harness and Utilities
    Dejagnu Harness Details
    Utilities
    Special Topics
    Qualifying Exception Safety Guarantees
    Overview
    @@ -38,7 +30,7 @@ Support for C++TR1 dialect. Support for C++11 dialect.
    Container::iterator_type is not necessarily Container::value_type* -

    Configure and Build Hacking

    Prerequisites

    +

    Configure and Build Hacking

    Prerequisites

    As noted previously, certain other tools are necessary for hacking on files that control configure (configure.ac, @@ -49,7 +41,7 @@ Support for C++11 dialect. in GCC try to stay in sync with each other in terms of versions of the auto-tools used, so please try to play nicely with the neighbors. -

    Overview: What Comes from Where

    Figure B.1. Configure and Build File Dependencies

    Dependency Graph for Configure and Build Files

    +

    Overview: What Comes from Where

    Figure B.1. Configure and Build File Dependencies

    Dependency Graph for Configure and Build Files

    Regenerate all generated files by using the command sequence "autoreconf" at the top level of the libstdc++ source directory. The following will also work, but is much more complex: @@ -59,7 +51,7 @@ Support for C++11 dialect. the current requirements and your vendor's choice of installation names. -

    Storing Information in non-AC files (like configure.host)

    +

    Storing Information in non-AC files (like configure.host)

    Until that glorious day when we can use AC_TRY_LINK with a cross-compiler, we have to hardcode the results of what the tests would have shown if they could be run. So we have an inflexible @@ -81,7 +73,7 @@ Support for C++11 dialect. for instance, but then we would need arguments to aclocal/autoconf to properly find them all when generating configure. I would discourage that. -

    Coding and Commenting Conventions

    +

    Coding and Commenting Conventions

    Most comments should use {octothorpes, shibboleths, hash marks, pound signs, whatever} rather than "dnl". Nearly all comments in configure.ac should. Comments inside macros written in ancilliary @@ -98,7 +90,7 @@ Support for C++11 dialect. Do not use any $target* variables, such as $target_alias. The single exception is in configure.ac, for automake+dejagnu's sake. -

    The acinclude.m4 layout

    +

    The acinclude.m4 layout

    The nice thing about acinclude.m4/aclocal.m4 is that macros aren't actually performed/called/expanded/whatever here, just loaded. So we can arrange the contents however we like. As of this writing, @@ -169,7 +161,7 @@ Support for C++11 dialect.

    Things which we don't seem to use directly, but just has to be present otherwise stuff magically goes wonky. -

    GLIBCXX_ENABLE, the --enable maker

    +

    GLIBCXX_ENABLE, the --enable maker

    All the GLIBCXX_ENABLE_FOO macros use a common helper, GLIBCXX_ENABLE. (You don't have to use it, but it's easy.) The helper does two things for us: @@ -257,4 +249,4 @@ Support for C++11 dialect. argument checking at all is done in this signature. See GLIBCXX_ENABLE_CXX_FLAGS for an example of handling, and an error message. -

    Prev Up Next
    Design Notes Home Writing and Generating Documentation
    +

    Prev Up Next
    Design Notes Home Writing and Generating Documentation
    diff --git a/libstdc++-v3/doc/html/manual/associative.html b/libstdc++-v3/doc/html/manual/associative.html index 26aae420a8a..2425b9960c9 100644 --- a/libstdc++-v3/doc/html/manual/associative.html +++ b/libstdc++-v3/doc/html/manual/associative.html @@ -1,17 +1,9 @@ -Associative
    Associative
    Prev Chapter 9.  + + +Associative
    Associative
    Prev Chapter 9.  Containers - Next

    Associative

    Insertion Hints

    +

    		 Next

    Associative

    Insertion Hints

    Section [23.1.2], Table 69, of the C++ standard lists this function for all of the associative containers (map, set, etc): 

    @@ -92,7 +84,7 @@
      the new item would in fact belong there.  If the hint does not
      point to the correct place, then no further local searching is
      done; the search begins from scratch in logarithmic time.
-

    bitset

    Size Variable

    +

    bitset

    Size Variable

    No, you cannot write code of the form 

           #include <bitset>
@@ -177,7 +169,7 @@
    
    
      Also note that the implementation of bitset used in libstdc++ has
      some extensions.
-

    Type String

    +

    Type String

    Bitmasks do not take char* nor const char* arguments in their constructors. This is something of an accident, but you can read @@ -194,7 +186,7 @@ instead of 

           std::bitset<5> b ( “10110” );    // invalid
-
    Prev Up Next
    Chapter 9.  +
    Prev Up Next
    Chapter 9.  Containers  Home Interacting with C
    diff --git a/libstdc++-v3/doc/html/manual/atomics.html b/libstdc++-v3/doc/html/manual/atomics.html index eb636c5644e..0a026bce34c 100644 --- a/libstdc++-v3/doc/html/manual/atomics.html +++ b/libstdc++-v3/doc/html/manual/atomics.html @@ -1,26 +1,16 @@ -Chapter 14.  Atomics
    Chapter 14.  + + +Chapter 14.  Atomics
    Chapter 14.  Atomics
    Prev Part II.  Standard Contents -  Next

    Chapter 14.  +

    		 Next

    Chapter 14.  Atomics - -

    Table of Contents

    API Reference

    + +

    Table of Contents

    API Reference

    Facilities for atomic operations. -

    API Reference

    +

    API Reference

    All items are declared in the standard header file atomic.

    @@ -35,7 +25,7 @@ atomic<int>.

    Full API details. -

    Prev Up Next
    Interacting with C Home Chapter 15.  +

    Prev Up Next
    Interacting with C Home Chapter 15.  Concurrency
    diff --git a/libstdc++-v3/doc/html/manual/backwards.html b/libstdc++-v3/doc/html/manual/backwards.html index a5984877151..b140fb9a9eb 100644 --- a/libstdc++-v3/doc/html/manual/backwards.html +++ b/libstdc++-v3/doc/html/manual/backwards.html @@ -1,21 +1,9 @@ -Backwards Compatibility
    Backwards Compatibility
    Prev Appendix B.  + + +Backwards Compatibility
    Backwards Compatibility
    Prev Appendix B.  Porting and Maintenance - Next

    Backwards Compatibility

    First

    The first generation GNU C++ library was called libg++. It was a +

    		 Next

    Backwards Compatibility

    First

    The first generation GNU C++ library was called libg++. It was a separate GNU project, although reliably paired with GCC. Rumors imply that it had a working relationship with at least two kinds of dinosaur. @@ -29,8 +17,8 @@ ISO Standard (e.g., statistical analysis). While there are a lot of really useful things that are used by a lot of people, the Standards Committee couldn't include everything, and so a lot of those “obvious” classes didn't get included. -

    Known Issues include many of the limitations of its immediate ancestor.

    Portability notes and known implementation limitations are as follows.

    No ios_base

    At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. -

    No cout in <ostream.h>, no cin in <istream.h>

    +

    Known Issues include many of the limitations of its immediate ancestor.

    Portability notes and known implementation limitations are as follows.

    No ios_base

    At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. +

    No cout in <ostream.h>, no cin in <istream.h>

    In earlier versions of the standard, <fstream.h>, <ostream.h> @@ -44,7 +32,7 @@ archived. For the desperate, the GCC extensions page describes where to find the last libg++ source. The code is considered replaced and rewritten. -

    Second

    +

    Second

    The second generation GNU C++ library was called libstdc++, or libstdc++-v2. It spans the time between libg++ and pre-ISO C++ standardization and is usually associated with the following GCC @@ -56,7 +44,7 @@ considered replaced and rewritten. archived. The code is considered replaced and rewritten.

    Portability notes and known implementation limitations are as follows. -

    Namespace std:: not supported

    +

    Namespace std:: not supported

    Some care is required to support C++ compiler and or library implementation that do not have the standard library in namespace std. @@ -120,7 +108,7 @@ AC_DEFUN([AC_CXX_NAMESPACE_STD], [ AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ]) fi ]) -

    Illegal iterator usage

    +

    Illegal iterator usage

    The following illustrate implementation-allowed illegal iterator use, and then correct use.

    • @@ -133,7 +121,7 @@ AC_DEFUN([AC_CXX_NAMESPACE_STD], [

    • if (iterator) won't work any more => use if (iterator != iterator_type()) -

    isspace from <cctype> is a macro +

    isspace from <cctype> is a macro

    Glibc 2.0.x and 2.1.x define <ctype.h> functionality as macros (isspace, isalpha etc.). @@ -167,7 +155,7 @@ std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; (<ctype.h>) and the definitions in namespace std:: (<cctype>). -

    No vector::at, deque::at, string::at

    +

    No vector::at, deque::at, string::at

    One solution is to add an autoconf-test for this: 

     AC_MSG_CHECKING(for container::at)
@@ -193,7 +181,7 @@ AC_DEFINE(HAVE_CONTAINER_AT)],

    If you are using other (non-GNU) compilers it might be a good idea to check for string::at separately. -

    No std::char_traits<char>::eof

    +

    No std::char_traits<char>::eof

    Use some kind of autoconf test, plus this: 

     #ifdef HAVE_CHAR_TRAITS
@@ -201,7 +189,7 @@ AC_DEFINE(HAVE_CONTAINER_AT)],
 #else
 #define CPP_EOF EOF
 #endif
-

    No string::clear

    +

    No string::clear

    There are two functions for deleting the contents of a string: clear and erase (the latter returns the string). @@ -219,12 +207,12 @@ erase(size_type __pos = 0, size_type __n = npos) Unfortunately, clear is not implemented in this version, so you should use erase (which is probably faster than operator=(charT*)). -

    +

    Removal of ostream::form and istream::scan extensions

    These are no longer supported. Please use stringstreams instead. -

    No basic_stringbuf, basic_stringstream

    +

    No basic_stringbuf, basic_stringstream

    Although the ISO standard i/ostringstream-classes are provided, (<sstream>), for compatibility with older implementations the pre-ISO @@ -312,14 +300,14 @@ any = temp; Another example of using stringstreams is in this howto.

    There is additional information in the libstdc++-v2 info files, in particular “info iostream”. -

    Little or no wide character support

    +

    Little or no wide character support

    Classes wstring and char_traits<wchar_t> are not supported. -

    No templatized iostreams

    +

    No templatized iostreams

    Classes wfilebuf and wstringstream are not supported. -

    Thread safety issues

    +

    Thread safety issues

    Earlier GCC releases had a somewhat different approach to threading configuration and proper compilation. Before GCC 3.0, configuration of the threading model was dictated by compiler @@ -370,14 +358,14 @@ particular “info iostream”

    Third

    The third generation GNU C++ library is called libstdc++, or +

    Third

    The third generation GNU C++ library is called libstdc++, or libstdc++-v3.

    The subset commonly known as the Standard Template Library (chapters 23 through 25, mostly) is adapted from the final release of the SGI STL (version 3.3), with extensive changes.

    A more formal description of the V3 goals can be found in the official design document. -

    Portability notes and known implementation limitations are as follows.

    Pre-ISO headers moved to backwards or removed

    The pre-ISO C++ headers +

    Portability notes and known implementation limitations are as follows.

    Pre-ISO headers moved to backwards or removed

    The pre-ISO C++ headers (<iostream.h>, <defalloc.h> etc.) are available, unlike previous libstdc++ versions, but inclusion @@ -450,7 +438,7 @@ like <vector.h> can be replaced with using namespace std; can be put at the global scope. This should be enough to get this code compiling, assuming the other usage is correct. -

    Extension headers hash_map, hash_set moved to ext or backwards

    At this time most of the features of the SGI STL extension have been +

    Extension headers hash_map, hash_set moved to ext or backwards

    At this time most of the features of the SGI STL extension have been replaced by standardized libraries. In particular, the unordered_map and unordered_set containers of TR1 and C++ 2011 @@ -524,7 +512,7 @@ AC_DEFUN([AC_HEADER_EXT_HASH_SET], [ AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ]) fi ]) -

    No ios::nocreate/ios::noreplace. +

    No ios::nocreate/ios::noreplace.

    The existence of ios::nocreate being used for input-streams has been confirmed, most probably because the author thought it would be more correct to specify nocreate explicitly. So @@ -535,7 +523,7 @@ open the file for reading, check if it has been opened, and then decide whether you want to create/replace or not. To my knowledge, even older implementations support app, ate and trunc (except for app ?). -

    +

    No stream::attach(int fd)

    Phil Edwards writes: It was considered and rejected for the ISO @@ -558,7 +546,7 @@ No stream::attach(int fd) For another example of this, refer to fdstream example by Nicolai Josuttis. -

    +

    Support for C++98 dialect.

    Check for complete library coverage of the C++1998/2003 standard. 

    @@ -626,7 +614,7 @@ AC_DEFUN([AC_HEADER_STDCXX_98], [
     AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ])
   fi
 ])
-

    +

    Support for C++TR1 dialect.

    Check for library coverage of the TR1 standard. 

    @@ -703,7 +691,7 @@ AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [
     AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ])
   fi
 ])
-

    +

    Support for C++11 dialect.

    Check for baseline language coverage in the compiler for the C++11 standard. 

    @@ -947,25 +935,25 @@ AC_DEFUN([AC_HEADER_UNORDERED_SET], [
   but the autoconf checks above could be extended to test for incomplete
   C++11 support with -std=c++0x and
   -std=gnu++0x.
-

    +

    Container::iterator_type is not necessarily Container::value_type*

    This is a change in behavior from older versions. Now, most iterator_type typedefs in container classes are POD objects, not value_type pointers. -

    Bibliography

    +

    Bibliography

    Migrating to GCC 4.1 - . Dan Kegel.

    + . Dan Kegel.

    Building the Whole Debian Archive with GCC 4.1: A Summary - . Martin Michlmayr.

    + . Martin Michlmayr.

    Migration guide for GCC-3.2 - .

    Prev Up Next
    API Evolution and Deprecation History Home Appendix C.  + .

    Prev Up Next
    API Evolution and Deprecation History Home Appendix C.  Free Software Needs Free Documentation
    diff --git a/libstdc++-v3/doc/html/manual/bitmap_allocator.html b/libstdc++-v3/doc/html/manual/bitmap_allocator.html index 07289501660..cb928833293 100644 --- a/libstdc++-v3/doc/html/manual/bitmap_allocator.html +++ b/libstdc++-v3/doc/html/manual/bitmap_allocator.html @@ -1,22 +1,10 @@ -Chapter 21. The bitmap_allocator
    Chapter 21. The bitmap_allocator
    Prev Part III.  + + +Chapter 21. The bitmap_allocator
    Chapter 21. The bitmap_allocator
    Prev Part III.  Extensions - Next

    Chapter 21. The bitmap_allocator

    Table of Contents

    Design
    Implementation
    Free List Store
    Super Block
    Super Block Data Layout
    Maximum Wasted Percentage
    allocate
    deallocate
    Questions
    1
    2
    3
    Locality
    Overhead and Grow Policy

    -

    Design

    +

    		 Next

    Chapter 21. The bitmap_allocator

    Table of Contents

    Design
    Implementation
    Free List Store
    Super Block
    Super Block Data Layout
    Maximum Wasted Percentage
    allocate
    deallocate
    Questions
    1
    2
    3
    Locality
    Overhead and Grow Policy

    +

    Design

    As this name suggests, this allocator uses a bit-map to keep track of the used and unused memory locations for its book-keeping purposes. @@ -42,4 +30,4 @@ Mutex Protection around every allocation/deallocation. The state of the macro is picked up automatically from the gthr abstraction layer. -

    Prev Up Next
    Multiple Thread Example Home Implementation
    +

    Prev Up Next
    Multiple Thread Example Home Implementation
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt02.html b/libstdc++-v3/doc/html/manual/bk01pt02.html index 360a1e3cafb..62163ab5605 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt02.html @@ -1,14 +1,10 @@ -Part II.  Standard Contents
    Part II.  + + +Part II.  Standard Contents
    Part II.  Standard Contents -
    Prev The GNU C++ Library Manual Next

    Part II.  +

    Prev The GNU C++ Library Manual Next

    Part II.  Standard Contents -

    Table of Contents

    4. +

    Table of Contents

    4. Support
    Types
    Fundamental Types
    Numeric Properties
    NULL
    Dynamic Memory
    Termination
    Termination Handlers
    Verbose Terminate Handler
    5. @@ -17,13 +13,13 @@
    Exceptions
    API Reference
    Adding Data to exception
    Concept Checking
    6. Utilities -
    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits
    7. +
    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits
    7. Strings
    String Classes
    Simple Transformations
    Case Sensitivity
    Arbitrary Character Types
    Tokenizing
    Shrink to Fit
    CString (MFC)
    8. Localization -
    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future
    9. +
    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future
    9. Containers
    Sequences
    list
    list::size() is O(n)
    vector
    Space Overhead Management
    Associative
    Insertion Hints
    bitset
    Size Variable
    Type String
    Interacting with C
    Containers vs. Arrays
    10. @@ -44,7 +40,7 @@
    API Reference
    15. Concurrency -
    API Reference
    Prev Up Next
    Debugging Support Home Chapter 4.  +
    API Reference
    Prev Up Next
    Debugging Support Home Chapter 4.  Support
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt02ch05s02.html b/libstdc++-v3/doc/html/manual/bk01pt02ch05s02.html index ec5117997a6..f4aa1c8bbbc 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt02ch05s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt02ch05s02.html @@ -1,17 +1,9 @@ -Concept Checking
    Concept Checking
    Prev Chapter 5.  + + +Concept Checking
    Concept Checking
    Prev Chapter 5.  Diagnostics - Next

    Concept Checking

    +

    		 Next

    Concept Checking

    In 1999, SGI added “concept checkers” to their implementation of the STL: code which checked the template parameters of instantiated pieces of the STL, in order to insure @@ -49,7 +41,7 @@ for example template argument types may need to be complete when used in a template definition, rather than at the point of instantiation. There are no plans to address these shortcomings. -

    Prev Up Next
    Chapter 5.  +

    Prev Up Next
    Chapter 5.  Diagnostics  Home Chapter 6.  diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch17s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch17s02.html index 05da2a6a8d2..7abfa972b1e 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch17s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch17s02.html @@ -1,20 +1,6 @@ -Semantics
    Semantics
    Prev Chapter 17. Debug Mode Next

    Semantics

    + + +Semantics

    Semantics
    Prev Chapter 17. Debug Mode Next

    Semantics

    A program that uses the C++ standard library correctly will maintain the same semantics under debug mode as it had with the normal (release) library. All functional and exception-handling @@ -66,4 +52,4 @@ with the debug-mode checks included, but this is unsupported and not guaranteed to work. For full debug-mode support you can use the __gnu_debug::basic_string debugging container directly, which always works correctly. -

    Prev Up Next
    Chapter 17. Debug Mode Home Using
    +

    Prev Up Next
    Chapter 17. Debug Mode Home Using
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html b/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html index 52de516e03a..c6154453e98 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html @@ -1,21 +1,7 @@ -Using
    Using
    Prev Chapter 17. Debug Mode Next

    Using

    -

    Using the Debug Mode

    To use the libstdc++ debug mode, compile your application with the + + +Using

    Using
    Prev Chapter 17. Debug Mode Next

    Using

    +

    Using the Debug Mode

    To use the libstdc++ debug mode, compile your application with the compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes and behavior of standard class templates such as std::vector, and therefore you can only link code @@ -24,7 +10,7 @@ units.

    By default, error messages are formatted to fit on lines of about 78 characters. The environment variable GLIBCXX_DEBUG_MESSAGE_LENGTH can be used to request a - different length.

    Using a Specific Debug Container

    When it is not feasible to recompile your entire application, or + different length.

    Using a Specific Debug Container

    When it is not feasible to recompile your entire application, or only specific containers need checking, debugging containers are available as GNU extensions. These debugging containers are functionally equivalent to the standard drop-in containers used in @@ -33,6 +19,6 @@ mode or with debug mode. The following table provides the names and headers of the debugging containers: -

    Table 17.1. Debugging Containers

    ContainerHeaderDebug containerDebug header
    std::bitsetbitset__gnu_debug::bitset<debug/bitset>
    std::dequedeque__gnu_debug::deque<debug/deque>
    std::listlist__gnu_debug::list<debug/list>
    std::mapmap__gnu_debug::map<debug/map>
    std::multimapmap__gnu_debug::multimap<debug/map>
    std::multisetset__gnu_debug::multiset<debug/set>
    std::setset__gnu_debug::set<debug/set>
    std::stringstring__gnu_debug::string<debug/string>
    std::wstringstring__gnu_debug::wstring<debug/string>
    std::basic_stringstring__gnu_debug::basic_string<debug/string>
    std::vectorvector__gnu_debug::vector<debug/vector>

    In addition, when compiling in C++11 mode, these additional +

    Table 17.1. Debugging Containers

    ContainerHeaderDebug containerDebug header
    std::bitsetbitset__gnu_debug::bitset<debug/bitset>
    std::dequedeque__gnu_debug::deque<debug/deque>
    std::listlist__gnu_debug::list<debug/list>
    std::mapmap__gnu_debug::map<debug/map>
    std::multimapmap__gnu_debug::multimap<debug/map>
    std::multisetset__gnu_debug::multiset<debug/set>
    std::setset__gnu_debug::set<debug/set>
    std::stringstring__gnu_debug::string<debug/string>
    std::wstringstring__gnu_debug::wstring<debug/string>
    std::basic_stringstring__gnu_debug::basic_string<debug/string>
    std::vectorvector__gnu_debug::vector<debug/vector>

    In addition, when compiling in C++11 mode, these additional containers have additional debug capability. -

    Table 17.2. Debugging Containers C++11

    ContainerHeaderDebug containerDebug header
    std::unordered_mapunordered_map__gnu_debug::unordered_map<debug/unordered_map>
    std::unordered_multimapunordered_map__gnu_debug::unordered_multimap<debug/unordered_map>
    std::unordered_setunordered_set__gnu_debug::unordered_set<debug/unordered_set>
    std::unordered_multisetunordered_set__gnu_debug::unordered_multiset<debug/unordered_set>

    Prev Up Next
    Semantics Home Design
    +

    Table 17.2. Debugging Containers C++11

    ContainerHeaderDebug containerDebug header
    std::unordered_mapunordered_map__gnu_debug::unordered_map<debug/unordered_map>
    std::unordered_multimapunordered_map__gnu_debug::unordered_multimap<debug/unordered_map>
    std::unordered_setunordered_set__gnu_debug::unordered_set<debug/unordered_set>
    std::unordered_multisetunordered_set__gnu_debug::unordered_multiset<debug/unordered_set>

    Prev Up Next
    Semantics Home Design
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch17s04.html b/libstdc++-v3/doc/html/manual/bk01pt03ch17s04.html index 91265f1644d..5222bdb7867 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch17s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch17s04.html @@ -1,21 +1,7 @@ -Design
    Design
    Prev Chapter 17. Debug Mode Next

    Design

    -

    Goals

    + + +Design

    Design
    Prev Chapter 17. Debug Mode Next

    Design

    +

    Goals

    The libstdc++ debug mode replaces unsafe (but efficient) standard containers and iterators with semantically equivalent safe standard containers and iterators to aid in debugging user programs. The @@ -103,10 +89,10 @@ (performance regression) or allocating extra memory associated with each iterator with new (changes the program semantics).

    -

    Methods

    +

    Methods

    This section provides an overall view of the design of the libstdc++ debug mode and details the relationship between design - decisions and the stated design goals.

    The Wrapper Model

    The libstdc++ debug mode uses a wrapper model where the + decisions and the stated design goals.

    The Wrapper Model

    The libstdc++ debug mode uses a wrapper model where the debugging versions of library components (e.g., iterators and containers) form a layer on top of the release versions of the library components. The debugging components first verify that the @@ -123,7 +109,7 @@ their associated containers, which are necessary to detect certain types of standard library usage errors such as dereferencing past-the-end iterators or inserting into a container using an - iterator from a different container.

    Safe Iterators

    Iterator wrappers provide a debugging layer over any iterator that + iterator from a different container.

    Safe Iterators

    Iterator wrappers provide a debugging layer over any iterator that is attached to a particular container, and will manage the information detailing the iterator's state (singular, dereferenceable, etc.) and tracking the container to which the @@ -135,7 +121,7 @@ typedef from the sequence type this iterator can reference.

  • Sequence: The type of sequence that this iterator references. This sequence must be a safe sequence (discussed below) whose iterator or const_iterator typedef - is the type of the safe iterator.

    • Safe Sequences (Containers)

    Container wrappers provide a debugging layer over a particular + is the type of the safe iterator.

    Safe Sequences (Containers)

    Container wrappers provide a debugging layer over a particular container type. Because containers vary greatly in the member functions they support and the semantics of those member functions (especially in the area of iterator invalidation), container @@ -171,7 +157,7 @@ template<typename _Tp, typename _Allocator = allocator<_Tp> // duplicate std::list interface with debugging semantics }; -

    Precondition Checking

    The debug mode operates primarily by checking the preconditions of +

    Precondition Checking

    The debug mode operates primarily by checking the preconditions of all standard library operations that it supports. Preconditions that are always checked (regardless of whether or not we are in debug mode) are checked via the __check_xxx macros defined @@ -198,7 +184,7 @@ template<typename _Tp, typename _Allocator = allocator<_Tp> cousin _GLIBCXX_DEBUG_PEDASSERT, or the assertion check macro that supports more advance formulation of error messages, _GLIBCXX_DEBUG_VERIFY. These macros are - documented more thoroughly in the debug mode source code.

    Release- and debug-mode coexistence

    The libstdc++ debug mode is the first debug mode we know of that + documented more thoroughly in the debug mode source code.

    Release- and debug-mode coexistence

    The libstdc++ debug mode is the first debug mode we know of that is able to provide the "Per-use recompilation" (4) guarantee, that allows release-compiled and debug-compiled code to be linked and executed together without causing unpredictable behavior. This @@ -214,7 +200,7 @@ template<typename _Tp, typename _Allocator = allocator<_Tp> recompilation but have had to give up some checking of the std::basic_string class template (namely, safe iterators). -

    Compile-time coexistence of release- and debug-mode components

    Both the release-mode components and the debug-mode +

    Compile-time coexistence of release- and debug-mode components

    Both the release-mode components and the debug-mode components need to exist within a single translation unit so that the debug versions can wrap the release versions. However, only one of these components should be user-visible at any particular @@ -268,7 +254,7 @@ namespace std // namespace __debug __attribute__ ((strong)); inline namespace __debug { } } -

    Link- and run-time coexistence of release- and +
    Link- and run-time coexistence of release- and debug-mode components

    Because each component has a distinct and separate release and debug implementation, there is no issue with link-time coexistence: the separate namespaces result in different mangled @@ -330,7 +316,7 @@ test02() changes. The effect on users is expected to be minimal, as there are simple alternatives (e.g., __gnu_debug::basic_string), and the usability benefit we gain from the ability to mix debug- and - release-compiled translation units is enormous.

    Alternatives for Coexistence

    The coexistence scheme above was chosen over many alternatives, + release-compiled translation units is enormous.

    Alternatives for Coexistence

    The coexistence scheme above was chosen over many alternatives, including language-only solutions and solutions that also required extensions to the C++ front end. The following is a partial list of solutions, with justifications for our rejection of each.

    • Completely separate debug/release libraries: This is by @@ -402,7 +388,7 @@ test02() that breaks user specialization), and additional testcases will be added as we are able to identify other typical problem cases. These test cases will serve as a benchmark by which we can compare debug - mode implementations.

    Other Implementations

    + mode implementations.

    Other Implementations

    There are several existing implementations of debug modes for C++ standard library implementations, although none of them directly supports debugging for programs using libstdc++. The existing @@ -423,4 +409,4 @@ test02() a full debug-mode implementation (including debugging for CodeWarrior extensions) and is easy to use, although it meets only the "Full recompilation" (1) recompilation - guarantee.

    Prev Up Next
    Using Home Chapter 18. Parallel Mode
    + guarantee.

    Prev Up Next
    Using Home Chapter 18. Parallel Mode
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch18s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch18s02.html index e7a98a3701a..82a9183168a 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch18s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch18s02.html @@ -1,20 +1,6 @@ -Semantics
    Semantics
    Prev Chapter 18. Parallel Mode Next

    Semantics

    The parallel mode STL algorithms are currently not exception-safe, + + +Semantics

    Semantics
    Prev Chapter 18. Parallel Mode Next

    Semantics

    The parallel mode STL algorithms are currently not exception-safe, i.e. user-defined functors must not throw exceptions. Also, the order of execution is not guaranteed for some functions, of course. Therefore, user-defined functors should not have any concurrent side effects. @@ -22,4 +8,4 @@ Therefore, user-defined functors should not have any concurrent side effects. OpenMP parallel regions in concurrent threads, it is not possible to call parallel STL algorithm in concurrent threads, either. -It might work with other compilers, though.

    Prev Up Next
    Chapter 18. Parallel Mode Home Using
    +It might work with other compilers, though.

    Prev Up Next
    Chapter 18. Parallel Mode Home Using
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html b/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html index 6885172ff5c..88ee85f2f93 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html @@ -1,20 +1,6 @@ -Using
    Using
    Prev Chapter 18. Parallel Mode Next

    Using

    Prerequisite Compiler Flags

    + + +Using

    Using
    Prev Chapter 18. Parallel Mode Next

    Using

    Prerequisite Compiler Flags

    Any use of parallel functionality requires additional compiler and runtime support, in particular support for OpenMP. Adding this support is not difficult: just compile your application with the compiler @@ -31,7 +17,7 @@ In addition, hardware that supports atomic operations and a compiler as -march=i686, -march=native or -mcpu=v9. See the GCC manual for more information. -

    Using Parallel Mode

    +

    Using Parallel Mode

    To use the libstdc++ parallel mode, compile your application with the prerequisite flags as detailed above, and in addition add -D_GLIBCXX_PARALLEL. This will convert all @@ -48,7 +34,7 @@ In addition, hardware that supports atomic operations and a compiler if no instantiation of a container is passed between the two translation units. Parallel mode functionality has distinct linkage, and cannot be confused with normal mode symbols. -

    Using Specific Parallel Components

    When it is not feasible to recompile your entire application, or +

    Using Specific Parallel Components

    When it is not feasible to recompile your entire application, or only specific algorithms need to be parallel-aware, individual parallel algorithms can be made available explicitly. These parallel algorithms are functionally equivalent to the standard @@ -77,4 +63,4 @@ Then compile this code with the prerequisite compiler flags flags for atomic operations.)

    The following table provides the names and headers of all the parallel algorithms that can be used in a similar manner: -

    Table 18.1. Parallel Algorithms

    AlgorithmHeaderParallel algorithmParallel header
    std::accumulatenumeric__gnu_parallel::accumulateparallel/numeric
    std::adjacent_differencenumeric__gnu_parallel::adjacent_differenceparallel/numeric
    std::inner_productnumeric__gnu_parallel::inner_productparallel/numeric
    std::partial_sumnumeric__gnu_parallel::partial_sumparallel/numeric
    std::adjacent_findalgorithm__gnu_parallel::adjacent_findparallel/algorithm
    std::countalgorithm__gnu_parallel::countparallel/algorithm
    std::count_ifalgorithm__gnu_parallel::count_ifparallel/algorithm
    std::equalalgorithm__gnu_parallel::equalparallel/algorithm
    std::findalgorithm__gnu_parallel::findparallel/algorithm
    std::find_ifalgorithm__gnu_parallel::find_ifparallel/algorithm
    std::find_first_ofalgorithm__gnu_parallel::find_first_ofparallel/algorithm
    std::for_eachalgorithm__gnu_parallel::for_eachparallel/algorithm
    std::generatealgorithm__gnu_parallel::generateparallel/algorithm
    std::generate_nalgorithm__gnu_parallel::generate_nparallel/algorithm
    std::lexicographical_comparealgorithm__gnu_parallel::lexicographical_compareparallel/algorithm
    std::mismatchalgorithm__gnu_parallel::mismatchparallel/algorithm
    std::searchalgorithm__gnu_parallel::searchparallel/algorithm
    std::search_nalgorithm__gnu_parallel::search_nparallel/algorithm
    std::transformalgorithm__gnu_parallel::transformparallel/algorithm
    std::replacealgorithm__gnu_parallel::replaceparallel/algorithm
    std::replace_ifalgorithm__gnu_parallel::replace_ifparallel/algorithm
    std::max_elementalgorithm__gnu_parallel::max_elementparallel/algorithm
    std::mergealgorithm__gnu_parallel::mergeparallel/algorithm
    std::min_elementalgorithm__gnu_parallel::min_elementparallel/algorithm
    std::nth_elementalgorithm__gnu_parallel::nth_elementparallel/algorithm
    std::partial_sortalgorithm__gnu_parallel::partial_sortparallel/algorithm
    std::partitionalgorithm__gnu_parallel::partitionparallel/algorithm
    std::random_shufflealgorithm__gnu_parallel::random_shuffleparallel/algorithm
    std::set_unionalgorithm__gnu_parallel::set_unionparallel/algorithm
    std::set_intersectionalgorithm__gnu_parallel::set_intersectionparallel/algorithm
    std::set_symmetric_differencealgorithm__gnu_parallel::set_symmetric_differenceparallel/algorithm
    std::set_differencealgorithm__gnu_parallel::set_differenceparallel/algorithm
    std::sortalgorithm__gnu_parallel::sortparallel/algorithm
    std::stable_sortalgorithm__gnu_parallel::stable_sortparallel/algorithm
    std::unique_copyalgorithm__gnu_parallel::unique_copyparallel/algorithm

    Prev Up Next
    Semantics Home Design
    +

    Table 18.1. Parallel Algorithms

    AlgorithmHeaderParallel algorithmParallel header
    std::accumulatenumeric__gnu_parallel::accumulateparallel/numeric
    std::adjacent_differencenumeric__gnu_parallel::adjacent_differenceparallel/numeric
    std::inner_productnumeric__gnu_parallel::inner_productparallel/numeric
    std::partial_sumnumeric__gnu_parallel::partial_sumparallel/numeric
    std::adjacent_findalgorithm__gnu_parallel::adjacent_findparallel/algorithm
    std::countalgorithm__gnu_parallel::countparallel/algorithm
    std::count_ifalgorithm__gnu_parallel::count_ifparallel/algorithm
    std::equalalgorithm__gnu_parallel::equalparallel/algorithm
    std::findalgorithm__gnu_parallel::findparallel/algorithm
    std::find_ifalgorithm__gnu_parallel::find_ifparallel/algorithm
    std::find_first_ofalgorithm__gnu_parallel::find_first_ofparallel/algorithm
    std::for_eachalgorithm__gnu_parallel::for_eachparallel/algorithm
    std::generatealgorithm__gnu_parallel::generateparallel/algorithm
    std::generate_nalgorithm__gnu_parallel::generate_nparallel/algorithm
    std::lexicographical_comparealgorithm__gnu_parallel::lexicographical_compareparallel/algorithm
    std::mismatchalgorithm__gnu_parallel::mismatchparallel/algorithm
    std::searchalgorithm__gnu_parallel::searchparallel/algorithm
    std::search_nalgorithm__gnu_parallel::search_nparallel/algorithm
    std::transformalgorithm__gnu_parallel::transformparallel/algorithm
    std::replacealgorithm__gnu_parallel::replaceparallel/algorithm
    std::replace_ifalgorithm__gnu_parallel::replace_ifparallel/algorithm
    std::max_elementalgorithm__gnu_parallel::max_elementparallel/algorithm
    std::mergealgorithm__gnu_parallel::mergeparallel/algorithm
    std::min_elementalgorithm__gnu_parallel::min_elementparallel/algorithm
    std::nth_elementalgorithm__gnu_parallel::nth_elementparallel/algorithm
    std::partial_sortalgorithm__gnu_parallel::partial_sortparallel/algorithm
    std::partitionalgorithm__gnu_parallel::partitionparallel/algorithm
    std::random_shufflealgorithm__gnu_parallel::random_shuffleparallel/algorithm
    std::set_unionalgorithm__gnu_parallel::set_unionparallel/algorithm
    std::set_intersectionalgorithm__gnu_parallel::set_intersectionparallel/algorithm
    std::set_symmetric_differencealgorithm__gnu_parallel::set_symmetric_differenceparallel/algorithm
    std::set_differencealgorithm__gnu_parallel::set_differenceparallel/algorithm
    std::sortalgorithm__gnu_parallel::sortparallel/algorithm
    std::stable_sortalgorithm__gnu_parallel::stable_sortparallel/algorithm
    std::unique_copyalgorithm__gnu_parallel::unique_copyparallel/algorithm

    Prev Up Next
    Semantics Home Design
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch18s04.html b/libstdc++-v3/doc/html/manual/bk01pt03ch18s04.html index 1e87375583e..baf2230d5a2 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch18s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch18s04.html @@ -1,21 +1,7 @@ -Design
    Design
    Prev Chapter 18. Parallel Mode Next

    Design

    -

    Interface Basics

    + + +Design

    Design
    Prev Chapter 18. Parallel Mode Next

    Design

    +

    Interface Basics

    All parallel algorithms are intended to have signatures that are equivalent to the ISO C++ algorithms replaced. For instance, the std::adjacent_find function is declared as: @@ -56,7 +42,7 @@ algorithms/algorithm classes.

    The general view of overloads for the paral ISO C++ signature to the correct parallel version. Also, some of the algorithms do not have support for run-time conditions, so the last overload is therefore missing. -

    Configuration and Tuning

    Setting up the OpenMP Environment

    +

    Configuration and Tuning

    Setting up the OpenMP Environment

    Several aspects of the overall runtime environment can be manipulated by standard OpenMP function calls.

    @@ -86,7 +72,7 @@ Other parts of the runtime environment able to be manipulated include nested parallelism (omp_set_nested), schedule kind (omp_set_schedule), and others. See the OpenMP documentation for more information. -

    Compile Time Switches

    +

    Compile Time Switches

    To force an algorithm to execute sequentially, even though parallelism is switched on in general via the macro _GLIBCXX_PARALLEL, add __gnu_parallel::sequential_tag() to the end @@ -140,7 +126,7 @@ several additional choices, namely __gnu_parallel::balanced_quicksort_tag. Multiway mergesort comes with the two splitting strategies for multi-way merging. The quicksort options cannot be used for stable_sort. -

    Run Time Settings and Defaults

    +

    Run Time Settings and Defaults

    The default parallelization strategy, the choice of specific algorithm strategy, the minimum threshold limits for individual parallel algorithms, and aspects of the underlying hardware can be specified as @@ -208,7 +194,7 @@ int main() return 0; } -

    Implementation Namespaces

    One namespace contain versions of code that are always +

    Implementation Namespaces

    One namespace contain versions of code that are always explicitly sequential: __gnu_serial.

    Two namespaces contain the parallel mode: @@ -224,4 +210,4 @@ __gnu_parallel.

    More information, and an organized index of types and functions related to the parallel mode on a per-namespace basis, can be found in the generated source documentation. -

    Prev Up Next
    Using Home Testing
    +

    Prev Up Next
    Using Home Testing
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch18s05.html b/libstdc++-v3/doc/html/manual/bk01pt03ch18s05.html index d6ed5e88617..d0c5c24f591 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch18s05.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch18s05.html @@ -1,20 +1,6 @@ -Testing
    Testing
    Prev Chapter 18. Parallel Mode Next

    Testing

    + + +Testing

    Testing
    Prev Chapter 18. Parallel Mode Next

    Testing

    Both the normal conformance and regression tests and the supplemental performance tests work.

    @@ -37,4 +23,4 @@ additional software dependencies than the usual bare-boned text file, and can be generated by using the make doc-performance rule in the testsuite's Makefile. -

    Prev Up Next
    Design Home Chapter 19. Profile Mode
    +

    Prev Up Next
    Design Home Chapter 19. Profile Mode
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html index eca2a7aa224..1cd563e52d4 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html @@ -1,24 +1,10 @@ -Design
    Design
    Prev Chapter 19. Profile Mode Next

    Design

    -

    Table 19.1. Profile Code Location

    Code LocationUse
    libstdc++-v3/include/std/*Preprocessor code to redirect to profile extension headers.
    libstdc++-v3/include/profile/*Profile extension public headers (map, vector, ...).
    libstdc++-v3/include/profile/impl/*Profile extension internals. Implementation files are + + +Design
    Design
    Prev Chapter 19. Profile Mode Next

    Design

    +

    Table 19.1. Profile Code Location

    Code LocationUse
    libstdc++-v3/include/std/*Preprocessor code to redirect to profile extension headers.
    libstdc++-v3/include/profile/*Profile extension public headers (map, vector, ...).
    libstdc++-v3/include/profile/impl/*Profile extension internals. Implementation files are only included from impl/profiler.h, which is the only - file included from the public headers.

    -

    Wrapper Model

    + file included from the public headers.


    +

    Wrapper Model

    In order to get our instrumented library version included instead of the release one, we use the same wrapper model as the debug mode. @@ -39,7 +25,7 @@ Currently, mixing the profile mode with debug and parallel extensions is not allowed. Mixing them at compile time will result in preprocessor errors. Mixing them at link time is undefined. -

    Instrumentation

    +

    Instrumentation

    Instead of instrumenting every public entry and exit point, we chose to add instrumentation on demand, as needed by individual diagnostics. @@ -58,7 +44,7 @@

    All the instrumentation on/off compile time switches live in include/profile/profiler.h. -

    Run Time Behavior

    +

    Run Time Behavior

    For practical reasons, the instrumentation library processes the trace partially rather than dumping it to disk in raw form. Each event is processed when @@ -77,14 +63,14 @@ For details, see paper presented at CGO 2009. -

    Analysis and Diagnostics

    +

    Analysis and Diagnostics

    Final analysis takes place offline, and it is based entirely on the generated trace and debugging info in the application binary. See section Diagnostics for a list of analysis types that we plan to support.

    The input to the analysis is a table indexed by profile type and call stack. The data type for each entry depends on the profile type. -

    Cost Model

    +

    Cost Model

    While it is likely that cost models become complex as we get into more sophisticated analysis, we will try to follow a simple set of rules at the beginning. @@ -112,7 +98,7 @@ For instance, when considering switching from set to unordered_set, if we detect use of operator ++, we will simply not issue the advice, since this could signal that the use - care require a sorted container.

    Reports

    + care require a sorted container.

    Reports

    There are two types of reports. First, if we recognize a pattern for which we have a substitute that is likely to give better performance, we print the advice and estimated performance gain. The advice is usually associated @@ -124,7 +110,7 @@ the top 10 multimap locations which have the worst data locality in actual traversals. Although this does not offer a solution, it helps the user focus on the key problems and ignore the uninteresting ones. -

    Testing

    +

    Testing

    First, we want to make sure we preserve the behavior of the release mode. You can just type "make check-profile", which builds and runs the whole test suite in profile mode. @@ -133,4 +119,4 @@ it helps the user focus on the key problems and ignore the uninteresting ones. We created a profile directory in the test suite. Each diagnostic must come with at least two tests, one for false positives and one for false negatives. -

    Prev Up Next
    Chapter 19. Profile Mode Home Extensions for Custom Containers
    +

    Prev Up Next
    Chapter 19. Profile Mode Home Extensions for Custom Containers
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s03.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s03.html index 4ff39cf537a..39318952a1c 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch19s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s03.html @@ -1,24 +1,10 @@ -Extensions for Custom Containers
    Extensions for Custom Containers
    Prev Chapter 19. Profile Mode Next

    Extensions for Custom Containers

    + + +Extensions for Custom Containers

    Extensions for Custom Containers
    Prev Chapter 19. Profile Mode Next

    Extensions for Custom Containers

    Many large projects use their own data structures instead of the ones in the standard library. If these data structures are similar in functionality to the standard library, they can be instrumented with the same hooks that are used to instrument the standard library. The instrumentation API is exposed in file profiler.h (look for "Instrumentation hooks"). -

    Prev Up Next
    Design Home Empirical Cost Model
    +

    Prev Up Next
    Design Home Empirical Cost Model
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s04.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s04.html index 91c64cf3224..36c252008a5 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch19s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s04.html @@ -1,20 +1,6 @@ -Empirical Cost Model
    Empirical Cost Model
    Prev Chapter 19. Profile Mode Next

    Empirical Cost Model

    + + +Empirical Cost Model

    Empirical Cost Model
    Prev Chapter 19. Profile Mode Next

    Empirical Cost Model

    Currently, the cost model uses formulas with predefined relative weights for alternative containers or container implementations. For instance, iterating through a vector is X times faster than iterating through a list. @@ -29,4 +15,4 @@ filled in either by hand or by an automated training mechanism. The analysis module will then use this database instead of the built in. generic parameters. -

    Prev Up Next
    Extensions for Custom Containers Home Implementation Issues
    +

    Prev Up Next
    Extensions for Custom Containers Home Implementation Issues
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html index ccbccc132c0..5b323918a5a 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html @@ -1,20 +1,6 @@ -Implementation Issues
    Implementation Issues
    Prev Chapter 19. Profile Mode Next

    Implementation Issues

    Stack Traces

    + + +Implementation Issues

    Implementation Issues
    Prev Chapter 19. Profile Mode Next

    Implementation Issues

    Stack Traces

    Accurate stack traces are needed during profiling since we group events by call context and dynamic instance. Without accurate traces, diagnostics may be hard to interpret. For instance, when giving advice to the user @@ -25,24 +11,24 @@ _GLIBCXX_PROFILE_STACK_DEPTH can be set to 0 if you are willing to give up call context information, or to a small positive value to reduce run time overhead. -

    Symbolization of Instruction Addresses

    +

    Symbolization of Instruction Addresses

    The profiling and analysis phases use only instruction addresses. An external utility such as addr2line is needed to postprocess the result. We do not plan to add symbolization support in the profile extension. This would require access to symbol tables, debug information tables, external programs or libraries and other system dependent information. -

    Concurrency

    +

    Concurrency

    Our current model is simplistic, but precise. We cannot afford to approximate because some of our diagnostics require precise matching of operations to container instance and call context. During profiling, we keep a single information table per diagnostic. There is a single lock per information table. -

    Using the Standard Library in the Instrumentation Implementation

    +

    Using the Standard Library in the Instrumentation Implementation

    As much as we would like to avoid uses of libstdc++ within our instrumentation library, containers such as unordered_map are very appealing. We plan to use them as long as they are named properly to avoid ambiguity. -

    Malloc Hooks

    +

    Malloc Hooks

    User applications/libraries can provide malloc hooks. When the implementation of the malloc hooks uses stdlibc++, there can be an infinite cycle between the profile mode instrumentation and the @@ -56,10 +42,10 @@ uses non-recursive locks. XXX: A definitive solution to this problem would be for the profile extension to use a custom allocator internally, and perhaps not to use libstdc++. -

    Construction and Destruction of Global Objects

    +

    Construction and Destruction of Global Objects

    The profiling library state is initialized at the first call to a profiling method. This allows us to record the construction of all global objects. However, we cannot do the same at destruction time. The trace is written by a function registered by atexit, thus invoked by exit. -

    Prev Up Next
    Empirical Cost Model Home Developer Information
    +

    Prev Up Next
    Empirical Cost Model Home Developer Information
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s06.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s06.html index 9fca3ed82ac..2d7d63cbf35 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch19s06.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s06.html @@ -1,20 +1,6 @@ -Developer Information
    Developer Information
    Prev Chapter 19. Profile Mode Next

    Developer Information

    Big Picture

    The profile mode headers are included with + + +Developer Information

    Developer Information
    Prev Chapter 19. Profile Mode Next

    Developer Information

    Big Picture

    The profile mode headers are included with -D_GLIBCXX_PROFILE through preprocessor directives in include/std/*.

    Instrumented implementations are provided in @@ -28,7 +14,7 @@ must ensure (1) that the call is guarded against reentrance and (2) that the call can be turned off at compile time using a -D_GLIBCXX_PROFILE_... compiler option. -

    How To Add A Diagnostic

    Let's say the diagnostic name is "magic". +

    How To Add A Diagnostic

    Let's say the diagnostic name is "magic".

    If you need to instrument a header not already under include/profile/*, first edit the corresponding header under include/std/ and add a preprocessor directive such @@ -79,4 +65,4 @@ include/profile/impl/profiler_trace.h. Use __trace_vector_to_list as an example.

    Add documentation in file doc/xml/manual/profile_mode.xml. -

    Prev Up Next
    Implementation Issues Home Diagnostics
    +

    Prev Up Next
    Implementation Issues Home Diagnostics
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html index 527af822780..78d11344be0 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html @@ -1,20 +1,6 @@ -Diagnostics
    Diagnostics
    Prev Chapter 19. Profile Mode Next

    Diagnostics

    + + +Diagnostics

    Diagnostics
    Prev Chapter 19. Profile Mode Next

    Diagnostics

    The table below presents all the diagnostics we intend to implement. Each diagnostic has a corresponding compile time switch -D_GLIBCXX_PROFILE_<diagnostic>. @@ -32,7 +18,7 @@ A high accuracy means that the diagnostic is unlikely to be wrong. These grades are not perfect. They are just meant to guide users with specific needs or time budgets. -

    Table 19.2. Profile Diagnostics

    GroupFlagBenefitCostFreq.Implemented 
    +

    Table 19.2. Profile Diagnostics

    GroupFlagBenefitCostFreq.Implemented 
    CONTAINERS HASHTABLE_TOO_SMALL101 10yes
      HASHTABLE_TOO_LARGE51 10yes
      @@ -49,7 +35,7 @@ LOCALITY SOFTWARE_PREFETCH88 5no
      RBTREE_LOCALITY48 5no
      - FALSE_SHARING810 10no

    Diagnostic Template

    • Switch: + FALSE_SHARING

    		810 10no

    Diagnostic Template

    • Switch: _GLIBCXX_PROFILE_<diagnostic>.

    • Goal: What problem will it diagnose?

    • Fundamentals:. @@ -66,10 +52,10 @@ program code ... advice sample

      -

    Containers

    +

    Containers

    Switch: _GLIBCXX_PROFILE_CONTAINERS. -

    Hashtable Too Small

    • Switch: +

      Hashtable Too Small

      • Switch: _GLIBCXX_PROFILE_HASHTABLE_TOO_SMALL.

      • Goal: Detect hashtables with many rehash operations, small construction size and large destruction size. @@ -95,7 +81,7 @@ advice sample foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1025530 rehash operations.

        -

      Hashtable Too Large

      • Switch: +

      Hashtable Too Large

      • Switch: _GLIBCXX_PROFILE_HASHTABLE_TOO_LARGE.

      • Goal: Detect hashtables which are never filled up because fewer elements than reserved are ever @@ -124,7 +110,7 @@ foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1 foo.cc:1: advice: Changing initial unordered_set size from 100 to 10 saves N bytes of memory and M iteration steps.

        -

      Inefficient Hash

      • Switch: +

      Inefficient Hash

      • Switch: _GLIBCXX_PROFILE_INEFFICIENT_HASH.

      • Goal: Detect hashtables with polarized distribution. @@ -155,7 +141,7 @@ class dumb_hash { hs.find(i); }

        -

      Vector Too Small

      • Switch: +

      Vector Too Small

      • Switch: _GLIBCXX_PROFILE_VECTOR_TOO_SMALL.

      • Goal:Detect vectors with many resize operations, small construction size and large destruction size.. @@ -180,7 +166,7 @@ class dumb_hash { foo.cc:1: advice: Changing initial vector size from 10 to 1000000 saves copying 4000000 bytes and 20 memory allocations and deallocations.

        -

      Vector Too Large

      • Switch: +

      Vector Too Large

      • Switch: _GLIBCXX_PROFILE_VECTOR_TOO_LARGE

      • Goal:Detect vectors which are never filled up because fewer elements than reserved are ever @@ -206,7 +192,7 @@ copying 4000000 bytes and 20 memory allocations and deallocations. foo.cc:1: advice: Changing initial vector size from 100 to 10 saves N bytes of memory and may reduce the number of cache and TLB misses.

        -

      Vector to Hashtable

      • Switch: +

      Vector to Hashtable

      • Switch: _GLIBCXX_PROFILE_VECTOR_TO_HASHTABLE.

      • Goal: Detect uses of vector that can be substituted with unordered_set @@ -237,7 +223,7 @@ bytes of memory and may reduce the number of cache and TLB misses. foo.cc:1: advice: Changing "vector" to "unordered_set" will save about 500,000 comparisons.

        -

      Hashtable to Vector

      • Switch: +

      Hashtable to Vector

      • Switch: _GLIBCXX_PROFILE_HASHTABLE_TO_VECTOR.

      • Goal: Detect uses of unordered_set that can be substituted with vector @@ -266,7 +252,7 @@ comparisons. foo.cc:1: advice: Changing "unordered_set" to "vector" will save about N indirections and may achieve better data locality.

        -

      Vector to List

      • Switch: +

      Vector to List

      • Switch: _GLIBCXX_PROFILE_VECTOR_TO_LIST.

      • Goal: Detect cases where vector could be substituted with list for @@ -296,7 +282,7 @@ indirections and may achieve better data locality. foo.cc:1: advice: Changing "vector" to "list" will save about 5,000,000 operations.

        -

      List to Vector

      • Switch: +

      List to Vector

      • Switch: _GLIBCXX_PROFILE_LIST_TO_VECTOR.

      • Goal: Detect cases where list could be substituted with vector for @@ -323,7 +309,7 @@ operations. foo.cc:1: advice: Changing "list" to "vector" will save about 1000000 indirect memory references.

        -

      List to Forward List (Slist)

      • Switch: +

      List to Forward List (Slist)

      • Switch: _GLIBCXX_PROFILE_LIST_TO_SLIST.

      • Goal: Detect cases where list could be substituted with forward_list for @@ -353,7 +339,7 @@ memory references. foo.cc:1: advice: Change "list" to "forward_list".

        -

      Ordered to Unordered Associative Container

      • Switch: +

      Ordered to Unordered Associative Container

      • Switch: _GLIBCXX_PROFILE_ORDERED_TO_UNORDERED.

      • Goal: Detect cases where ordered associative containers can be replaced with unordered ones. @@ -380,9 +366,9 @@ foo.cc:1: advice: Change "list" to "forward_list". 7 sum += *s.find(i); 8 }

        -

    Algorithms

    Switch: +

    Algorithms

    Switch: _GLIBCXX_PROFILE_ALGORITHMS. -

    Sort Algorithm Performance

    • Switch: +

      Sort Algorithm Performance

      • Switch: _GLIBCXX_PROFILE_SORT.

      • Goal: Give measure of sort algorithm performance based on actual input. For instance, advise Radix Sort over @@ -403,9 +389,9 @@ foo.cc:1: advice: Change "list" to "forward_list". Runtime(algo) for algo in [radix, quick, merge, ...]

      • Example:

        -

    Data Locality

    Switch: +

    Data Locality

    Switch: _GLIBCXX_PROFILE_LOCALITY. -

    Need Software Prefetch

    • Switch: +

      Need Software Prefetch

      • Switch: _GLIBCXX_PROFILE_SOFTWARE_PREFETCH.

      • Goal: Discover sequences of indirect memory accesses that are not regular, thus cannot be predicted by @@ -448,7 +434,7 @@ foo.cc:1: advice: Change "list" to "forward_list". foo.cc:7: advice: Insert prefetch instruction.

        -

      Linked Structure Locality

      • Switch: +

      Linked Structure Locality

      • Switch: _GLIBCXX_PROFILE_RBTREE_LOCALITY.

      • Goal: Give measure of locality of objects stored in linked structures (lists, red-black trees and hashtables) @@ -493,13 +479,13 @@ foo.cc:7: advice: Insert prefetch instruction. foo.cc:5: advice: High scatter score NNN for set built here. Consider changing the allocation sequence or switching to a structure conscious allocator.

        -

    Multithreaded Data Access

    +

    Multithreaded Data Access

    The diagnostics in this group are not meant to be implemented short term. They require compiler support to know when container elements are written to. Instrumentation can only tell us when elements are referenced.

    Switch: _GLIBCXX_PROFILE_MULTITHREADED. -

    Data Dependence Violations at Container Level

    • Switch: +

      Data Dependence Violations at Container Level

      • Switch: _GLIBCXX_PROFILE_DDTEST.

      • Goal: Detect container elements that are referenced from multiple threads in the parallel region or @@ -523,7 +509,7 @@ the allocation sequence or switching to a structure conscious allocator.

      • Example:

        -

      False Sharing

      • Switch: +

      False Sharing

      • Switch: _GLIBCXX_PROFILE_FALSE_SHARING.

      • Goal: Detect elements in the same container which share a cache line, are written by at least one @@ -556,7 +542,7 @@ OMP_NUM_THREADS=2 ./a.out foo.cc:1: advice: Change container structure or padding to avoid false sharing in multithreaded access at foo.cc:4. Detected N shared cache lines.

        -

    Statistics

    +

    Statistics

    Switch: _GLIBCXX_PROFILE_STATISTICS.

    @@ -569,4 +555,4 @@ sharing in multithreaded access at foo.cc:4. Detected N shared cache lines. This diagnostic will not issue any advice, but it will print statistics for each container construction site. The statistics will contain the cost of each operation actually performed on the container. -

    Prev Up Next
    Developer Information Home Chapter 20. The mt_allocator
    +

    Prev Up Next
    Developer Information Home Chapter 20. The mt_allocator
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch20s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch20s02.html index 01b74f78aa6..db0141c9281 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch20s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch20s02.html @@ -1,18 +1,6 @@ -Design Issues
    Design Issues
    Prev Chapter 20. The mt_allocator Next

    Design Issues

    Overview

    There are three general components to the allocator: a datum + + +Design Issues

    Design Issues
    Prev Chapter 20. The mt_allocator Next

    Design Issues

    Overview

    There are three general components to the allocator: a datum describing the characteristics of the memory pool, a policy class containing this pool that links instantiation types to common or individual pools, and a class inheriting from the policy class that is @@ -48,4 +36,4 @@ tuning, for instance.

    This class has the interface required for standard library allocator classes, namely member functions allocate and deallocate, plus others. -

    Prev Up Next
    Chapter 20. The mt_allocator Home Implementation
    +

    Prev Up Next
    Chapter 20. The mt_allocator Home Implementation
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch20s03.html b/libstdc++-v3/doc/html/manual/bk01pt03ch20s03.html index b250231a9f4..89066482cc8 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch20s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch20s03.html @@ -1,18 +1,6 @@ -Implementation
    Implementation
    Prev Chapter 20. The mt_allocator Next

    Implementation

    Tunable Parameters

    Certain allocation parameters can be modified, or tuned. There + + +Implementation

    Implementation
    Prev Chapter 20. The mt_allocator Next

    Implementation

    Tunable Parameters

    Certain allocation parameters can be modified, or tuned. There exists a nested struct __pool_base::_Tune that contains all these parameters, which include settings for

    • Alignment

    • Maximum bytes before calling ::operator new directly

    • Minimum bytes

    • Size of underlying global allocations

    • Maximum number of supported threads

    • Migration of deallocations to the global free list

    • Shunt for global new and delete

    Adjusting parameters for a given instance of an allocator can only @@ -51,7 +39,7 @@ int main() return 0; } -

    Initialization

    +

    Initialization

    The static variables (pointers to freelists, tuning parameters etc) are initialized as above, or are set to the global defaults.

    @@ -143,7 +131,7 @@ The _S_initialize() function: for this specific bin. This only occurs when a number of blocks are grabbed from the global list to a thread specific list or when a thread decides to return some blocks to the global freelist. -

    Deallocation Notes

    Notes about deallocation. This allocator does not explicitly +

    Deallocation Notes

    Notes about deallocation. This allocator does not explicitly release memory. Because of this, memory debugging programs like valgrind or purify may notice leaks: sorry about this inconvenience. Operating systems will reclaim allocated memory at @@ -170,4 +158,4 @@ implementation-specific, and subject to change. For an example of a pool that frees memory, see the following example. -

    Prev Up Next
    Design Issues Home Single Thread Example
    +

    Prev Up Next
    Design Issues Home Single Thread Example
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch20s04.html b/libstdc++-v3/doc/html/manual/bk01pt03ch20s04.html index 556cad61ca5..a094e221856 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch20s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch20s04.html @@ -1,18 +1,6 @@ -Single Thread Example
    Single Thread Example
    Prev Chapter 20. The mt_allocator Next

    Single Thread Example

    + + +Single Thread Example

    Single Thread Example
    Prev Chapter 20. The mt_allocator Next

    Single Thread Example

    Let's start by describing how the data on a freelist is laid out in memory. This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes): 

    @@ -88,4 +76,4 @@ of the global freelist and update the pointer as needed
 The decision to add deallocated blocks to the front of the freelist was made
 after a set of performance measurements that showed that this is roughly 10%
 faster than maintaining a set of "last pointers" as well.
-
    Prev Up Next
    Implementation Home Multiple Thread Example
    +

    Prev Up Next
    Implementation Home Multiple Thread Example
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch20s05.html b/libstdc++-v3/doc/html/manual/bk01pt03ch20s05.html index 8a77a056fd4..778b86c9a07 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch20s05.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch20s05.html @@ -1,18 +1,6 @@ -Multiple Thread Example
    Multiple Thread Example
    Prev Chapter 20. The mt_allocator Next

    Multiple Thread Example

    + + +Multiple Thread Example

    Multiple Thread Example
    Prev Chapter 20. The mt_allocator Next

    Multiple Thread Example

    In the ST example we never used the thread_id variable present in each block. Let's start by explaining the purpose of this in a MT application.

    @@ -116,4 +104,4 @@ mutex to be locked) this operation is also made in chunks of blocks a threads freelist mentioned above). The "formula" used can probably be improved to further reduce the risk of blocks being "bounced back and forth" between freelists. -

    Prev Up Next
    Single Thread Example Home Chapter 21. The bitmap_allocator
    +

    Prev Up Next
    Single Thread Example Home Chapter 21. The bitmap_allocator
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html index e9d73b96e90..84309ac46ba 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html @@ -1,18 +1,6 @@ -Implementation
    Implementation
    Prev Chapter 21. The bitmap_allocator Next

    Implementation

    Free List Store

    + + +Implementation

    Implementation
    Prev Chapter 21. The bitmap_allocator Next

    Implementation

    Free List Store

    The Free List Store (referred to as FLS for the remaining part of this document) is the Global memory pool that is shared by all instances of the bitmapped allocator instantiated for any type. This maintains a @@ -60,7 +48,7 @@ by a percentage of less than some THRESHOLD value, then return true, else return false.

    Currently, (3) is being used with a value of 36% Maximum wastage per Super Block. -

    Super Block

    +

    Super Block

    A super block is the block of memory acquired from the FLS from which the bitmap allocator carves out memory for single objects and satisfies the user's requests. These super blocks come in @@ -75,7 +63,7 @@ else return false.

    The super block is contained in the FLS, and the FLS is responsible for getting / returning Super Bocks to and from the OS using operator new as defined by the C++ standard. -

    Super Block Data Layout

    +

    Super Block Data Layout

    Each Super Block will be of some size that is a multiple of the number of Bits Per Block. Typically, this value is chosen as Bits_Per_Byte x sizeof(size_t). On an x86 system, this gives the @@ -88,7 +76,7 @@ else return false.

    Consider a block of size 64 ints. In memory, it would look like this: (assume a 32-bit system where, size_t is a 32-bit entity). -

    Table 21.1. Bitmap Allocator Memory Map

    268042949672954294967295Data -> Space for 64 ints

    +

    Table 21.1. Bitmap Allocator Memory Map

    268042949672954294967295Data -> Space for 64 ints

    The first Column(268) represents the size of the Block in bytes as seen by the Bitmap Allocator. Internally, a global free list is used to keep track of the free blocks used and given back by the @@ -115,7 +103,7 @@ else return false.

    The 3rd 4x2 is size of the bitmap itself, which is the size of 32-bits x 2, which is 8-bytes, or 2 x sizeof(size_t). -

    Maximum Wasted Percentage

    +

    Maximum Wasted Percentage

    This has nothing to do with the algorithm per-se, only with some vales that must be chosen correctly to ensure that the allocator performs well in a real word scenario, and maintains a good @@ -140,7 +128,7 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%

    Thus, knowing these values, and based on the sizeof(value_type), we may create a function that returns the Max_Wastage_Percentage for us to use. -

    allocate

    +

    allocate

    The allocate function is specialized for single object allocation ONLY. Thus, ONLY if n == 1, will the bitmap_allocator's specialized algorithm be used. Otherwise, the request is satisfied @@ -195,7 +183,7 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524% Thus, you can clearly see that the allocate function is nothing but a combination of the next-fit and first-fit algorithm optimized ONLY for single object allocations. -

    deallocate

    +

    deallocate

    The deallocate function again is specialized for single objects ONLY. For all n belonging to > 1, the operator delete is called without further ado, and the deallocate function returns. @@ -226,7 +214,7 @@ single object allocations. the vector. While doing this, we also make sure that the basic invariant is maintained by making sure that _S_last_request and _S_last_dealloc_index point to valid locations within the vector. -

    Questions

    1

    +

    Questions

    1

    Q1) The "Data Layout" section is cryptic. I have no idea of what you are trying to say. Layout of what? The free-list? Each bitmap? The Super Block? @@ -236,7 +224,7 @@ size. In the example, a super block of size 32 x 1 is taken. The general formula for calculating the size of a super block is 32 x sizeof(value_type) x 2^n, where n ranges from 0 to 32 for 32-bit systems. -

    2

    +

    2

    And since I just mentioned the term `each bitmap', what in the world is meant by it? What does each bitmap manage? How does it relate to the super block? Is the Super @@ -253,7 +241,7 @@ Block a bitmap as well? blocks' status. Each bit-map is made up of a number of size_t, whose exact number for a super-block of a given size I have just mentioned. -

    3

    +

    3

    How do the allocate and deallocate functions work in regard to bitmaps?

    @@ -282,7 +270,7 @@ Block a bitmap as well?

    The bit-map now looks like this: 1111111111111111111111111111111111111111111111111111111111111110 -

    Locality

    +

    Locality

    Another issue would be whether to keep the all bitmaps in a separate area in memory, or to keep them near the actual blocks that will be given out or allocated for the client. After some @@ -299,7 +287,7 @@ equivalent.

  • And also this would preserve the cac new_allocator's book keeping overhead is too much for small objects and single object allocations, though it preserves the locality of blocks very well when they are returned back to the allocator. -

    • Overhead and Grow Policy

    +

    Overhead and Grow Policy

    Expected overhead per block would be 1 bit in memory. Also, once the address of the free list has been found, the cost for allocation/deallocation would be negligible, and is supposed to be @@ -322,4 +310,4 @@ equivalent.

  • And also this would preserve the cac sizeof(size_t) x 8 which is the number of bits in an integer, which can fit exactly in a CPU register. Hence, the term given is exponential growth of the internal pool. -

    • Prev Up Next
    Chapter 21. The bitmap_allocator Home Chapter 22. Policy-Based Data Structures
    +

    Prev Up Next
    Chapter 21. The bitmap_allocator Home Chapter 22. Policy-Based Data Structures
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch23s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch23s02.html index a1d4fdcc08b..d37a538f5eb 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch23s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch23s02.html @@ -1,14 +1,6 @@ -Deprecated
    Deprecated
    Prev Chapter 23. HP/SGI Extensions Next

    Deprecated

    + + +Deprecated

    Deprecated
    Prev Chapter 23. HP/SGI Extensions Next

    Deprecated

    The SGI hashing classes hash_set and hash_set have been deprecated by the unordered_set, unordered_multiset, unordered_map, @@ -64,4 +56,4 @@ associative containers defined in the ISO C++ 2011 standard in the headers <unordered_map> and <unordered_set>. -

    Prev Up Next
    Chapter 23. HP/SGI Extensions Home Chapter 24. Utilities
    +

    Prev Up Next
    Chapter 23. HP/SGI Extensions Home Chapter 24. Utilities
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch30s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch30s02.html index df5b9d60a7a..f7abf820fac 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch30s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch30s02.html @@ -1,18 +1,6 @@ -Implementation
    Implementation
    Prev Chapter 30. Concurrency Next

    Implementation

    Using Builtin Atomic Functions

    The functions for atomic operations described above are either + + +Implementation

    Implementation
    Prev Chapter 30. Concurrency Next

    Implementation

    Using Builtin Atomic Functions

    The functions for atomic operations described above are either implemented via compiler intrinsics (if the underlying host is capable) or by library fallbacks.

    Compiler intrinsics (builtins) are always preferred. However, as the compiler builtins for atomics are not universally implemented, @@ -41,7 +29,7 @@ hardware, hand-crafted assembly is selected. This is the case for the following

    • cris

    • hppa

    • i386

    • i486

    • m48k

    • mips

    • sparc

    And for the rest, a simulated atomic lock via pthreads.

    Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation.

    More details on the library fallbacks from the porting section. -

    Thread Abstraction

    A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract +

    Thread Abstraction

    A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract the thread interface for GCC. This layer is called "gthread," and is comprised of one header file that wraps the host's default thread layer with a POSIX-like interface. @@ -54,4 +42,4 @@ use this layer. More detail as to the specific interface can be found in the sou functions, and usage found in the usual <pthread.h> file, including pthread_t, pthread_once_t, pthread_create, etc. -

    Prev Up Next
    Chapter 30. Concurrency Home Use
    +

    Prev Up Next
    Chapter 30. Concurrency Home Use
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch30s03.html b/libstdc++-v3/doc/html/manual/bk01pt03ch30s03.html index 49301aaa1f8..913d564823c 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch30s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch30s03.html @@ -1,18 +1,6 @@ -Use
    Use
    Prev Chapter 30. Concurrency Next

    Use

    Typical usage of the last two constructs is demonstrated as follows: + + +Use

    Use
    Prev Chapter 30. Concurrency Next

    Use

    Typical usage of the last two constructs is demonstrated as follows: 

     #include <ext/concurrence.h>
 
@@ -43,6 +31,6 @@ the mutex as control moves out of this block.
 concurrence-related errors. These classes
 are: __concurrence_lock_error, __concurrence_unlock_error, __concurrence_wait_error,
 and __concurrence_broadcast_error.
-
    Prev Up Next
    Implementation Home Part IV.  +

    Prev Up Next
    Implementation Home Part IV.  Appendices
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt03pr01.html b/libstdc++-v3/doc/html/manual/bk01pt03pr01.html index 8345c4a1db6..e496d4da1f4 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03pr01.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03pr01.html @@ -1,17 +1,9 @@ -
    Prev Part III.  + + +
    Prev Part III.  Extensions - Next

    +

    		 Next

    Here we will make an attempt at describing the non-Standard extensions to the library. Some of these are from older versions of standard library components, namely SGI's STL, and some of these are @@ -29,7 +21,7 @@ extensions, be aware of two things: treat them differently, or...

  • You should know how to access these headers properly. -

    • Prev Up Next
    Part III.  +

    Prev Up Next
    Part III.  Extensions  Home Chapter 16. Compile Time Checks
    diff --git a/libstdc++-v3/doc/html/manual/bk01pt04.html b/libstdc++-v3/doc/html/manual/bk01pt04.html index ab4ea3b8fff..47c3875cc85 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt04.html @@ -1,14 +1,10 @@ -Part IV.  Appendices
    Part IV.  + + +Part IV.  Appendices
    Part IV.  Appendices -
    Prev The GNU C++ Library Manual Next

    Part IV.  +

    Prev The GNU C++ Library Manual Next

    Part IV.  Appendices -

    Table of Contents

    A. +

    Table of Contents

    A. Contributing
    Contributor Checklist
    Reading
    Assignment
    Getting Sources
    Submitting Patches
    Directory Layout and Source Conventions
    Coding Style
    Bad Identifiers
    By Example
    Design Notes
    B. @@ -41,7 +37,7 @@ Support for C++11 dialect.
    D. GNU General Public License version 3 -
    E. GNU Free Documentation License
    Prev Up Next
    Use Home Appendix A.  +
    E. GNU Free Documentation License
    Prev Up Next
    Use Home Appendix A.  Contributing
    diff --git a/libstdc++-v3/doc/html/manual/bugs.html b/libstdc++-v3/doc/html/manual/bugs.html index 5b7a831bada..0464e8567da 100644 --- a/libstdc++-v3/doc/html/manual/bugs.html +++ b/libstdc++-v3/doc/html/manual/bugs.html @@ -1,18 +1,10 @@ -Bugs
    Bugs
    Prev Chapter 1. Status Next

    Bugs

    Implementation Bugs

    + + +Bugs

    Bugs
    Prev Chapter 1. Status Next

    Bugs

    Implementation Bugs

    Information on known bugs, details on efforts to fix them, and fixed bugs are all available as part of the GCC bug tracking system, with the category set to libstdc++. -

    Standard Bugs

    +

    Standard Bugs

    Everybody's got issues. Even the C++ Standard Library.

    The Library Working Group, or LWG, is the ISO subcommittee responsible @@ -357,4 +349,4 @@ More algorithms that throw away information

    The traditional HP / SGI return type and value is blessed by the resolution of the DR. -

    Prev Up Next
    License Home Chapter 2. Setup
    +

    Prev Up Next
    License Home Chapter 2. Setup
    diff --git a/libstdc++-v3/doc/html/manual/concurrency.html b/libstdc++-v3/doc/html/manual/concurrency.html index 31b91fd74e6..e743d3a3dc9 100644 --- a/libstdc++-v3/doc/html/manual/concurrency.html +++ b/libstdc++-v3/doc/html/manual/concurrency.html @@ -1,32 +1,16 @@ -Chapter 15.  Concurrency
    Chapter 15.  + + +Chapter 15.  Concurrency
    Chapter 15.  Concurrency
    Prev Part II.  Standard Contents -  Next

    Chapter 15.  +

    		 Next

    Chapter 15.  Concurrency - -

    Table of Contents

    API Reference

    + +

    Table of Contents

    API Reference

    Facilities for concurrent operation, and control thereof. -

    API Reference

    +

    API Reference

    All items are declared in one of four standard header files.

    In header mutex, class @@ -49,7 +33,7 @@ and packaged_task.

    Full API details. -

    Prev Up Next
    Chapter 14.  +

    Prev Up Next
    Chapter 14.  Atomics  Home Part III.  diff --git a/libstdc++-v3/doc/html/manual/configure.html b/libstdc++-v3/doc/html/manual/configure.html index 76c7a7478aa..a721df2cd75 100644 --- a/libstdc++-v3/doc/html/manual/configure.html +++ b/libstdc++-v3/doc/html/manual/configure.html @@ -1,20 +1,6 @@ -Configure
    Configure
    Prev Chapter 2. Setup Next

    Configure

    + + +Configure

    Configure
    Prev Chapter 2. Setup Next

    Configure

    When configuring libstdc++, you'll have to configure the entire gccsrcdir directory. Consider using the toplevel gcc configuration option @@ -229,4 +215,4 @@ freestanding environment, in which only a minimal set of headers are provided. This option builds such an environment. -

    Prev Up Next
    Chapter 2. Setup Home Make
    +

    Prev Up Next
    Chapter 2. Setup Home Make
    diff --git a/libstdc++-v3/doc/html/manual/containers.html b/libstdc++-v3/doc/html/manual/containers.html index 2c625db76c2..859a3562c2e 100644 --- a/libstdc++-v3/doc/html/manual/containers.html +++ b/libstdc++-v3/doc/html/manual/containers.html @@ -1,22 +1,14 @@ -Chapter 9.  Containers
    Chapter 9.  + + +Chapter 9.  Containers
    Chapter 9.  Containers
    Prev Part II.  Standard Contents -  Next

    Chapter 9.  +

    		 Next

    Chapter 9.  Containers - -

    Table of Contents

    Sequences
    list
    list::size() is O(n)
    vector
    Space Overhead Management
    Associative
    Insertion Hints
    bitset
    Size Variable
    Type String
    Interacting with C
    Containers vs. Arrays

    Sequences

    list

    list::size() is O(n)

    + +

    Table of Contents

    Sequences
    list
    list::size() is O(n)
    vector
    Space Overhead Management
    Associative
    Insertion Hints
    bitset
    Size Variable
    Type String
    Interacting with C
    Containers vs. Arrays

    Sequences

    list

    list::size() is O(n)

    Yes it is, and that's okay. This is a decision that we preserved when we imported SGI's STL implementation. The following is quoted from their FAQ: @@ -50,8 +42,8 @@ 

     	 if (L.empty())
 	     ...
-

    vector

    -

    Space Overhead Management

    +

    vector

    +

    Space Overhead Management

    In this message to the list, Daniel Kostecky announced work on an alternate form of std::vector that would support @@ -60,4 +52,4 @@

    The first two alpha releases were announced here and here. -

    Prev Up Next
    Facets Home Associative
    +

    Prev Up Next
    Facets Home Associative
    diff --git a/libstdc++-v3/doc/html/manual/containers_and_c.html b/libstdc++-v3/doc/html/manual/containers_and_c.html index f1b55a43bd2..13b1c9c654b 100644 --- a/libstdc++-v3/doc/html/manual/containers_and_c.html +++ b/libstdc++-v3/doc/html/manual/containers_and_c.html @@ -1,17 +1,9 @@ -Interacting with C
    Interacting with C
    Prev Chapter 9.  + + +Interacting with C
    Interacting with C
    Prev Chapter 9.  Containers - Next

    Interacting with C

    Containers vs. Arrays

    +

    		 Next

    Interacting with C

    Containers vs. Arrays

    You're writing some code and can't decide whether to use builtin arrays or some kind of container. There are compelling reasons to use one of the container classes, but you're afraid that @@ -92,7 +84,7 @@ template<typename T, unsigned int sz> inline unsigned int lengthof (T (&)[sz]) { return sz; }

    looks just weird! Hint: unused parameters can be left nameless. -

    Prev Up Next
    Associative Home Chapter 10.  +

    Prev Up Next
    Associative Home Chapter 10.  Iterators
    diff --git a/libstdc++-v3/doc/html/manual/debug.html b/libstdc++-v3/doc/html/manual/debug.html index e81be790fda..fc59e8d75d9 100644 --- a/libstdc++-v3/doc/html/manual/debug.html +++ b/libstdc++-v3/doc/html/manual/debug.html @@ -1,22 +1,10 @@ -Debugging Support
    Debugging Support
    Prev Chapter 3. Using Next

    Debugging Support

    + + +Debugging Support

    Debugging Support
    Prev Chapter 3. Using Next

    Debugging Support

    There are numerous things that can be done to improve the ease with which C++ binaries are debugged when using the GNU tool chain. Here are some of them. -

    Using g++

    +

    Using g++

    Compiler flags determine how debug information is transmitted between compilation and debug or analysis tools.

    @@ -43,7 +31,7 @@ Many other options are available: please see "Options for Debugging Your Program" in Using the GNU Compiler Collection (GCC) for a complete list. -

    Debug Versions of Library Binary Files

    +

    Debug Versions of Library Binary Files

    If you would like debug symbols in libstdc++, there are two ways to build libstdc++ with debug flags. The first is to create a separate debug build by running make from the top-level of a tree @@ -65,7 +53,7 @@

    This quick and dirty approach is often sufficient for quick debugging tasks, when you cannot or don't want to recompile your - application to use the debug mode.

    Memory Leak Hunting

    + application to use the debug mode.

    Memory Leak Hunting

    There are various third party memory tracing and debug utilities that can be used to provide detailed memory allocation information about C++ code. An exhaustive list of tools is not going to be @@ -134,7 +122,7 @@ up the runtime environment, library, and test file, might be: 

        valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
-

    Data Race Hunting

    +

    Data Race Hunting

    All synchronization primitives used in the library internals need to be understood by race detectors so that they do not produce false reports.

    @@ -184,7 +172,7 @@ #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(A) ANNOTATE_HAPPENS_AFTER(A)

    Refer to the documentation of each particular tool for details. -

    Using gdb

    +

    Using gdb

    Many options are available for GDB itself: please see "GDB features for C++" in the GDB documentation. Also @@ -237,18 +225,18 @@ on-line versions of the GDB user manual in GDB's homepage, at "GDB: The GNU Project Debugger" . -

    Tracking uncaught exceptions

    +

    Tracking uncaught exceptions

    The verbose termination handler gives information about uncaught exceptions which are killing the program. It is described in the linked-to page. -

    Debug Mode

    The Debug Mode +

    Debug Mode

    The Debug Mode has compile and run-time checks for many containers. -

    Compile Time Checking

    The Compile-Time +

    Compile Time Checking

    The Compile-Time Checks Extension has compile-time checks for many algorithms. -

    Profile-based Performance Analysis

    The Profile-based +

    Profile-based Performance Analysis

    The Profile-based Performance Analysis Extension has performance checks for many algorithms. -

    Prev Up Next
    Exceptions Home Part II.  +

    Prev Up Next
    Exceptions Home Part II.  Standard Contents
    diff --git a/libstdc++-v3/doc/html/manual/debug_mode.html b/libstdc++-v3/doc/html/manual/debug_mode.html index f851e71ed8d..4dc445189ea 100644 --- a/libstdc++-v3/doc/html/manual/debug_mode.html +++ b/libstdc++-v3/doc/html/manual/debug_mode.html @@ -1,24 +1,10 @@ -Chapter 17. Debug Mode
    Chapter 17. Debug Mode
    Prev Part III.  + + +Chapter 17. Debug Mode
    Chapter 17. Debug Mode
    Prev Part III.  Extensions - Next

    Chapter 17. Debug Mode

    Table of Contents

    Intro
    Semantics
    Using
    Using the Debug Mode
    Using a Specific Debug Container
    Design
    Goals
    Methods
    The Wrapper Model
    Safe Iterators
    Safe Sequences (Containers)
    Precondition Checking
    Release- and debug-mode coexistence
    Compile-time coexistence of release- and debug-mode components
    Link- and run-time coexistence of release- and - debug-mode components
    Alternatives for Coexistence
    Other Implementations

    Intro

    +

    		 Next

    Chapter 17. Debug Mode

    Table of Contents

    Intro
    Semantics
    Using
    Using the Debug Mode
    Using a Specific Debug Container
    Design
    Goals
    Methods
    The Wrapper Model
    Safe Iterators
    Safe Sequences (Containers)
    Precondition Checking
    Release- and debug-mode coexistence
    Compile-time coexistence of release- and debug-mode components
    Link- and run-time coexistence of release- and + debug-mode components
    Alternatives for Coexistence
    Other Implementations

    Intro

    By default, libstdc++ is built with efficiency in mind, and therefore performs little or no error checking that is not required by the C++ standard. This means that programs that @@ -49,4 +35,4 @@ the same predicate that was passed to set_intersection; the libstdc++ debug mode will detect an error if the sequence is not sorted or was sorted by a - different predicate.

    Prev Up Next
    Chapter 16. Compile Time Checks Home Semantics
    + different predicate.

    Prev Up Next
    Chapter 16. Compile Time Checks Home Semantics
    diff --git a/libstdc++-v3/doc/html/manual/diagnostics.html b/libstdc++-v3/doc/html/manual/diagnostics.html index 67950f2a298..de8905043f5 100644 --- a/libstdc++-v3/doc/html/manual/diagnostics.html +++ b/libstdc++-v3/doc/html/manual/diagnostics.html @@ -1,22 +1,14 @@ -Chapter 5.  Diagnostics
    Chapter 5.  + + +Chapter 5.  Diagnostics
    Chapter 5.  Diagnostics
    Prev Part II.  Standard Contents -  Next

    Chapter 5.  +

    		 Next

    Chapter 5.  Diagnostics - -

    Table of Contents

    Exceptions
    API Reference
    Adding Data to exception
    Concept Checking

    Exceptions

    API Reference

    + +

    Table of Contents

    Exceptions
    API Reference
    Adding Data to exception
    Concept Checking

    Exceptions

    API Reference

    All exception objects are defined in one of the standard header files: exception, stdexcept, new, and @@ -31,7 +23,7 @@ found in the source documentation.

    Full API details. -

    Adding Data to exception

    +

    Adding Data to exception

    The standard exception classes carry with them a single string as data (usually describing what went wrong or where the 'throw' took place). It's good to remember that you can add your own data to @@ -48,4 +40,4 @@ int e; DBID id; // some user-defined type }; -

    Prev Up Next
    Termination Home Concept Checking
    +
    Prev Up Next
    Termination Home Concept Checking
    diff --git a/libstdc++-v3/doc/html/manual/documentation_hacking.html b/libstdc++-v3/doc/html/manual/documentation_hacking.html index c5971c47372..825caa73a60 100644 --- a/libstdc++-v3/doc/html/manual/documentation_hacking.html +++ b/libstdc++-v3/doc/html/manual/documentation_hacking.html @@ -1,17 +1,9 @@ -Writing and Generating Documentation
    Writing and Generating Documentation
    Prev Appendix B.  + + +Writing and Generating Documentation
    Writing and Generating Documentation
    Prev Appendix B.  Porting and Maintenance - Next

    Writing and Generating Documentation

    Introduction

    +

    		 Next

    Writing and Generating Documentation

    Introduction

    Documentation for the GNU C++ Library is created from three independent sources: a manual, a FAQ, and an API reference.

    @@ -35,7 +27,7 @@ as per GNU Manuals. -

    Generating Documentation

    +

    Generating Documentation

    Certain Makefile rules are required by the GNU Coding Standards. These standard rules generate HTML, PDF, XML, or man files. For each of the generative rules, there is an additional @@ -125,7 +117,7 @@ supported, and are always aliased to dummy rules. These unsupported formats are: info, ps, and dvi. -

    Doxygen

    Prerequisites

    Table B.1. Doxygen Prerequisites

    ToolVersionRequired By
    coreutils8.5all
    bash4.1all
    doxygen1.7.6.1all
    graphviz2.26graphical hierarchies
    pdflatex2007-59pdf output

    +

    Doxygen

    Prerequisites

    Table B.1. Doxygen Prerequisites

    ToolVersionRequired By
    coreutils8.5all
    bash4.1all
    doxygen1.7.6.1all
    graphviz2.26graphical hierarchies
    pdflatex2007-59pdf output

    Prerequisite tools are Bash 2.0 or later, Doxygen, and the GNU @@ -147,7 +139,7 @@ capacity. Specifically, the pool_size variable in the configuration file texmf.cnf may need to be increased by a minimum factor of two. -

    Generating the Doxygen Files

    +

    Generating the Doxygen Files

    The following Makefile rules run Doxygen to generate HTML docs, XML docs, XML docs as a single file, PDF docs, and the man pages. These rules are not conditional! If the required @@ -179,7 +171,7 @@ If you wish to tweak the Doxygen settings, do so by editing doc/doxygen/user.cfg.in. Notes to fellow library hackers are written in triple-# comments. -

    Markup

    +

    Markup

    In general, libstdc++ files should be formatted according to the rules found in the Coding Standard. Before @@ -234,14 +226,14 @@ Complicated math functions should use the multi-line format. An example from random.h:

    -


    -/**
    - * @brief A model of a linear congruential random number generator.
    - *
    - * @f[
    - *     x_{i+1}\leftarrow(ax_{i} + c) \bmod m
    - * @f]
    - */
    +


    +/**
    + * @brief A model of a linear congruential random number generator.
    + *
    + * @f[
    + *     x_{i+1}\leftarrow(ax_{i} + c) \bmod m
    + * @f]
    + */

    One area of note is the markup required for @@ -250,10 +242,10 @@ multiple directories, include part of the installed path to disambiguate. For example:

    -


    -/** @file debug/vector
    - *  This file is a GNU debug extension to the Standard C++ Library.
    - */
    +


    +/** @file debug/vector
    + *  This file is a GNU debug extension to the Standard C++ Library.
    + */

    The other relevant detail for header files is the use of a @@ -268,18 +260,18 @@ headername in the file block. An example:

    -


    -/** @file bits/basic_string.h
    - *  This is an internal header file, included by other library headers.
    - *  Do not attempt to use it directly. @headername{string}
    - */
    +


    +/** @file bits/basic_string.h
    + *  This is an internal header file, included by other library headers.
    + *  Do not attempt to use it directly. @headername{string}
    + */

    Be careful about using certain, special characters when writing Doxygen comments. Single and double quotes, and separators in filenames are two common trouble spots. When in doubt, consult the following table. -

    Table B.2. HTML to Doxygen Markup Comparison

    HTMLDoxygen
    \\\
    "\"
    '\'
    <i>@a word
    <b>@b word
    <code>@c word
    <em>@a word
    <em><em>two words or more</em>

    Docbook

    Prerequisites

    Table B.3. Docbook Prerequisites

    ToolVersionRequired By
    docbook5-style-xsl1.76.1all
    xsltproc1.1.26all
    xmllint2.7.7validation
    dblatex0.3pdf output
    pdflatex2007-59pdf output
    docbook2X0.8.8info output
    epub3 stylesheetsb3epub output

    +

    Table B.2. HTML to Doxygen Markup Comparison

    HTMLDoxygen
    \\\
    "\"
    '\'
    <i>@a word
    <b>@b word
    <code>@c word
    <em>@a word
    <em><em>two words or more</em>

    Docbook

    Prerequisites

    Table B.3. Docbook Prerequisites

    ToolVersionRequired By
    docbook5-style-xsl1.76.1all
    xsltproc1.1.26all
    xmllint2.7.7validation
    dblatex0.3pdf output
    pdflatex2007-59pdf output
    docbook2X0.8.8info output
    epub3 stylesheetsb3epub output

    Editing the DocBook sources requires an XML editor. Many exist: some notable options include emacs, Kate, @@ -326,7 +318,7 @@ XML to Texinfo is required. The default choice is docbook2X.

    For epub output, the stylesheets for EPUB3 are required. These stylesheets are still in development. To validate the created file, epubcheck is necessary. -

    Generating the DocBook Files

    +

    Generating the DocBook Files

    The following Makefile rules generate (in order): an HTML version of all the DocBook documentation, a PDF version of the same, and a single XML document. These rules are not @@ -351,7 +343,7 @@ make XSL_STYLE_DIR="/usr/share/xml/docbook/stylesheet/nwalsh" doc-html-docbook -

    Editing and Validation

    +

    Editing and Validation

    After editing the xml sources, please make sure that the XML documentation and markup is still valid. This can be done easily, with the following validation rule: @@ -371,77 +363,77 @@ make XSL_STYLE_DIR="/usr/share/xml/docbook/stylesheet/nwal validation on the entire manual fails.

    All Docbook xml sources should always validate. No excuses! -

    File Organization and Basics


    -      Which files are important
    -
    -      All Docbook files are in the directory
    -      libstdc++-v3/doc/xml
    -
    -      Inside this directory, the files of importance:
    -      spine.xml   - index to documentation set
    -      manual/spine.xml  - index to manual
    -      manual/*.xml   - individual chapters and sections of the manual
    -      faq.xml   - index to FAQ
    -      api.xml   - index to source level / API
    -
    -      All *.txml files are template xml files, i.e., otherwise empty files with
    -      the correct structure, suitable for filling in with new information.
    -
    -      Canonical Writing Style
    -
    -      class template
    -      function template
    -      member function template
    -      (via C++ Templates, Vandevoorde)
    -
    -      class in namespace std: allocator, not std::allocator
    -
    -      header file: iostream, not <iostream>
    -
    -
    -      General structure
    -
    -      <set>
    -      <book>
    -      </book>
    -
    -      <book>
    -      <chapter>
    -      </chapter>
    -      </book>
    -
    -      <book>
    -      <part>
    -      <chapter>
    -      <section>
    -      </section>
    -
    -      <sect1>
    -      </sect1>
    -
    -      <sect1>
    -      <sect2>
    -      </sect2>
    -      </sect1>
    -      </chapter>
    -
    -      <chapter>
    -      </chapter>
    -      </part>
    -      </book>
    -
    -      </set>
    -    

    Markup By Example

    +

    File Organization and Basics


    +      Which files are important
    +
    +      All Docbook files are in the directory
    +      libstdc++-v3/doc/xml
    +
    +      Inside this directory, the files of importance:
    +      spine.xml   - index to documentation set
    +      manual/spine.xml  - index to manual
    +      manual/*.xml   - individual chapters and sections of the manual
    +      faq.xml   - index to FAQ
    +      api.xml   - index to source level / API
    +
    +      All *.txml files are template xml files, i.e., otherwise empty files with
    +      the correct structure, suitable for filling in with new information.
    +
    +      Canonical Writing Style
    +
    +      class template
    +      function template
    +      member function template
    +      (via C++ Templates, Vandevoorde)
    +
    +      class in namespace std: allocator, not std::allocator
    +
    +      header file: iostream, not <iostream>
    +
    +
    +      General structure
    +
    +      <set>
    +      <book>
    +      </book>
    +
    +      <book>
    +      <chapter>
    +      </chapter>
    +      </book>
    +
    +      <book>
    +      <part>
    +      <chapter>
    +      <section>
    +      </section>
    +
    +      <sect1>
    +      </sect1>
    +
    +      <sect1>
    +      <sect2>
    +      </sect2>
    +      </sect1>
    +      </chapter>
    +
    +      <chapter>
    +      </chapter>
    +      </part>
    +      </book>
    +
    +      </set>
    +    

    Markup By Example

    Complete details on Docbook markup can be found in the DocBook Element Reference, online. An incomplete reference for HTML to Docbook conversion is detailed in the table below. -

    Table B.4. HTML to Docbook XML Markup Comparison

    HTMLDocbook
    <p><para>
    <pre><computeroutput>, <programlisting>, - <literallayout>
    <ul><itemizedlist>
    <ol><orderedlist>
    <il><listitem>
    <dl><variablelist>
    <dt><term>
    <dd><listitem>
    <a href=""><ulink url="">
    <code><literal>, <programlisting>
    <strong><emphasis>
    <em><emphasis>
    "<quote>

    +

    Table B.4. HTML to Docbook XML Markup Comparison

    HTMLDocbook
    <p><para>
    <pre><computeroutput>, <programlisting>, + <literallayout>
    <ul><itemizedlist>
    <ol><orderedlist>
    <il><listitem>
    <dl><variablelist>
    <dt><term>
    <dd><listitem>
    <a href=""><ulink url="">
    <code><literal>, <programlisting>
    <strong><emphasis>
    <em><emphasis>
    "<quote>

    And examples of detailed markup for which there are no real HTML equivalents are listed in the table below. -

    Table B.5. Docbook XML Element Use

    ElementUse
    <structname><structname>char_traits</structname>
    <classname><classname>string</classname>
    <function> +

    Table B.5. Docbook XML Element Use

    ElementUse
    <structname><structname>char_traits</structname>
    <classname><classname>string</classname>
    <function>

    <function>clear()</function>

    <function>fs.clear()</function>

    <type><type>long long</type>
    <varname><varname>fs</varname>
    <literal> @@ -454,7 +446,7 @@ make XSL_STYLE_DIR="/usr/share/xml/docbook/stylesheet/nwal

    <filename class="headerfile">ctype.h</filename>

    <filename class="directory">/home/gcc/build</filename>

    <filename class="libraryfile">libstdc++.so</filename>

    -

    Prev Up Next
    Appendix B.  +

    Prev Up Next
    Appendix B.  Porting and Maintenance  Home Porting to New Hardware or Operating Systems
    diff --git a/libstdc++-v3/doc/html/manual/dynamic_memory.html b/libstdc++-v3/doc/html/manual/dynamic_memory.html index 31f45eae33a..93c460fed67 100644 --- a/libstdc++-v3/doc/html/manual/dynamic_memory.html +++ b/libstdc++-v3/doc/html/manual/dynamic_memory.html @@ -1,17 +1,9 @@ -Dynamic Memory
    Dynamic Memory
    Prev Chapter 4.  + + +Dynamic Memory
    Dynamic Memory
    Prev Chapter 4.  Support - Next

    Dynamic Memory

    +

    		 Next

    Dynamic Memory

    There are six flavors each of new and delete, so make certain that you're using the right ones. Here are quickie descriptions of new: @@ -74,7 +66,7 @@

    bad_alloc is derived from the base exception class defined in Sect1 19. -

    Prev Up Next
    Chapter 4.  +

    Prev Up Next
    Chapter 4.  Support  Home Termination
    diff --git a/libstdc++-v3/doc/html/manual/ext_algorithms.html b/libstdc++-v3/doc/html/manual/ext_algorithms.html index bd5d2b0ee9e..e6a9d8c50a7 100644 --- a/libstdc++-v3/doc/html/manual/ext_algorithms.html +++ b/libstdc++-v3/doc/html/manual/ext_algorithms.html @@ -1,17 +1,9 @@ -Chapter 25. Algorithms
    Chapter 25. Algorithms
    Prev Part III.  + + +Chapter 25. Algorithms
    Chapter 25. Algorithms
    Prev Part III.  Extensions - Next

    Chapter 25. Algorithms

    25.1.6 (count, count_if) is extended with two more versions of count +

    		 Next

    Chapter 25. Algorithms

    25.1.6 (count, count_if) is extended with two more versions of count and count_if. The standard versions return their results. The additional signatures return void, but take a final parameter by reference to which they assign their results, e.g., @@ -28,4 +20,4 @@ 

        lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
 				 _InputIter2 first2, _InputIter2 last2)

    which does... what? -

    Prev Up Next
    Chapter 24. Utilities Home Chapter 26. Numerics
    +

    Prev Up Next
    Chapter 24. Utilities Home Chapter 26. Numerics
    diff --git a/libstdc++-v3/doc/html/manual/ext_compile_checks.html b/libstdc++-v3/doc/html/manual/ext_compile_checks.html index 02633b387bf..306ca1a4b6e 100644 --- a/libstdc++-v3/doc/html/manual/ext_compile_checks.html +++ b/libstdc++-v3/doc/html/manual/ext_compile_checks.html @@ -1,17 +1,9 @@ -Chapter 16. Compile Time Checks
    Chapter 16. Compile Time Checks
    Prev Part III.  + + +Chapter 16. Compile Time Checks
    Chapter 16. Compile Time Checks
    Prev Part III.  Extensions - Next

    Chapter 16. Compile Time Checks

    +

    		 Next

    Chapter 16. Compile Time Checks

    Also known as concept checking.

    In 1999, SGI added concept checkers to their implementation of the STL: code which checked the template parameters of @@ -45,4 +37,4 @@ support for template parameter constraints based on concepts in the core language. This will obviate the need for the library-simulated concept checking described above. -

    Prev Up Next
     Home Chapter 17. Debug Mode
    +

    Prev Up Next
     Home Chapter 17. Debug Mode
    diff --git a/libstdc++-v3/doc/html/manual/ext_concurrency.html b/libstdc++-v3/doc/html/manual/ext_concurrency.html index 23e613f39a2..8a096fff36c 100644 --- a/libstdc++-v3/doc/html/manual/ext_concurrency.html +++ b/libstdc++-v3/doc/html/manual/ext_concurrency.html @@ -1,21 +1,9 @@ -Chapter 30. Concurrency
    Chapter 30. Concurrency
    Prev Part III.  + + +Chapter 30. Concurrency
    Chapter 30. Concurrency
    Prev Part III.  Extensions - Next

    Chapter 30. Concurrency

    Table of Contents

    Design
    Interface to Locks and Mutexes
    Interface to Atomic Functions
    Implementation
    Using Builtin Atomic Functions
    Thread Abstraction
    Use

    Design

    Interface to Locks and Mutexes

    The file <ext/concurrence.h> +

    		 Next

    Chapter 30. Concurrency

    Table of Contents

    Design
    Interface to Locks and Mutexes
    Interface to Atomic Functions
    Implementation
    Using Builtin Atomic Functions
    Thread Abstraction
    Use

    Design

    Interface to Locks and Mutexes

    The file <ext/concurrence.h> contains all the higher-level constructs for playing with threads. In contrast to the atomics layer, the concurrence layer consists largely of types. All types are defined within namespace __gnu_cxx. @@ -45,7 +33,7 @@ critical sections, while retaining exception-safety. These types have been superseded in the ISO C++ 2011 standard by the mutex and lock types defined in the header <mutex>. -

    Interface to Atomic Functions

    +

    Interface to Atomic Functions

    Two functions and one type form the base of atomic support.

    The type _Atomic_word is a signed integral type supporting atomic operations. @@ -103,4 +91,4 @@ _GLIBCXX_WRITE_MEM_BARRIER

    Which expand to the appropriate write and read barrier required by the host hardware and operating system. -

    Prev Up Next
    Chapter 29. Demangling Home Implementation
    +

    Prev Up Next
    Chapter 29. Demangling Home Implementation
    diff --git a/libstdc++-v3/doc/html/manual/ext_containers.html b/libstdc++-v3/doc/html/manual/ext_containers.html index 4ed98016bc8..6f236b7da20 100644 --- a/libstdc++-v3/doc/html/manual/ext_containers.html +++ b/libstdc++-v3/doc/html/manual/ext_containers.html @@ -1,17 +1,9 @@ -Chapter 23. HP/SGI Extensions
    Chapter 23. HP/SGI Extensions
    Prev Part III.  + + +Chapter 23. HP/SGI Extensions
    Chapter 23. HP/SGI Extensions
    Prev Part III.  Extensions - Next

    Chapter 23. HP/SGI Extensions

    Table of Contents

    Backwards Compatibility
    Deprecated

    Backwards Compatibility

    A few extensions and nods to backwards-compatibility have +

    		 Next

    Chapter 23. HP/SGI Extensions

    Table of Contents

    Backwards Compatibility
    Deprecated

    Backwards Compatibility

    A few extensions and nods to backwards-compatibility have been made with containers. Those dealing with older SGI-style allocators are dealt with elsewhere. The remaining ones all deal with bits: @@ -47,4 +39,4 @@ 

        size_t _Find_first() const;
    size_t _Find_next (size_t prev) const;

    The same caveat given for the _Unchecked_* functions applies here also. -

    Prev Up Next
    Acknowledgments Home Deprecated
    +

    Prev Up Next
    Acknowledgments Home Deprecated
    diff --git a/libstdc++-v3/doc/html/manual/ext_demangling.html b/libstdc++-v3/doc/html/manual/ext_demangling.html index a39c918fd03..79d9452c13e 100644 --- a/libstdc++-v3/doc/html/manual/ext_demangling.html +++ b/libstdc++-v3/doc/html/manual/ext_demangling.html @@ -1,17 +1,9 @@ -Chapter 29. Demangling
    Chapter 29. Demangling
    Prev Part III.  + + +Chapter 29. Demangling
    Chapter 29. Demangling
    Prev Part III.  Extensions - Next

    Chapter 29. Demangling

    +

    		 Next

    Chapter 29. Demangling

    Transforming C++ ABI identifiers (like RTTI symbols) into the original C++ source identifiers is called “demangling.” @@ -79,4 +71,4 @@ int main() be writing C++ in order to demangle C++. (That also means we have to use crummy memory management facilities, so don't forget to free() the returned char array.) -

    Prev Up Next
    Chapter 28. Input and Output Home Chapter 30. Concurrency
    +

    Prev Up Next
    Chapter 28. Input and Output Home Chapter 30. Concurrency
    diff --git a/libstdc++-v3/doc/html/manual/ext_io.html b/libstdc++-v3/doc/html/manual/ext_io.html index a1350e53c2d..664103f4b82 100644 --- a/libstdc++-v3/doc/html/manual/ext_io.html +++ b/libstdc++-v3/doc/html/manual/ext_io.html @@ -1,20 +1,12 @@ -Chapter 28. Input and Output
    Chapter 28. Input and Output
    Prev Part III.  + + +Chapter 28. Input and Output
    Chapter 28. Input and Output
    Prev Part III.  Extensions - Next

    Chapter 28. Input and Output

    Table of Contents

    Derived filebufs

    +

    		 Next

    Chapter 28. Input and Output

    Table of Contents

    Derived filebufs

    Extensions allowing filebufs to be constructed from "C" types like FILE*s and file descriptors. -

    Derived filebufs

    The v2 library included non-standard extensions to construct +

    Derived filebufs

    The v2 library included non-standard extensions to construct std::filebufs from C stdio types such as FILE*s and POSIX file descriptors. Today the recommended way to use stdio types with libstdc++ @@ -50,4 +42,4 @@ __gnu_cxx::stdio_filebuf. This class can be constructed from a C FILE* or a file descriptor, and provides the fd() function. -

    Prev Up Next
    Chapter 27. Iterators Home Chapter 29. Demangling
    +

    Prev Up Next
    Chapter 27. Iterators Home Chapter 29. Demangling
    diff --git a/libstdc++-v3/doc/html/manual/ext_iterators.html b/libstdc++-v3/doc/html/manual/ext_iterators.html index 491cfa93c1f..16893716971 100644 --- a/libstdc++-v3/doc/html/manual/ext_iterators.html +++ b/libstdc++-v3/doc/html/manual/ext_iterators.html @@ -1,17 +1,9 @@ -Chapter 27. Iterators
    Chapter 27. Iterators
    Prev Part III.  + + +Chapter 27. Iterators
    Chapter 27. Iterators
    Prev Part III.  Extensions - Next

    Chapter 27. Iterators

    24.3.2 describes struct iterator, which didn't exist in the +

    		 Next

    Chapter 27. Iterators

    24.3.2 describes struct iterator, which didn't exist in the original HP STL implementation (the language wasn't rich enough at the time). For backwards compatibility, base classes are provided which declare the same nested typedefs: @@ -19,4 +11,4 @@ two iterators and returns a result. It is extended by another signature which takes two iterators and a reference to a result. The result is modified, and the function returns nothing. -

    Prev Up Next
    Chapter 26. Numerics Home Chapter 28. Input and Output
    +

    Prev Up Next
    Chapter 26. Numerics Home Chapter 28. Input and Output
    diff --git a/libstdc++-v3/doc/html/manual/ext_numerics.html b/libstdc++-v3/doc/html/manual/ext_numerics.html index fea09d7bccc..f38ca1497c4 100644 --- a/libstdc++-v3/doc/html/manual/ext_numerics.html +++ b/libstdc++-v3/doc/html/manual/ext_numerics.html @@ -1,17 +1,9 @@ -Chapter 26. Numerics
    Chapter 26. Numerics
    Prev Part III.  + + +Chapter 26. Numerics
    Chapter 26. Numerics
    Prev Part III.  Extensions - Next

    Chapter 26. Numerics

    26.4, the generalized numeric operations such as accumulate, +

    		 Next

    Chapter 26. Numerics

    26.4, the generalized numeric operations such as accumulate, are extended with the following functions: 

        power (x, n);
@@ -29,4 +21,4 @@
    value + 1 to *(first + 1) and so on."
 
        void iota(_ForwardIter first, _ForwardIter last, _Tp value);
    The iota function is included in the ISO C++ 2011 standard.
-
    Prev Up Next
    Chapter 25. Algorithms Home Chapter 27. Iterators
    +

    Prev Up Next
    Chapter 25. Algorithms Home Chapter 27. Iterators
    diff --git a/libstdc++-v3/doc/html/manual/ext_utilities.html b/libstdc++-v3/doc/html/manual/ext_utilities.html index 316e4146eee..071ce4bcc20 100644 --- a/libstdc++-v3/doc/html/manual/ext_utilities.html +++ b/libstdc++-v3/doc/html/manual/ext_utilities.html @@ -1,17 +1,9 @@ -Chapter 24. Utilities
    Chapter 24. Utilities
    Prev Part III.  + + +Chapter 24. Utilities
    Chapter 24. Utilities
    Prev Part III.  Extensions - Next

    Chapter 24. Utilities

    +

    		 Next

    Chapter 24. Utilities

    The <functional> header contains many additional functors and helper functions, extending section 20.3. They are @@ -47,4 +39,4 @@ get_temporary_buffer(5, (int*)0);

    The specialized algorithms of section 20.4.4 are extended with uninitialized_copy_n. -

    Prev Up Next
    Deprecated Home Chapter 25. Algorithms
    +

    Prev Up Next
    Deprecated Home Chapter 25. Algorithms
    diff --git a/libstdc++-v3/doc/html/manual/extensions.html b/libstdc++-v3/doc/html/manual/extensions.html index c27deebf603..57358738ebd 100644 --- a/libstdc++-v3/doc/html/manual/extensions.html +++ b/libstdc++-v3/doc/html/manual/extensions.html @@ -1,20 +1,12 @@ -Part III.  Extensions
    Part III.  + + +Part III.  Extensions
    Part III.  Extensions -
    Prev The GNU C++ Library Manual Next

    Part III.  +

    Prev The GNU C++ Library Manual Next

    Part III.  Extensions - -

    Table of Contents

    16. Compile Time Checks
    17. Debug Mode
    Intro
    Semantics
    Using
    Using the Debug Mode
    Using a Specific Debug Container
    Design
    Goals
    Methods
    The Wrapper Model
    Safe Iterators
    Safe Sequences (Containers)
    Precondition Checking
    Release- and debug-mode coexistence
    Compile-time coexistence of release- and debug-mode components
    Link- and run-time coexistence of release- and + +

    Table of Contents

    16. Compile Time Checks
    17. Debug Mode
    Intro
    Semantics
    Using
    Using the Debug Mode
    Using a Specific Debug Container
    Design
    Goals
    Methods
    The Wrapper Model
    Safe Iterators
    Safe Sequences (Containers)
    Precondition Checking
    Release- and debug-mode coexistence
    Compile-time coexistence of release- and debug-mode components
    Link- and run-time coexistence of release- and debug-mode components
    Alternatives for Coexistence
    Other Implementations
    18. Parallel Mode
    Intro
    Semantics
    Using
    Prerequisite Compiler Flags
    Using Parallel Mode
    Using Specific Parallel Components
    Design
    Interface Basics
    Configuration and Tuning
    Setting up the OpenMP Environment
    Compile Time Switches
    Run Time Settings and Defaults
    Implementation Namespaces
    Testing
    Bibliography
    19. Profile Mode
    Intro
    Using the Profile Mode
    Tuning the Profile Mode
    Design
    Wrapper Model
    Instrumentation
    Run Time Behavior
    Analysis and Diagnostics
    Cost Model
    Reports
    Testing
    Extensions for Custom Containers
    Empirical Cost Model
    Implementation Issues
    Stack Traces
    Symbolization of Instruction Addresses
    Concurrency
    Using the Standard Library in the Instrumentation Implementation
    Malloc Hooks
    Construction and Destruction of Global Objects
    Developer Information
    Big Picture
    How To Add A Diagnostic
    Diagnostics
    Diagnostic Template
    Containers
    Hashtable Too Small
    Hashtable Too Large
    Inefficient Hash
    Vector Too Small
    Vector Too Large
    Vector to Hashtable
    Hashtable to Vector
    Vector to List
    List to Vector
    List to Forward List (Slist)
    Ordered to Unordered Associative Container
    Algorithms
    Sort Algorithm Performance
    Data Locality
    Need Software Prefetch
    Linked Structure Locality
    Multithreaded Data Access
    Data Dependence Violations at Container Level
    False Sharing
    Statistics
    Bibliography
    20. The mt_allocator
    Intro
    Design Issues
    Overview
    Implementation
    Tunable Parameters
    Initialization
    Deallocation Notes
    Single Thread Example
    Multiple Thread Example
    21. The bitmap_allocator
    Design
    Implementation
    Free List Store
    Super Block
    Super Block Data Layout
    Maximum Wasted Percentage
    allocate
    deallocate
    Questions
    1
    2
    3
    Locality
    Overhead and Grow Policy
    22. Policy-Based Data Structures
    Intro
    Performance Issues
    Associative
    Priority Que
    Goals
    Associative
    Policy Choices
    Underlying Data Structures
    Iterators
    Functional
    Priority Queues
    Policy Choices
    Underlying Data Structures
    Binary Heaps
    Using
    Prerequisites
    Organization
    Tutorial
    Basic Use
    Configuring via Template Parameters
    @@ -79,4 +71,4 @@ Text modify Down
    Observations
    Associative
    Priority_Queue
    Acknowledgments
    Bibliography -
    23. HP/SGI Extensions
    Backwards Compatibility
    Deprecated
    24. Utilities
    25. Algorithms
    26. Numerics
    27. Iterators
    28. Input and Output
    Derived filebufs
    29. Demangling
    30. Concurrency
    Design
    Interface to Locks and Mutexes
    Interface to Atomic Functions
    Implementation
    Using Builtin Atomic Functions
    Thread Abstraction
    Use
    Prev Up Next
    Interacting with C Home 
    +
    23. HP/SGI Extensions
    Backwards Compatibility
    Deprecated
    24. Utilities
    25. Algorithms
    26. Numerics
    27. Iterators
    28. Input and Output
    Derived filebufs
    29. Demangling
    30. Concurrency
    Design
    Interface to Locks and Mutexes
    Interface to Atomic Functions
    Implementation
    Using Builtin Atomic Functions
    Thread Abstraction
    Use
    Prev Up Next
    Interacting with C Home 
    diff --git a/libstdc++-v3/doc/html/manual/facets.html b/libstdc++-v3/doc/html/manual/facets.html index df74d456525..acf38fc4dcc 100644 --- a/libstdc++-v3/doc/html/manual/facets.html +++ b/libstdc++-v3/doc/html/manual/facets.html @@ -1,17 +1,9 @@ -Facets
    Facets
    Prev Chapter 8.  + + +Facets
    Facets
    Prev Chapter 8.  Localization - Next

    Facets

    ctype

    Implementation

    Specializations

    +

    		 Next

    Facets

    ctype

    Implementation

    Specializations

    For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the @@ -36,7 +28,7 @@ to wchar_t and wcsrtombs for conversions between wchar_t and char.

    Neither of these two required specializations deals with Unicode characters. -

    Future

    • +

    Future

    • How to deal with the global locale issue?

    • How to deal with different types than char, wchar_t?

    • @@ -58,30 +50,30 @@ characters.

    • Rename abstract base class. See if just smash-overriding is a better approach. Clarify, add sanity to naming. -

    Bibliography

    +

    Bibliography

    The GNU C Library - . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization.

    + . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization.

    Correspondence - . Ulrich Drepper. Copyright © 2002 .

    + . Ulrich Drepper. Copyright © 2002 .

    ISO/IEC 14882:1998 Programming languages - C++ - . Copyright © 1998 ISO.

    + . Copyright © 1998 ISO.

    ISO/IEC 9899:1999 Programming languages - C - . Copyright © 1999 ISO.

    + . Copyright © 1999 ISO.

    The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004) - . Copyright © 1999 - The Open Group/The Institute of Electrical and Electronics Engineers, Inc..

    + . Copyright © 1999 + The Open Group/The Institute of Electrical and Electronics Engineers, Inc..

    The C++ Programming Language, Special Edition . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. Addison Wesley - .

    + .

    Standard C++ IOStreams and Locales . Advanced Programmer's Guide and Reference . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. Addison Wesley Longman - .

    codecvt

    + .

    codecvt

    The standard class codecvt attempts to address conversions between different character encoding schemes. In particular, the standard attempts to detail conversions between the implementation-defined wide @@ -95,7 +87,7 @@ including Unicode and UTF8. Design issues and requirements are addressed, and examples of correct usage for both the required specializations for wide and narrow characters and the implementation-provided extended functionality are given. -

    Requirements

    +

    Requirements

    Around page 425 of the C++ Standard, this charming heading comes into view:

    22.2.1.5 - Template class codecvt @@ -141,7 +133,7 @@ third template parameter, stateT.

    Two: The required conversions, by specifying mbstate_t as the third template parameter, imply an implementation strategy that is mostly (or wholly) based on the underlying C library, and the functions -mcsrtombs and wcsrtombs in particular.

    Design

    wchar_t Size

    +mcsrtombs and wcsrtombs in particular.

    Design

    wchar_t Size

    The simple implementation detail of wchar_t's size seems to repeatedly confound people. Many systems use a two byte, unsigned integral type to represent wide characters, and use an @@ -153,7 +145,7 @@ mcsrtombs and wcsrtombs in particular.

    Support for Unicode

    +

    Support for Unicode

    Probably the most frequently asked question about code conversion is: "So dudes, what's the deal with Unicode strings?" The dude part is optional, but apparently the usefulness of @@ -221,7 +213,7 @@ mechanism may be required. Some way to enforce strict type checking on the internal and external types. As part of this, the size of the internal and external types will need to be known. -

    Other Issues

    +

    Other Issues

    In addition, multi-threaded and multi-locale environments also impact the design and requirements for code conversions. In particular, they affect the required specialization codecvt<wchar_t, char, mbstate_t> @@ -253,7 +245,7 @@ For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the LC_CTYPE category implements. -

    Implementation

    +

    Implementation

    The two required specializations are implemented as follows:

    @@ -355,7 +347,7 @@ Definitions for all the required codecvt member functions are provided for this specialization, and usage of codecvt<internal character type, external character type, encoding_state> is consistent with other codecvt usage. -

    Use

    A conversions involving string literal.

    +

    Use

    A conversions involving string literal.

       typedef codecvt_base::result                  result;
   typedef unsigned short                        unicode_t;
   typedef unicode_t                             int_type;
@@ -392,7 +384,7 @@ codecvt usage.
   VERIFY( !int_traits::compare(i_arr, i_lit, size) );
   VERIFY( efrom_next == e_lit + size );
   VERIFY( ito_next == i_arr + size );
-

    Future

    • +

    Future

    • a. things that are sketchy, or remain unimplemented: do_encoding, max_length and length member functions are only weakly implemented. I have no idea how to do @@ -418,50 +410,50 @@ codecvt usage.

    • wchar_t/char internal buffers and conversions between internal/external buffers? -

    Bibliography

    +

    Bibliography

    The GNU C Library . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization - .

    + .

    Correspondence - . Ulrich Drepper. Copyright © 2002 .

    + . Ulrich Drepper. Copyright © 2002 .

    ISO/IEC 14882:1998 Programming languages - C++ - . Copyright © 1998 ISO.

    + . Copyright © 1998 ISO.

    ISO/IEC 9899:1999 Programming languages - C - . Copyright © 1999 ISO.

    + . Copyright © 1999 ISO.

    System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008) - . Copyright © 2008 + . Copyright © 2008 The Open Group/The Institute of Electrical and Electronics Engineers, Inc. - .

    + .

    The C++ Programming Language, Special Edition . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. Addison Wesley - .

    + .

    Standard C++ IOStreams and Locales . Advanced Programmer's Guide and Reference . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. Addison Wesley Longman - .

    + .

    A brief description of Normative Addendum 1 - . Clive Feather. Extended Character Sets.

    + . Clive Feather. Extended Character Sets.

    The Unicode HOWTO - . Bruno Haible.

    + . Bruno Haible.

    UTF-8 and Unicode FAQ for Unix/Linux - . Markus Khun.

    messages

    + . Markus Khun.

    messages

    The std::messages facet implements message retrieval functionality equivalent to Java's java.text.MessageFormat .using either GNU gettext or IEEE 1003.1-200 functions. -

    Requirements

    +

    Requirements

    The std::messages facet is probably the most vaguely defined facet in the standard library. It's assumed that this facility was built into the standard library in order to convert string literals from one @@ -510,7 +502,7 @@ be found, returns dfault. -6- Effects: Releases unspecified resources associated with cat. -7- Notes: The limit on such resources, if any, is implementation-defined. -

    Design

    +

    Design

    A couple of notes on the standard.

    First, why is messages_base::catalog specified as a typedef @@ -543,7 +535,7 @@ It is implicitly assumed that the locale for the default message string in 'get' is in the "C" locale. Thus, all source code is assumed to be written in English, so translations are always from "en_US" to other, explicitly named locales. -

    Implementation

    Models

    +

    Implementation

    Models

    This is a relatively simple class, on the face of it. The standard specifies very little in concrete terms, so generic implementations that are conforming yet do very little are the @@ -584,7 +576,7 @@ A new, standards-conformant non-virtual member function signature was added for 'open' so that a directory could be specified with a given message catalog. This simplifies calling conventions for the gnu model. -

    The GNU Model

    +

    The GNU Model

    The messages facet, because it is retrieving and converting between characters sets, depends on the ctype and perhaps the codecvt facet in a given locale. In addition, underlying "C" @@ -627,7 +619,7 @@ model. use_facet<messages<char> >(loc_de).open("libstdc++", locale(), dir); -

    Use

    +

    Use

    A simple example using the GNU model of message conversion. 

     #include <iostream>
@@ -649,7 +641,7 @@ void test01()
   cout << "thank you in german:" << s02 << '\n';
   mssg_de.close(cat_de);
 }
-

    Future

    • +

    Future

    • Things that are sketchy, or remain unimplemented:

      • _M_convert_from_char, _M_convert_to_char are in flux, @@ -699,44 +691,44 @@ void test01() model. As of this writing, it is unknown how to query to see if a specified message catalog exists using the gettext package. -

    Bibliography

    +

    Bibliography

    The GNU C Library . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling, and 7 Locales and Internationalization - .

    + .

    Correspondence - . Ulrich Drepper. Copyright © 2002 .

    + . Ulrich Drepper. Copyright © 2002 .

    ISO/IEC 14882:1998 Programming languages - C++ - . Copyright © 1998 ISO.

    + . Copyright © 1998 ISO.

    ISO/IEC 9899:1999 Programming languages - C - . Copyright © 1999 ISO.

    + . Copyright © 1999 ISO.

    System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008) - . Copyright © 2008 + . Copyright © 2008 The Open Group/The Institute of Electrical and Electronics Engineers, Inc. - .

    + .

    The C++ Programming Language, Special Edition . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. Addison Wesley - .

    + .

    Standard C++ IOStreams and Locales . Advanced Programmer's Guide and Reference . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. Addison Wesley Longman - .

    + .

    API Specifications, Java Platform - . java.util.Properties, java.text.MessageFormat, + . java.util.Properties, java.text.MessageFormat, java.util.Locale, java.util.ResourceBundle - .

    + .

    GNU gettext tools, version 0.10.38, Native Language Support Library and Tools. - .

    Prev Up Next
    Chapter 8.  + .

    Prev Up Next
    Chapter 8.  Localization  Home Chapter 9.  diff --git a/libstdc++-v3/doc/html/manual/fstreams.html b/libstdc++-v3/doc/html/manual/fstreams.html index 0e67c62dc58..b68e366356c 100644 --- a/libstdc++-v3/doc/html/manual/fstreams.html +++ b/libstdc++-v3/doc/html/manual/fstreams.html @@ -1,17 +1,9 @@ -File Based Streams
    File Based Streams
    Prev Chapter 13.  + + +File Based Streams
    File Based Streams
    Prev Chapter 13.  Input and Output - Next

    File Based Streams

    Copying a File

    +

    		 Next

    File Based Streams

    Copying a File

    So you want to copy a file quickly and easily, and most important, completely portably. And since this is C++, you have an open ifstream (call it IN) and an open ofstream (call it OUT): @@ -57,7 +49,7 @@ The operators shown above are all defined in the parent basic_ostream class and are therefore available with all possible descendants. -

    Binary Input and Output

    +

    Binary Input and Output

    The first and most important thing to remember about binary I/O is that opening a file with ios::binary is not, repeat not, the only thing you have to do. It is not a silver @@ -155,4 +147,4 @@ between arbitrary programs, or across a network, or from one invocation of a program to another invocation of the same program on a different platform, etc. -

    Prev Up Next
    Memory Based Streams Home Interacting with C
    +

    Prev Up Next
    Memory Based Streams Home Interacting with C
    diff --git a/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html b/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html index 0c4a2d30fdb..2bb9a0b6783 100644 --- a/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html +++ b/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html @@ -1,17 +1,9 @@ -Generalized Operations
    Generalized Operations
    Prev Chapter 12.  + + +Generalized Operations
    Generalized Operations
    Prev Chapter 12.  Numerics - Next

    Generalized Operations

    +

    		 Next

    Generalized Operations

    There are four generalized functions in the <numeric> header that follow the same conventions as those in <algorithm>. Each of them is overloaded: one signature for common default operations, @@ -34,7 +26,7 @@ and multiplies all the members of the array; here we must obviously use 1 as a starting value instead of 0.

    The other three functions have similar dual-signature forms. -

    Prev Up Next
    Chapter 12.  +

    Prev Up Next
    Chapter 12.  Numerics  Home Interacting with C
    diff --git a/libstdc++-v3/doc/html/manual/index.html b/libstdc++-v3/doc/html/manual/index.html index 0fad7857818..c181dde7302 100644 --- a/libstdc++-v3/doc/html/manual/index.html +++ b/libstdc++-v3/doc/html/manual/index.html @@ -1,12 +1,8 @@ -The GNU C++ Library Manual
    The GNU C++ Library Manual
    Prev   Next

    The GNU C++ Library Manual

    Paolo Carlini

    Phil Edwards

    Doug Gregor

    Benjamin Kosnik

    Dhruv Matani

    Jason Merrill

    Mark Mitchell

    Nathan Myers

    Felix Natter

    Stefan Olsson

    Silvius Rus

    Johannes Singler

    Ami Tavory

    Jonathan Wakely

    Copyright © 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 + + +The GNU C++ Library Manual

    The GNU C++ Library Manual
    Prev   Next

    The GNU C++ Library Manual

    Paolo Carlini

    Phil Edwards

    Doug Gregor

    Benjamin Kosnik

    Dhruv Matani

    Jason Merrill

    Mark Mitchell

    Nathan Myers

    Felix Natter

    Stefan Olsson

    Silvius Rus

    Johannes Singler

    Ami Tavory

    Jonathan Wakely

    Copyright © 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 FSF -

    Table of Contents

    I. +

    Table of Contents

    I. Introduction
    1. Status
    Implementation Status
    C++ 1998/2003
    Implementation Status
    Implementation Specific Behavior
    C++ 2011
    Implementation Specific Behavior
    C++ TR1
    Implementation Specific Behavior
    C++ TR 24733
    License
    The Code: GPL
    The Documentation: GPL, FDL
    Bugs
    Implementation Bugs
    Standard Bugs
    2. Setup
    Prerequisites
    Configure
    Make
    3. Using
    Command Options
    Headers
    Header Files
    Mixing Headers
    The C Headers and namespace std
    Precompiled Headers
    Macros
    Namespaces
    Available Namespaces
    namespace std
    Using Namespace Composition
    Linking
    Almost Nothing
    Finding Dynamic or Shared Libraries
    Concurrency
    Prerequisites
    Thread Safety
    Atomics
    IO
    Structure
    Defaults
    Future
    Alternatives
    Containers
    Exceptions
    Exception Safety
    Exception Neutrality
    Doing without
    Compatibility
    With C
    With POSIX thread cancellation
    Debugging Support
    Using g++
    Debug Versions of Library Binary Files
    Memory Leak Hunting
    Data Race Hunting
    Using gdb
    Tracking uncaught exceptions
    Debug Mode
    Compile Time Checking
    Profile-based Performance Analysis
    II. @@ -20,13 +16,13 @@
    Exceptions
    API Reference
    Adding Data to exception
    Concept Checking
    6. Utilities -
    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits
    7. +
    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits
    7. Strings
    String Classes
    Simple Transformations
    Case Sensitivity
    Arbitrary Character Types
    Tokenizing
    Shrink to Fit
    CString (MFC)
    8. Localization -
    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future
    9. +
    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future
    9. Containers
    Sequences
    list
    list::size() is O(n)
    vector
    Space Overhead Management
    Associative
    Insertion Hints
    bitset
    Size Variable
    Type String
    Interacting with C
    Containers vs. Arrays
    10. @@ -150,21 +146,21 @@ Support for C++11 dialect.
    D. GNU General Public License version 3 -
    E. GNU Free Documentation License

    List of Figures

    22.1. Node Invariants
    22.2. Underlying Associative Data Structures
    22.3. Range Iteration in Different Data Structures
    22.4. Point Iteration in Hash Data Structures
    22.5. Effect of erase in different underlying data structures
    22.6. Underlying Priority Queue Data Structures
    22.7. Exception Hierarchy
    22.8. Non-unique Mapping Standard Containers
    22.9. +
    E. GNU Free Documentation License

    List of Figures

    22.1. Node Invariants
    22.2. Underlying Associative Data Structures
    22.3. Range Iteration in Different Data Structures
    22.4. Point Iteration in Hash Data Structures
    22.5. Effect of erase in different underlying data structures
    22.6. Underlying Priority Queue Data Structures
    22.7. Exception Hierarchy
    22.8. Non-unique Mapping Standard Containers
    22.9. Effect of embedded lists in std::multimap -
    22.10. Non-unique Mapping Containers
    22.11. Point Iterator Hierarchy
    22.12. Invalidation Guarantee Tags Hierarchy
    22.13. Container Tag Hierarchy
    22.14. Hash functions, ranged-hash functions, and - range-hashing functions
    22.15. Insert hash sequence diagram
    22.16. Insert hash sequence diagram with a null policy
    22.17. Hash policy class diagram
    22.18. Balls and bins
    22.19. Insert resize sequence diagram
    22.20. Standard resize policy trigger sequence - diagram
    22.21. Standard resize policy size sequence - diagram
    22.22. Tree node invariants
    22.23. Tree node invalidation
    22.24. A tree and its update policy
    22.25. Restoring node invariants
    22.26. Insert update sequence
    22.27. Useless update path
    22.28. A PATRICIA trie
    22.29. A trie and its update policy
    22.30. A simple list
    22.31. The counter algorithm
    22.32. Underlying Priority-Queue Data-Structures.
    22.33. Priority-Queue Data-Structure Tags.
    B.1. Configure and Build File Dependencies

    List of Tables

    1.1. C++ 1998/2003 Implementation Status
    1.2. C++ 2011 Implementation Status
    1.3. C++ TR1 Implementation Status
    1.4. C++ TR 24733 Implementation Status
    3.1. C++ Command Options
    3.2. C++ 1998 Library Headers
    3.3. C++ 1998 Library Headers for C Library Facilities
    3.4. C++ 2011 Library Headers
    3.5. C++ 2011 Library Headers for C Library Facilities
    3.6. C++ TR 1 Library Headers
    3.7. C++ TR 1 Library Headers for C Library Facilities
    3.8. C++ TR 24733 Decimal Floating-Point Header
    3.9. C++ ABI Headers
    3.10. Extension Headers
    3.11. Extension Debug Headers
    3.12. Extension Profile Headers
    3.13. Extension Parallel Headers
    17.1. Debugging Containers
    17.2. Debugging Containers C++11
    18.1. Parallel Algorithms
    19.1. Profile Code Location
    19.2. Profile Diagnostics
    21.1. Bitmap Allocator Memory Map
    B.1. Doxygen Prerequisites
    B.2. HTML to Doxygen Markup Comparison
    B.3. Docbook Prerequisites
    B.4. HTML to Docbook XML Markup Comparison
    B.5. Docbook XML Element Use
    B.6. Extension Allocators
    B.7. Extension Allocators Continued

    List of Equations

    22.1. Ranged Hash Function
    22.2. Range-Hashing, Division Method
    22.3. Division via Prime Modulo
    22.4. Division via Bit Mask
    22.5. +
    22.10. Non-unique Mapping Containers
    22.11. Point Iterator Hierarchy
    22.12. Invalidation Guarantee Tags Hierarchy
    22.13. Container Tag Hierarchy
    22.14. Hash functions, ranged-hash functions, and + range-hashing functions
    22.15. Insert hash sequence diagram
    22.16. Insert hash sequence diagram with a null policy
    22.17. Hash policy class diagram
    22.18. Balls and bins
    22.19. Insert resize sequence diagram
    22.20. Standard resize policy trigger sequence + diagram
    22.21. Standard resize policy size sequence + diagram
    22.22. Tree node invariants
    22.23. Tree node invalidation
    22.24. A tree and its update policy
    22.25. Restoring node invariants
    22.26. Insert update sequence
    22.27. Useless update path
    22.28. A PATRICIA trie
    22.29. A trie and its update policy
    22.30. A simple list
    22.31. The counter algorithm
    22.32. Underlying Priority-Queue Data-Structures.
    22.33. Priority-Queue Data-Structure Tags.
    B.1. Configure and Build File Dependencies

    List of Tables

    1.1. C++ 1998/2003 Implementation Status
    1.2. C++ 2011 Implementation Status
    1.3. C++ TR1 Implementation Status
    1.4. C++ TR 24733 Implementation Status
    3.1. C++ Command Options
    3.2. C++ 1998 Library Headers
    3.3. C++ 1998 Library Headers for C Library Facilities
    3.4. C++ 2011 Library Headers
    3.5. C++ 2011 Library Headers for C Library Facilities
    3.6. C++ TR 1 Library Headers
    3.7. C++ TR 1 Library Headers for C Library Facilities
    3.8. C++ TR 24733 Decimal Floating-Point Header
    3.9. C++ ABI Headers
    3.10. Extension Headers
    3.11. Extension Debug Headers
    3.12. Extension Profile Headers
    3.13. Extension Parallel Headers
    17.1. Debugging Containers
    17.2. Debugging Containers C++11
    18.1. Parallel Algorithms
    19.1. Profile Code Location
    19.2. Profile Diagnostics
    21.1. Bitmap Allocator Memory Map
    B.1. Doxygen Prerequisites
    B.2. HTML to Doxygen Markup Comparison
    B.3. Docbook Prerequisites
    B.4. HTML to Docbook XML Markup Comparison
    B.5. Docbook XML Element Use
    B.6. Extension Allocators
    B.7. Extension Allocators Continued

    List of Equations

    22.1. Ranged Hash Function
    22.2. Range-Hashing, Division Method
    22.3. Division via Prime Modulo
    22.4. Division via Bit Mask
    22.5. A Standard String Hash Function -
    22.6. +
    22.6. Only k String DNA Hash -
    22.7. +
    22.7. Probability of Probe Sequence of Length k -
    22.8. +
    22.8. Probability Probe Sequence in Some Bin -
    Prev   Next
    The GNU C++ Library Home Part I.  +
    Prev   Next
    The GNU C++ Library Home Part I.  Introduction
    diff --git a/libstdc++-v3/doc/html/manual/internals.html b/libstdc++-v3/doc/html/manual/internals.html index 8f8b39bf9f0..8d3c02add25 100644 --- a/libstdc++-v3/doc/html/manual/internals.html +++ b/libstdc++-v3/doc/html/manual/internals.html @@ -1,21 +1,9 @@ -Porting to New Hardware or Operating Systems
    Porting to New Hardware or Operating Systems
    Prev Appendix B.  + + +Porting to New Hardware or Operating Systems
    Porting to New Hardware or Operating Systems
    Prev Appendix B.  Porting and Maintenance - Next

    Porting to New Hardware or Operating Systems

    +

    		 Next

    Porting to New Hardware or Operating Systems

    This document explains how to port libstdc++ (the GNU C++ library) to a new target.

    In order to make the GNU C++ library (libstdc++) work with a new @@ -32,7 +20,7 @@ works. It is difficult to test the C++ compiler without a working library, but you should at least try some minimal test cases.

    (Note that what we think of as a "target," the library refers to as a "host." The comment at the top of configure.ac explains why.) -

    Operating System

    If you are porting to a new operating system (as opposed to a new chip +

    Operating System

    If you are porting to a new operating system (as opposed to a new chip using an existing operating system), you will need to create a new directory in the config/os hierarchy. For example, the IRIX configuration files are all in config/os/irix. There is no set @@ -111,7 +99,7 @@ this: #endif

    We recommend copying an existing os_defines.h to use as a starting point. -

    CPU

    If you are porting to a new chip (as opposed to a new operating system +

    CPU

    If you are porting to a new chip (as opposed to a new operating system running on an existing chip), you will need to create a new directory in the config/cpu hierarchy. Much like the Operating system setup, there are no strict rules on how to organize the CPU configuration @@ -129,7 +117,7 @@ example, alpha, alphaev5, an

    The cpu_include_dir sets default locations for the files controlling Thread safety and Numeric limits, if the defaults are not appropriate for your chip. -

    Character Types

    The library requires that you provide three header files to implement +

    Character Types

    The library requires that you provide three header files to implement character classification, analogous to that provided by the C libraries <ctype.h> header. You can model these on the files provided in config/os/generic. However, these files will almost @@ -288,7 +276,7 @@ from __low up until __high i ++__low; return __low; } -

    Thread Safety

    The C++ library string functionality requires a couple of atomic +

    Thread Safety

    The C++ library string functionality requires a couple of atomic operations to provide thread-safety. If you don't take any special action, the library will use stub versions of these functions that are not thread-safe. They will work fine, unless your applications are @@ -343,7 +331,7 @@ must be equivalent to those provided here, but using atomic operations: { *__mem += __val; } -

    Numeric Limits

    The C++ library requires information about the fundamental data types, +

    Numeric Limits

    The C++ library requires information about the fundamental data types, such as the minimum and maximum representable values of each type. You can define each of these values individually, but it is usually easiest just to indicate how many bits are used in each of the data @@ -355,7 +343,7 @@ same values, you can provide a CPU-specific file instead so that you do not have to provide the same definitions for each operating system. To take that approach, create a new file called cpu_limits.h in your CPU configuration directory (see CPU). -

    Libtool

    The C++ library is compiled, archived and linked with libtool. +

    Libtool

    The C++ library is compiled, archived and linked with libtool. Explaining the full workings of libtool is beyond the scope of this document, but there are a few, particular bits that are necessary for porting. @@ -377,4 +365,4 @@ do this is to build the library using gcc -shared. ltcf-c.sh in the top-level directory. Find the switch statement that sets archive_cmds. Here, adjust the setting for your operating system. -

    Prev Up Next
    Writing and Generating Documentation Home Test
    +

    Prev Up Next
    Writing and Generating Documentation Home Test
    diff --git a/libstdc++-v3/doc/html/manual/intro.html b/libstdc++-v3/doc/html/manual/intro.html index 2bfe1917a8d..9951bb47a17 100644 --- a/libstdc++-v3/doc/html/manual/intro.html +++ b/libstdc++-v3/doc/html/manual/intro.html @@ -1,17 +1,9 @@ -Part I.  Introduction
    Part I.  + + +Part I.  Introduction
    Part I.  Introduction -
    Prev The GNU C++ Library Manual Next

    Part I.  +

    Prev The GNU C++ Library Manual Next

    Part I.  Introduction - -

    Table of Contents

    1. Status
    Implementation Status
    C++ 1998/2003
    Implementation Status
    Implementation Specific Behavior
    C++ 2011
    Implementation Specific Behavior
    C++ TR1
    Implementation Specific Behavior
    C++ TR 24733
    License
    The Code: GPL
    The Documentation: GPL, FDL
    Bugs
    Implementation Bugs
    Standard Bugs
    2. Setup
    Prerequisites
    Configure
    Make
    3. Using
    Command Options
    Headers
    Header Files
    Mixing Headers
    The C Headers and namespace std
    Precompiled Headers
    Macros
    Namespaces
    Available Namespaces
    namespace std
    Using Namespace Composition
    Linking
    Almost Nothing
    Finding Dynamic or Shared Libraries
    Concurrency
    Prerequisites
    Thread Safety
    Atomics
    IO
    Structure
    Defaults
    Future
    Alternatives
    Containers
    Exceptions
    Exception Safety
    Exception Neutrality
    Doing without
    Compatibility
    With C
    With POSIX thread cancellation
    Debugging Support
    Using g++
    Debug Versions of Library Binary Files
    Memory Leak Hunting
    Data Race Hunting
    Using gdb
    Tracking uncaught exceptions
    Debug Mode
    Compile Time Checking
    Profile-based Performance Analysis
    Prev Up Next
    The GNU C++ Library Manual Home Chapter 1. Status
    + +

    Table of Contents

    1. Status
    Implementation Status
    C++ 1998/2003
    Implementation Status
    Implementation Specific Behavior
    C++ 2011
    Implementation Specific Behavior
    C++ TR1
    Implementation Specific Behavior
    C++ TR 24733
    License
    The Code: GPL
    The Documentation: GPL, FDL
    Bugs
    Implementation Bugs
    Standard Bugs
    2. Setup
    Prerequisites
    Configure
    Make
    3. Using
    Command Options
    Headers
    Header Files
    Mixing Headers
    The C Headers and namespace std
    Precompiled Headers
    Macros
    Namespaces
    Available Namespaces
    namespace std
    Using Namespace Composition
    Linking
    Almost Nothing
    Finding Dynamic or Shared Libraries
    Concurrency
    Prerequisites
    Thread Safety
    Atomics
    IO
    Structure
    Defaults
    Future
    Alternatives
    Containers
    Exceptions
    Exception Safety
    Exception Neutrality
    Doing without
    Compatibility
    With C
    With POSIX thread cancellation
    Debugging Support
    Using g++
    Debug Versions of Library Binary Files
    Memory Leak Hunting
    Data Race Hunting
    Using gdb
    Tracking uncaught exceptions
    Debug Mode
    Compile Time Checking
    Profile-based Performance Analysis
    Prev Up Next
    The GNU C++ Library Manual Home Chapter 1. Status
    diff --git a/libstdc++-v3/doc/html/manual/io.html b/libstdc++-v3/doc/html/manual/io.html index a0296abe85a..f12a80077ae 100644 --- a/libstdc++-v3/doc/html/manual/io.html +++ b/libstdc++-v3/doc/html/manual/io.html @@ -1,22 +1,14 @@ -Chapter 13.  Input and Output
    Chapter 13.  + + +Chapter 13.  Input and Output
    Chapter 13.  Input and Output
    Prev Part II.  Standard Contents -  Next

    Chapter 13.  +

    		 Next

    Chapter 13.  Input and Output - -

    Table of Contents

    Iostream Objects
    Stream Buffers
    Derived streambuf Classes
    Buffering
    Memory Based Streams
    Compatibility With strstream
    File Based Streams
    Copying a File
    Binary Input and Output
    Interacting with C
    Using FILE* and file descriptors
    Performance

    Iostream Objects

    To minimize the time you have to wait on the compiler, it's good to + +

    Table of Contents

    Iostream Objects
    Stream Buffers
    Derived streambuf Classes
    Buffering
    Memory Based Streams
    Compatibility With strstream
    File Based Streams
    Copying a File
    Binary Input and Output
    Interacting with C
    Using FILE* and file descriptors
    Performance

    Iostream Objects

    To minimize the time you have to wait on the compiler, it's good to only include the headers you really need. Many people simply include <iostream> when they don't need to -- and that can penalize your runtime as well. Here are some tips on which header to use @@ -126,4 +118,4 @@ the standard objects in that source file; you'll pay less startup time. Only include the header files you need to in general; your compile times will go down when there's less parsing work to do. -

    Prev Up Next
    Interacting with C Home Stream Buffers
    +

    Prev Up Next
    Interacting with C Home Stream Buffers
    diff --git a/libstdc++-v3/doc/html/manual/io_and_c.html b/libstdc++-v3/doc/html/manual/io_and_c.html index 198db3d2bf2..155a2f6a0cc 100644 --- a/libstdc++-v3/doc/html/manual/io_and_c.html +++ b/libstdc++-v3/doc/html/manual/io_and_c.html @@ -1,22 +1,14 @@ -Interacting with C
    Interacting with C
    Prev Chapter 13.  + + +Interacting with C
    Interacting with C
    Prev Chapter 13.  Input and Output - Next

    Interacting with C

    Using FILE* and file descriptors

    +

    		 Next

    Interacting with C

    Using FILE* and file descriptors

    See the extensions for using FILE and file descriptors with ofstream and ifstream. -

    Performance

    +

    Performance

    Pathetic Performance? Ditch C.

    It sounds like a flame on C, but it isn't. Really. Calm down. I'm just saying it to get your attention. @@ -59,7 +51,7 @@ clog, and their wide-character counterchapters). File stream objects that you declare yourself have no such requirement and are fully buffered. -

    Prev Up Next
    File Based Streams Home Chapter 14.  +

    Prev Up Next
    File Based Streams Home Chapter 14.  Atomics
    diff --git a/libstdc++-v3/doc/html/manual/iterators.html b/libstdc++-v3/doc/html/manual/iterators.html index d2e1d8e481c..dcd9a92ead8 100644 --- a/libstdc++-v3/doc/html/manual/iterators.html +++ b/libstdc++-v3/doc/html/manual/iterators.html @@ -1,22 +1,14 @@ -Chapter 10.  Iterators
    Chapter 10.  + + +Chapter 10.  Iterators
    Chapter 10.  Iterators
    Prev Part II.  Standard Contents -  Next

    Chapter 10.  +

    		 Next

    Chapter 10.  Iterators - -

    Table of Contents

    Predefined
    Iterators vs. Pointers
    One Past the End

    Predefined

    Iterators vs. Pointers

    + +

    Table of Contents

    Predefined
    Iterators vs. Pointers
    One Past the End

    Predefined

    Iterators vs. Pointers

    The following FAQ entry points out that iterators are not implemented as pointers. They are a generalization @@ -52,7 +44,7 @@ classes. down through inheritance, so while the compiler has to do work looking up all the names, your runtime code does not. (This has been a prime concern from the beginning.) -

    One Past the End

    This starts off sounding complicated, but is actually very easy, +

    One Past the End

    This starts off sounding complicated, but is actually very easy, especially towards the end. Trust me.

    Beginners usually have a little trouble understand the whole 'past-the-end' thing, until they remember their early algebra classes @@ -132,7 +124,7 @@ classes. sequences very simple to recognize: if the two endpoints compare equal, then the {array, sequence, container, whatever} is empty.

    Just don't dereference end(). -

    Prev Up Next
    Interacting with C Home Chapter 11.  +

    Prev Up Next
    Interacting with C Home Chapter 11.  Algorithms
    diff --git a/libstdc++-v3/doc/html/manual/license.html b/libstdc++-v3/doc/html/manual/license.html index 2c9a184b900..a87ae4da415 100644 --- a/libstdc++-v3/doc/html/manual/license.html +++ b/libstdc++-v3/doc/html/manual/license.html @@ -1,101 +1,93 @@ -License
    License
    Prev Chapter 1. Status Next

    License

    + + +License

    License
    Prev Chapter 1. Status Next

    License

    There are two licenses affecting GNU libstdc++: one for the code, and one for the documentation.

    There is a license section in the FAQ regarding common questions. If you have more questions, ask the FSF or the gcc mailing list. -

    The Code: GPL

    +

    The Code: GPL

    The source code is distributed under the GNU General Public License version 3, with the addition under section 7 of an exception described in the “GCC Runtime Library Exception, version 3.1” as follows (or see the file COPYING.RUNTIME): -


    -GCC RUNTIME LIBRARY EXCEPTION
    -
    -Version 3.1, 31 March 2009
    -
    -Copyright (C) 2009 Free Software Foundation, Inc.
    -
    -Everyone is permitted to copy and distribute verbatim copies of this
    -license document, but changing it is not allowed.
    -
    -This GCC Runtime Library Exception ("Exception") is an additional
    -permission under section 7 of the GNU General Public License, version
    -3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
    -bears a notice placed by the copyright holder of the file stating that
    -the file is governed by GPLv3 along with this Exception.
    -
    -When you use GCC to compile a program, GCC may combine portions of
    -certain GCC header files and runtime libraries with the compiled
    -program. The purpose of this Exception is to allow compilation of
    -non-GPL (including proprietary) programs to use, in this way, the
    -header files and runtime libraries covered by this Exception.
    -
    -0. Definitions.
    -
    -A file is an "Independent Module" if it either requires the Runtime
    -Library for execution after a Compilation Process, or makes use of an
    -interface provided by the Runtime Library, but is not otherwise based
    -on the Runtime Library.
    -
    -"GCC" means a version of the GNU Compiler Collection, with or without
    -modifications, governed by version 3 (or a specified later version) of
    -the GNU General Public License (GPL) with the option of using any
    -subsequent versions published by the FSF.
    -
    -"GPL-compatible Software" is software whose conditions of propagation,
    -modification and use would permit combination with GCC in accord with
    -the license of GCC.
    -
    -"Target Code" refers to output from any compiler for a real or virtual
    -target processor architecture, in executable form or suitable for
    -input to an assembler, loader, linker and/or execution
    -phase. Notwithstanding that, Target Code does not include data in any
    -format that is used as a compiler intermediate representation, or used
    -for producing a compiler intermediate representation.
    -
    -The "Compilation Process" transforms code entirely represented in
    -non-intermediate languages designed for human-written code, and/or in
    -Java Virtual Machine byte code, into Target Code. Thus, for example,
    -use of source code generators and preprocessors need not be considered
    -part of the Compilation Process, since the Compilation Process can be
    -understood as starting with the output of the generators or
    -preprocessors.
    -
    -A Compilation Process is "Eligible" if it is done using GCC, alone or
    -with other GPL-compatible software, or if it is done without using any
    -work based on GCC. For example, using non-GPL-compatible Software to
    -optimize any GCC intermediate representations would not qualify as an
    -Eligible Compilation Process.
    -
    -1. Grant of Additional Permission.
    -
    -You have permission to propagate a work of Target Code formed by
    -combining the Runtime Library with Independent Modules, even if such
    -propagation would otherwise violate the terms of GPLv3, provided that
    -all Target Code was generated by Eligible Compilation Processes. You
    -may then convey such a combination under terms of your choice,
    -consistent with the licensing of the Independent Modules.
    -
    -2. No Weakening of GCC Copyleft.
    -
    -The availability of this Exception does not imply any general
    -presumption that third-party software is unaffected by the copyleft
    -requirements of the license of GCC.
    +


    +GCC RUNTIME LIBRARY EXCEPTION
    +
    +Version 3.1, 31 March 2009
    +
    +Copyright (C) 2009 Free Software Foundation, Inc.
    +
    +Everyone is permitted to copy and distribute verbatim copies of this
    +license document, but changing it is not allowed.
    +
    +This GCC Runtime Library Exception ("Exception") is an additional
    +permission under section 7 of the GNU General Public License, version
    +3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
    +bears a notice placed by the copyright holder of the file stating that
    +the file is governed by GPLv3 along with this Exception.
    +
    +When you use GCC to compile a program, GCC may combine portions of
    +certain GCC header files and runtime libraries with the compiled
    +program. The purpose of this Exception is to allow compilation of
    +non-GPL (including proprietary) programs to use, in this way, the
    +header files and runtime libraries covered by this Exception.
    +
    +0. Definitions.
    +
    +A file is an "Independent Module" if it either requires the Runtime
    +Library for execution after a Compilation Process, or makes use of an
    +interface provided by the Runtime Library, but is not otherwise based
    +on the Runtime Library.
    +
    +"GCC" means a version of the GNU Compiler Collection, with or without
    +modifications, governed by version 3 (or a specified later version) of
    +the GNU General Public License (GPL) with the option of using any
    +subsequent versions published by the FSF.
    +
    +"GPL-compatible Software" is software whose conditions of propagation,
    +modification and use would permit combination with GCC in accord with
    +the license of GCC.
    +
    +"Target Code" refers to output from any compiler for a real or virtual
    +target processor architecture, in executable form or suitable for
    +input to an assembler, loader, linker and/or execution
    +phase. Notwithstanding that, Target Code does not include data in any
    +format that is used as a compiler intermediate representation, or used
    +for producing a compiler intermediate representation.
    +
    +The "Compilation Process" transforms code entirely represented in
    +non-intermediate languages designed for human-written code, and/or in
    +Java Virtual Machine byte code, into Target Code. Thus, for example,
    +use of source code generators and preprocessors need not be considered
    +part of the Compilation Process, since the Compilation Process can be
    +understood as starting with the output of the generators or
    +preprocessors.
    +
    +A Compilation Process is "Eligible" if it is done using GCC, alone or
    +with other GPL-compatible software, or if it is done without using any
    +work based on GCC. For example, using non-GPL-compatible Software to
    +optimize any GCC intermediate representations would not qualify as an
    +Eligible Compilation Process.
    +
    +1. Grant of Additional Permission.
    +
    +You have permission to propagate a work of Target Code formed by
    +combining the Runtime Library with Independent Modules, even if such
    +propagation would otherwise violate the terms of GPLv3, provided that
    +all Target Code was generated by Eligible Compilation Processes. You
    +may then convey such a combination under terms of your choice,
    +consistent with the licensing of the Independent Modules.
    +
    +2. No Weakening of GCC Copyleft.
    +
    +The availability of this Exception does not imply any general
    +presumption that third-party software is unaffected by the copyleft
    +requirements of the license of GCC.
        

    Hopefully that text is self-explanatory. If it isn't, you need to speak to your lawyer, or the Free Software Foundation. -

    The Documentation: GPL, FDL

    +

    The Documentation: GPL, FDL

    The documentation shipped with the library and made available over the web, excluding the pages generated from source comments, are copyrighted by the Free Software Foundation, and placed under the @@ -110,4 +102,4 @@ requirements of the license of GCC.

    If you plan on making copies of the documentation, please let us know. We can probably offer suggestions. -

    Prev Up Next
    Chapter 1. Status Home Bugs
    +

    Prev Up Next
    Chapter 1. Status Home Bugs
    diff --git a/libstdc++-v3/doc/html/manual/localization.html b/libstdc++-v3/doc/html/manual/localization.html index 004cd35d130..8a2fa1e7dd3 100644 --- a/libstdc++-v3/doc/html/manual/localization.html +++ b/libstdc++-v3/doc/html/manual/localization.html @@ -1,26 +1,18 @@ -Chapter 8.  Localization
    Chapter 8.  + + +Chapter 8.  Localization
    Chapter 8.  Localization
    Prev Part II.  Standard Contents -  Next

    Chapter 8.  +

    		 Next

    Chapter 8.  Localization - -

    Table of Contents

    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future

    Locales

    locale

    + +

    Table of Contents

    Locales
    locale
    Requirements
    Design
    Implementation
    Interacting with "C" locales
    Future
    Facets
    ctype
    Implementation
    Specializations
    Future
    codecvt
    Requirements
    Design
    wchar_t Size
    Support for Unicode
    Other Issues
    Implementation
    Use
    Future
    messages
    Requirements
    Design
    Implementation
    Models
    The GNU Model
    Use
    Future

    Locales

    locale

    Describes the basic locale object, including nested classes id, facet, and the reference-counted implementation object, class _Impl. -

    Requirements

    +

    Requirements

    Class locale is non-templatized and has two distinct types nested inside of it:

    @@ -56,14 +48,14 @@ class id

    Provides an index for looking up specific facets. -

    Design

    +

    Design

    The major design challenge is fitting an object-orientated and non-global locale design on top of POSIX and other relevant standards, which include the Single Unix (nee X/Open.)

    Because C and earlier versions of POSIX fall down so completely, portability is an issue. -

    Implementation

    Interacting with "C" locales

    • +

    Implementation

    Interacting with "C" locales

    • `locale -a` displays available locales. 

       af_ZA
@@ -393,7 +385,7 @@ global locale" (emphasis Paolo), that is:
   particular on the working of locale(""), which constructs the locale
   object from the environment of the running program, that is, in
   practice, the set of LC_ALL, LANG, etc. variable of the shell.
-

    Future

    • +

    Future

    • Locale initialization: at what point does _S_classic, _S_global get initialized? Can named locales assume this initialization has already taken place? @@ -411,35 +403,35 @@ global locale" (emphasis Paolo), that is: What should non-required facet instantiations do? If the generic implementation is provided, then how to end-users provide specializations? -

    Bibliography

    +

    Bibliography

    The GNU C Library . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization - .

    + .

    Correspondence - . Ulrich Drepper. Copyright © 2002 .

    + . Ulrich Drepper. Copyright © 2002 .

    ISO/IEC 14882:1998 Programming languages - C++ - . Copyright © 1998 ISO.

    + . Copyright © 1998 ISO.

    ISO/IEC 9899:1999 Programming languages - C - . Copyright © 1999 ISO.

    + . Copyright © 1999 ISO.

    System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008) - . Copyright © 2008 + . Copyright © 2008 The Open Group/The Institute of Electrical and Electronics Engineers, Inc. - .

    + .

    The C++ Programming Language, Special Edition . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. Addison Wesley - .

    + .

    Standard C++ IOStreams and Locales . Advanced Programmer's Guide and Reference . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. Addison Wesley Longman - .

    Prev Up Next
    Chapter 7.  + .

    Prev Up Next
    Chapter 7.  Strings  Home Facets
    diff --git a/libstdc++-v3/doc/html/manual/make.html b/libstdc++-v3/doc/html/manual/make.html index aa9c7f666d5..1fbbf8f9f1f 100644 --- a/libstdc++-v3/doc/html/manual/make.html +++ b/libstdc++-v3/doc/html/manual/make.html @@ -1,17 +1,9 @@ -Make
    Make
    Prev Chapter 2. Setup Next

    Make

    If you have never done this before, you should read the basic + + +Make

    Make
    Prev Chapter 2. Setup Next

    Make

    If you have never done this before, you should read the basic GCC Installation Instructions first. Read all of them. Twice.

    Then type: make, and congratulations, you've started to build. -

    Prev Up Next
    Configure Home Chapter 3. Using
    +

    Prev Up Next
    Configure Home Chapter 3. Using
    diff --git a/libstdc++-v3/doc/html/manual/memory.html b/libstdc++-v3/doc/html/manual/memory.html index fc8e09fdb30..b097e5ff65f 100644 --- a/libstdc++-v3/doc/html/manual/memory.html +++ b/libstdc++-v3/doc/html/manual/memory.html @@ -1,23 +1,15 @@ -Memory
    Memory
    Prev Chapter 6.  + + +Memory
    Memory
    Prev Chapter 6.  Utilities - Next

    Memory

    +

    		 Next

    Memory

    Memory contains three general areas. First, function and operator calls via new and delete operator or member function calls. Second, allocation via allocator. And finally, smart pointer and intelligent pointer abstractions. -

    Allocators

    +

    Allocators

    Memory management for Standard Library entities is encapsulated in a class template called allocator. The allocator abstraction is used throughout the @@ -25,7 +17,7 @@ algorithms, and parts of iostreams. This class, and base classes of it, are the superset of available free store (“heap”) management classes. -

    Requirements

    +

    Requirements

    The C++ standard only gives a few directives in this area:

    • When you add elements to a container, and the container must @@ -62,7 +54,7 @@

    Complete details can be found in the C++ standard, look in [20.4 Memory]. -

    Design Issues

    +

    Design Issues

    The easiest way of fulfilling the requirements is to call operator new each time a container needs memory, and to call operator delete each time @@ -101,7 +93,7 @@ or loading and unloading shared objects in memory. As such, using caching allocators on systems that do not support abi::__cxa_atexit is not recommended. -

    Implementation

    Interface Design

    +

    Implementation

    Interface Design

    The only allocator interface that is supported is the standard C++ interface. As such, all STL containers have been adjusted, and all external allocators have @@ -114,7 +106,7 @@

    The base class that allocator is derived from may not be user-configurable. -

    Selecting Default Allocation Policy

    +

    Selecting Default Allocation Policy

    It's difficult to pick an allocation strategy that will provide maximum utility, without excessively penalizing some behavior. In fact, it's difficult just deciding which typical actions to measure @@ -151,7 +143,7 @@ The current default choice for allocator is __gnu_cxx::new_allocator. -

    Disabling Memory Caching

    +

    Disabling Memory Caching

    In use, allocator may allocate and deallocate using implementation-specific strategies and heuristics. Because of this, a given call to an allocator object's @@ -187,7 +179,7 @@ environment, it likely means that you linked against objects built against the older library (objects which might still using the cached allocations...). -

    Using a Specific Allocator

    +

    Using a Specific Allocator

    You can specify different memory management schemes on a per-container basis, by overriding the default Allocator template parameter. For example, an easy @@ -198,7 +190,7 @@ Likewise, a debugging form of whichever allocator is currently in use: 

         std::deque <int, __gnu_cxx::debug_allocator<std::allocator<int> > >  debug_deque;
-

    Custom Allocators

    +

    Custom Allocators

    Writing a portable C++ allocator would dictate that the interface would look much like the one specified for allocator. Additional member functions, but @@ -207,7 +199,7 @@ Probably the best place to start would be to copy one of the extension allocators: say a simple one like new_allocator. -

    Extension Allocators

    +

    Extension Allocators

    Several other allocators are provided as part of this implementation. The location of the extension allocators and their names have changed, but in all cases, functionality is @@ -318,33 +310,33 @@ of the used and unused memory locations. It has its own chapter in the documentation. -

    Bibliography

    +

    Bibliography

    ISO/IEC 14882:1998 Programming languages - C++ . isoc++_1998 - 20.4 Memory.

    + 20.4 Memory.

    The Standard Librarian: What Are Allocators Good For? - . Matt Austern. + . Matt Austern. C/C++ Users Journal - .

    + .

    The Hoard Memory Allocator - . Emery Berger.

    + . Emery Berger.

    Reconsidering Custom Memory Allocation - . Emery Berger. Ben Zorn. Kathryn McKinley. Copyright © 2002 OOPSLA.

    + . Emery Berger. Ben Zorn. Kathryn McKinley. Copyright © 2002 OOPSLA.

    Allocator Types - . Klaus Kreft. Angelika Langer. + . Klaus Kreft. Angelika Langer. C/C++ Users Journal - .

    The C++ Programming Language. Bjarne Stroustrup. Copyright © 2000 . 19.4 Allocators. + .

    The C++ Programming Language. Bjarne Stroustrup. Copyright © 2000 . 19.4 Allocators. Addison Wesley - .

    Yalloc: A Recycling C++ Allocator. Felix Yen.

    auto_ptr

    Limitations

    Explaining all of the fun and delicious things that can + .

    Yalloc: A Recycling C++ Allocator. Felix Yen.

    auto_ptr

    Limitations

    Explaining all of the fun and delicious things that can happen with misuse of the auto_ptr class template (called AP here) would take some time. Suffice it to say that the use of AP @@ -395,7 +387,7 @@ to die. AP is trivial to write, however, so you could write your own auto_array_ptr for that situation (in fact, this has been done many times; check the mailing lists, Usenet, Boost, etc). -

    Use in Containers

    +

    Use in Containers

    All of the containers described in the standard library require their contained types to have, among other things, a copy constructor like this: @@ -431,16 +423,16 @@ }

    Should you try this with the checks enabled, you will see an error. -

    shared_ptr

    +

    shared_ptr

    The shared_ptr class template stores a pointer, usually obtained via new, and implements shared ownership semantics. -

    Requirements

    +

    Requirements

    The standard deliberately doesn't require a reference-counted implementation, allowing other techniques such as a circular-linked-list.

    -

    Design Issues

    +

    Design Issues

    The shared_ptr code is kindly donated to GCC by the Boost project and the original authors of the code. The basic design and algorithms are from Boost, the notes below describe details specific to @@ -454,7 +446,7 @@ drops to zero. Derived classes override those functions to destroy resources in a context where the correct dynamic type is known. This is an application of the technique known as type erasure. -

    Implementation

    Class Hierarchy

    +

    Implementation

    Class Hierarchy

    A shared_ptr<T> contains a pointer of type T* and an object of type __shared_count. The shared_count contains a @@ -501,7 +493,7 @@ C++11-only features are: rvalue-ref/move support, allocator support, aliasing constructor, make_shared & allocate_shared. Additionally, the constructors taking auto_ptr parameters are deprecated in C++11 mode. -

    Thread Safety

    +

    Thread Safety

    The Thread Safety section of the Boost shared_ptr documentation says "shared_ptr @@ -546,7 +538,7 @@ compiler, standard library, platform etc. For the version of shared_ptr in libstdc++ the compiler and library are fixed, which makes things much simpler: we have an atomic CAS or we don't, see Lock Policy below for details. -

    Selecting Lock Policy

    +

    Selecting Lock Policy

    There is a single _Sp_counted_base class, which is a template parameterized on the enum @@ -587,7 +579,7 @@ used when libstdc++ is built without --enable-threadsext/atomicity.h, which detect if the program is multi-threaded. If only one thread of execution exists in the program then less expensive non-atomic operations are used. -

    Related functions and classes
    dynamic_pointer_cast, static_pointer_cast, +

    Related functions and classes
    dynamic_pointer_cast, static_pointer_cast, const_pointer_cast

    As noted in N2351, these functions can be implemented non-intrusively using the alias constructor. However the aliasing constructor is only available @@ -620,13 +612,13 @@ is called. Users should not try to use this. As well as the extra constructors, this implementation also needs some members of _Sp_counted_deleter to be protected where they could otherwise be private. -

    Use

    Examples

    +

    Use

    Examples

    Examples of use can be found in the testsuite, under testsuite/tr1/2_general_utilities/shared_ptr, testsuite/20_util/shared_ptr and testsuite/20_util/weak_ptr. -

    Unresolved Issues

    +

    Unresolved Issues

    The shared_ptr atomic access clause in the C++11 standard is not implemented in GCC.

    @@ -662,33 +654,33 @@ be private.

    tr1::_Sp_deleter could be a private member of tr1::__shared_count but it would alter the ABI. -

    Acknowledgments

    +

    Acknowledgments

    The original authors of the Boost shared_ptr, which is really nice code to work with, Peter Dimov in particular for his help and invaluable advice on thread safety. Phillip Jordan and Paolo Carlini for the lock policy implementation. -

    Bibliography

    +

    Bibliography

    Improving shared_ptr for C++0x, Revision 2 - . + . N2351 - .

    + .

    C++ Standard Library Active Issues List - . + . N2456 - .

    + .

    Working Draft, Standard for Programming Language C++ - . + . N2461 - .

    + .

    Boost C++ Libraries documentation, shared_ptr - . + . N2461 - .

    Prev Up Next
    Pairs Home Traits
    + .

    Prev Up Next
    Pairs Home Traits
    diff --git a/libstdc++-v3/doc/html/manual/mt_allocator.html b/libstdc++-v3/doc/html/manual/mt_allocator.html index 8349da341b6..5efda940418 100644 --- a/libstdc++-v3/doc/html/manual/mt_allocator.html +++ b/libstdc++-v3/doc/html/manual/mt_allocator.html @@ -1,22 +1,10 @@ -Chapter 20. The mt_allocator
    Chapter 20. The mt_allocator
    Prev Part III.  + + +Chapter 20. The mt_allocator
    Chapter 20. The mt_allocator
    Prev Part III.  Extensions - Next

    Chapter 20. The mt_allocator

    Table of Contents

    Intro
    Design Issues
    Overview
    Implementation
    Tunable Parameters
    Initialization
    Deallocation Notes
    Single Thread Example
    Multiple Thread Example

    -

    Intro

    +

    		 Next

    Chapter 20. The mt_allocator

    Table of Contents

    Intro
    Design Issues
    Overview
    Implementation
    Tunable Parameters
    Initialization
    Deallocation Notes
    Single Thread Example
    Multiple Thread Example

    +

    Intro

    The mt allocator [hereinafter referred to simply as "the allocator"] is a fixed size (power of two) allocator that was initially developed specifically to suit the needs of multi threaded @@ -32,4 +20,4 @@

    The aim of this document is to describe - from an application point of view - the "inner workings" of the allocator. -

    Prev Up Next
    Diagnostics Home Design Issues
    +

    Prev Up Next
    Diagnostics Home Design Issues
    diff --git a/libstdc++-v3/doc/html/manual/numerics.html b/libstdc++-v3/doc/html/manual/numerics.html index c11c2c103f8..c7076fd0572 100644 --- a/libstdc++-v3/doc/html/manual/numerics.html +++ b/libstdc++-v3/doc/html/manual/numerics.html @@ -1,23 +1,15 @@ -Chapter 12.  Numerics
    Chapter 12.  + + +Chapter 12.  Numerics
    Chapter 12.  Numerics
    Prev Part II.  Standard Contents -  Next

    Chapter 12.  +

    		 Next

    Chapter 12.  Numerics - -

    Table of Contents

    Complex
    complex Processing
    Generalized Operations
    Interacting with C
    Numerics vs. Arrays
    C99

    Complex

    -

    complex Processing

    + +

    Table of Contents

    Complex
    complex Processing
    Generalized Operations
    Interacting with C
    Numerics vs. Arrays
    C99

    Complex

    +

    complex Processing

    Using complex<> becomes even more comple- er, sorry, complicated, with the not-quite-gratuitously-incompatible addition of complex types to the C language. David Tribble has @@ -36,7 +28,7 @@ <complex.h> includes both <complex> and the C99 <complex.h> (if the C library provides it). -

    Prev Up Next
    Chapter 11.  +

    Prev Up Next
    Chapter 11.  Algorithms  Home Generalized Operations
    diff --git a/libstdc++-v3/doc/html/manual/numerics_and_c.html b/libstdc++-v3/doc/html/manual/numerics_and_c.html index 46dfff5edbc..0897edbaf97 100644 --- a/libstdc++-v3/doc/html/manual/numerics_and_c.html +++ b/libstdc++-v3/doc/html/manual/numerics_and_c.html @@ -1,17 +1,9 @@ -Interacting with C
    Interacting with C
    Prev Chapter 12.  + + +Interacting with C
    Interacting with C
    Prev Chapter 12.  Numerics - Next

    Interacting with C

    Numerics vs. Arrays

    One of the major reasons why FORTRAN can chew through numbers so well +

    		 Next

    Interacting with C

    Numerics vs. Arrays

    One of the major reasons why FORTRAN can chew through numbers so well is that it is defined to be free of pointer aliasing, an assumption that C89 is not allowed to make, and neither is C++98. C99 adds a new keyword, restrict, to apply to individual pointers. The @@ -26,7 +18,7 @@ speaking this is only one of the five template classes, and they are designed to be familiar to people who have worked with the BLAS libraries before. -

    C99

    In addition to the other topics on this page, we'll note here some +

    C99

    In addition to the other topics on this page, we'll note here some of the C99 features that appear in libstdc++.

    The C99 features depend on the --enable-c99 configure flag. This flag is already on by default, but it can be disabled by the @@ -39,7 +31,7 @@ are supported, as is the lldiv_t typedef. Also supported are the wide character functions using 'long long', like wcstoll. -

    Prev Up Next
    Generalized Operations Home Chapter 13.  +

    Prev Up Next
    Generalized Operations Home Chapter 13.  Input and Output
    diff --git a/libstdc++-v3/doc/html/manual/pairs.html b/libstdc++-v3/doc/html/manual/pairs.html index 43c04745e2e..130c63254f0 100644 --- a/libstdc++-v3/doc/html/manual/pairs.html +++ b/libstdc++-v3/doc/html/manual/pairs.html @@ -1,17 +1,9 @@ -Pairs
    Pairs
    Prev Chapter 6.  + + +Pairs
    Pairs
    Prev Chapter 6.  Utilities - Next

    Pairs

    The pair<T1,T2> is a simple and handy way to +

    		 Next

    Pairs

    The pair<T1,T2> is a simple and handy way to carry around a pair of objects. One is of type T1, and another of type T2; they may be the same type, but you don't get anything extra if they are. The two members can be accessed directly, as @@ -46,7 +38,7 @@ instance of a pair instantiated on their respective types: 

         pair<int,MyClass> p = make_pair(4,myobject);
-
    Prev Up Next
    Chapter 6.  +
    Prev Up Next
    Chapter 6.  Utilities  Home Memory
    diff --git a/libstdc++-v3/doc/html/manual/parallel_mode.html b/libstdc++-v3/doc/html/manual/parallel_mode.html index 3cd6ef16fab..65ad01ffd0a 100644 --- a/libstdc++-v3/doc/html/manual/parallel_mode.html +++ b/libstdc++-v3/doc/html/manual/parallel_mode.html @@ -1,23 +1,9 @@ -Chapter 18. Parallel Mode
    Chapter 18. Parallel Mode
    Prev Part III.  + + +Chapter 18. Parallel Mode
    Chapter 18. Parallel Mode
    Prev Part III.  Extensions - Next

    Chapter 18. Parallel Mode

    Table of Contents

    Intro
    Semantics
    Using
    Prerequisite Compiler Flags
    Using Parallel Mode
    Using Specific Parallel Components
    Design
    Interface Basics
    Configuration and Tuning
    Setting up the OpenMP Environment
    Compile Time Switches
    Run Time Settings and Defaults
    Implementation Namespaces
    Testing
    Bibliography

    The libstdc++ parallel mode is an experimental parallel +

    		 Next

    Chapter 18. Parallel Mode

    Table of Contents

    Intro
    Semantics
    Using
    Prerequisite Compiler Flags
    Using Parallel Mode
    Using Specific Parallel Components
    Design
    Interface Basics
    Configuration and Tuning
    Setting up the OpenMP Environment
    Compile Time Switches
    Run Time Settings and Defaults
    Implementation Namespaces
    Testing
    Bibliography

    The libstdc++ parallel mode is an experimental parallel implementation of many algorithms the C++ Standard Library.

    Several of the standard algorithms, for instance @@ -25,14 +11,14 @@ Several of the standard algorithms, for instance annotations. These parallel mode constructs and can be invoked by explicit source declaration or by compiling existing sources with a specific compiler flag. -

    Intro

    The following library components in the include +

    Intro

    The following library components in the include numeric are included in the parallel mode:

    • std::accumulate

    • std::adjacent_difference

    • std::inner_product

    • std::partial_sum

    The following library components in the include -algorithm are included in the parallel mode:

    • std::adjacent_find

    • std::count

    • std::count_if

    • std::equal

    • std::find

    • std::find_if

    • std::find_first_of

    • std::for_each

    • std::generate

    • std::generate_n

    • std::lexicographical_compare

    • std::mismatch

    • std::search

    • std::search_n

    • std::transform

    • std::replace

    • std::replace_if

    • std::max_element

    • std::merge

    • std::min_element

    • std::nth_element

    • std::partial_sort

    • std::partition

    • std::random_shuffle

    • std::set_union

    • std::set_intersection

    • std::set_symmetric_difference

    • std::set_difference

    • std::sort

    • std::stable_sort

    • std::unique_copy

    Bibliography

    +algorithm are included in the parallel mode:

    • std::adjacent_find

    • std::count

    • std::count_if

    • std::equal

    • std::find

    • std::find_if

    • std::find_first_of

    • std::for_each

    • std::generate

    • std::generate_n

    • std::lexicographical_compare

    • std::mismatch

    • std::search

    • std::search_n

    • std::transform

    • std::replace

    • std::replace_if

    • std::max_element

    • std::merge

    • std::min_element

    • std::nth_element

    • std::partial_sort

    • std::partition

    • std::random_shuffle

    • std::set_union

    • std::set_intersection

    • std::set_symmetric_difference

    • std::set_difference

    • std::sort

    • std::stable_sort

    • std::unique_copy

    Bibliography

    Parallelization of Bulk Operations for STL Dictionaries . Johannes Singler. Leonor Frias. Copyright © 2007 . Workshop on Highly Parallel Processing on a Chip (HPPC) 2007. (LNCS) - .

    + .

    The Multi-Core Standard Template Library . Johannes Singler. Peter Sanders. Felix Putze. Copyright © 2007 . Euro-Par 2007: Parallel Processing. (LNCS 4641) - .

    Prev Up Next
    Design Home Semantics
    + .

    Prev Up Next
    Design Home Semantics
    diff --git a/libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html b/libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html index f62faf48b1b..f5e51a90671 100644 --- a/libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html +++ b/libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html @@ -1,34 +1,6 @@ -Testing
    Testing
    Prev Chapter 22. Policy-Based Data Structures Next

    Testing

    Regression

    The library contains a single comprehensive regression test. + + +Testing

    Testing
    Prev Chapter 22. Policy-Based Data Structures Next

    Testing

    Regression

    The library contains a single comprehensive regression test. For a given container type in this library, the test creates an object of the container type and an object of the corresponding standard type (e.g., std::set). It @@ -50,9 +22,9 @@ this library's containers and the containers' value-types are configured to use this allocator.

    For granularity, the test is split into the several sources, each checking only some containers.

    For more details, consult the files in - testsuite/ext/pb_ds/regression.

    Performance

    Hash-Based

    + testsuite/ext/pb_ds/regression.

    Performance

    Hash-Based

    Text find -

    +

    Description

    This test inserts a number of values with keys from an @@ -72,16 +44,16 @@

    The test checks the effect of different range-hashing functions, trigger policies, and cache-hashing policies. -

    +

    Results

    The graphic below show the results for the native and collision-chaining hash types the the function applied being a text find timing test using find. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -175,7 +147,7 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    In this setting, the range-hashing scheme affects performance more than other policies. As the results show, containers using @@ -190,9 +162,9 @@ library's implementation. (Unfortunately, it was not possible to run the tests with std::tr1::unordered_map 's cache_hash_code = true , as it appeared to - malfuntion.)

    + malfuntion.)

    Integer find -

    +

    Description

    This test inserts a number of values with uniform integer keys into a container, then performs a series of finds @@ -205,7 +177,7 @@

    The test checks the effect of different underlying hash-tables, - range-hashing functions, and trigger policies.

    + range-hashing functions, and trigger policies.

    Results

    There are two sets of results for this type, one for @@ -213,10 +185,10 @@

    The first graphic below shows the results for the native and collision-chaining hash types. The function applied being a random integer timing test using find. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -315,10 +287,10 @@

    And the second graphic shows the results for the native and general-probe hash types. The function applied being a random integer timing test using find. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -378,7 +350,7 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    In this setting, the choice of underlying hash-table affects performance most, then the range-hashing scheme and, only finally, @@ -394,9 +366,9 @@ above graphics should be noted that std::tr1::unordered_map are hard-wired currently to mod-based schemes. -

    +

    Integer Subscript find -

    +

    Description

    This test inserts a number of values with uniform integer keys into a container, then performs a series of finds @@ -408,7 +380,7 @@ performance/ext/pb_ds/random_int_subscript_find_timing.cc

    The test checks the effect of different underlying - hash-tables, range-hashing functions, and trigger policies.

    + hash-tables, range-hashing functions, and trigger policies.

    Results

    There are two sets of results for this type, one for @@ -417,10 +389,10 @@ and collision-chaining hash types, using as the function applied an integer subscript timing test with find. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -517,10 +489,10 @@

    And the second graphic shows the results for the native and general-probe hash types. The function applied being a random integer timing test using find. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -580,12 +552,12 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    This test shows similar results to Hash-Based - Integer find Find Timing test.

    + Integer find Find Timing test.

    Integer Subscript insert -

    +

    Description

    This test inserts a number of values with uniform i.i.d. integer keys into a container, using @@ -597,7 +569,7 @@ performance/ext/pb_ds/random_int_subscript_insert_timing.cc

    The test checks the effect of different underlying - hash-tables.

    + hash-tables.

    Results

    There are two sets of results for this type, one for @@ -606,10 +578,10 @@ and collision-chaining hash types, using as the function applied an integer subscript timing test with insert. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -706,10 +678,10 @@

    And the second graphic shows the results for the native and general-probe hash types. The function applied being a random integer timing test using find. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -769,7 +741,7 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    In this setting, as in Hash-Based Text find Find Timing test and Hash-Based @@ -798,9 +770,9 @@ find Find Timing Test and Hash-Based Integer find Find Timing Test. Unsurprisingly, however, containers with lower αmax perform worse in this case, - since more re-hashes are performed.

    + since more re-hashes are performed.

    Integer find with Skewed-Distribution -

    +

    Description

    This test inserts a number of values with a markedly non-uniform integer keys into a container, then performs @@ -813,13 +785,13 @@ performance/ext/pb_ds/hash_zlob_random_int_find_timing.cc

    The test checks the effect of different range-hashing - functions and trigger policies.

    + functions and trigger policies.

    Results

    The graphic below show the results for the native, collision-chaining, and general-probing hash types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -896,7 +868,7 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    In this setting, the distribution of keys is so skewed that the underlying hash-table type affects performance marginally. @@ -923,9 +895,9 @@ performance is bad, a χ2 test can be used to check how to transform it into a more uniform distribution.

    For this reason, this library's default range-hashing - function is mask-based.

    + function is mask-based.

    Erase Memory Use -

    +

    Description

    This test inserts a number of uniform integer keys into a container, then erases all keys except one. It measures @@ -935,13 +907,13 @@ performance/ext/pb_ds/hash_random_int_erase_mem_usage.cc

    The test checks how containers adjust internally as their - logical size decreases.

    + logical size decreases.

    Results

    The graphic below show the results for the native, collision-chaining, and general-probing hash types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetails
    n_hash_map_ncah
    std::tr1::unordered_map @@ -1018,7 +990,7 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    The standard's hash-based containers act very differently than trees in this respect. When erasing numerous keys from an standard @@ -1026,9 +998,9 @@ depending on whether the container is tree-based or hash-based. This is a fundamental consequence of the standard's interface for associative containers, and it is not due to a specific - implementation.

    Branch-Based

    + implementation.

    Branch-Based

    Text insert -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into a container @@ -1040,7 +1012,7 @@ performance/ext/pb_ds/tree_text_insert_timing.cc -

    +

    Results

    The three graphics below show the results for the native tree and this library's node-based trees, the native tree and @@ -1048,10 +1020,10 @@ and this library's PATRICIA-trie, respectively.

    The graphic immediately below shows the results for the native tree type and several node-based tree types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_map
    std::map @@ -1081,10 +1053,10 @@ null_node_update

    The graphic below shows the results for the native tree type and a vector-based tree type. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_map
    std::map @@ -1102,10 +1074,10 @@ null_node_update

    The graphic below shows the results for the native tree type and a PATRICIA trie type. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_map
    std::map @@ -1121,7 +1093,7 @@ Node_update null_node_update -
    +
    Observations

    Observing the first graphic implies that for this setting, a splay tree (tree with Tag @@ -1141,9 +1113,9 @@ encountered, a new "hash-table" is built A large fan-out PATRICIA trie, however, doe does well in look-ups (see Branch-Based Text find Find Timing Test). It may be - beneficial in semi-static settings.

    + beneficial in semi-static settings.

    Text find -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([wickland96thirty]) into @@ -1156,14 +1128,14 @@ performance/ext/pb_ds/text_find_timing.cc

    The test checks the effect of different underlying - data structures.

    + data structures.

    Results

    The graphic immediately below shows the results for the native tree type and several other tree types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_map
    std::map @@ -1215,7 +1187,7 @@ Node_Update null_node_update -
    +
    Observations

    For this setting, a splay tree (tree with Tag @@ -1248,9 +1220,9 @@ by a sub-trie. A large-fan-out PATRICIA trie does not do well on modifications (see Tree-Based and Trie-Based Text Insert Timing Test). Therefore, it is possibly beneficial in - semi-static settings.

    + semi-static settings.

    Text find with Locality-of-Reference -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -1266,14 +1238,14 @@ performance/ext/pb_ds/tree_text_lor_find_timing.cc

    The test checks the effect of different underlying - data structures in a locality-of-reference setting.

    + data structures in a locality-of-reference setting.

    Results

    The graphic immediately below shows the results for the native tree type and several other tree types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_map
    std::map @@ -1325,7 +1297,7 @@ Node_Update null_node_update -
    +
    Observations

    For this setting, an ordered-vector tree (tree with Tag @@ -1335,9 +1307,9 @@ tree all share approximately the same performance.

    A splay tree (tree with Tag = splay_tree_tag) does much better, since each (successful) find "bubbles" the - corresponding node to the root of the tree.

    + corresponding node to the root of the tree.

    split and join -

    +

    Description

    This test a container, inserts into a number of values, splits the container at the median, and joins the two containers. (If the @@ -1356,14 +1328,14 @@ implication, this test checks the most efficient way to erase a sub-sequence from a tree-like-based container, since this can always be performed by a small sequence of splits and joins. -

    +

    Results

    The graphic immediately below shows the results for the native tree type and several other tree types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_set
    std::set @@ -1415,7 +1387,7 @@ Node_Update null_node_update -
    +
    Observations

    In this test, the native red-black trees must be split and joined externally, through a sequence of erase and @@ -1442,9 +1414,9 @@ via container_traits).

    It is important to note that split and join are not esoteric methods - they are the most efficient means of erasing a contiguous range of values from a - tree based container.

    + tree based container.

    Order-Statistics -

    +

    Description

    This test creates a container, inserts random integers into the the container, and then checks the order-statistics of the @@ -1461,14 +1433,14 @@ performance/ext/pb_ds/tree_order_statistics_timing.cc

    The test checks the performance difference of policies based - on node-invariant as opposed to a external functions.

    + on node-invariant as opposed to a external functions.

    Results

    The graphic immediately below shows the results for the native tree type and several other tree types. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_set
    std::set @@ -1496,7 +1468,7 @@ Node_Update tree_order_statistics_node_update -
    +
    Observations

    In this test, the native red-black tree can support order-statistics queries only externally, by performing a @@ -1513,9 +1485,9 @@ tree (tree with Tag = rb_tree_tag ) is logarithmic in the number of elements. Consequently, the splay - tree has worse performance than the red-black tree.

    Multimap

    + tree has worse performance than the red-black tree.

    Multimap

    Text find with Small Secondary-to-Primary Key Ratios -

    +

    Description

    This test inserts a number of pairs into a container. The first item of each pair is a string from an arbitrary text @@ -1536,14 +1508,14 @@ performance/ext/pb_ds/multimap_text_find_timing_small.cc

    The test checks the find-time scalability of different - "multimap" designs.

    + "multimap" designs.

    Results

    The graphic below show the results for "multimaps" which use a tree-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_mmap
    std::multimap @@ -1602,10 +1574,10 @@ αmin = 1/8 and αmax = 1/2

    The graphic below show the results for "multimaps" which use a hash-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_hash_mmap
    std::tr1::unordered_multimap @@ -1684,12 +1656,12 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    See Observations::Mapping-Semantics - Considerations.

    + Considerations.

    Text find with Large Secondary-to-Primary Key Ratios -

    +

    Description

    This test inserts a number of pairs into a container. The first item of each pair is a string from an arbitrary text @@ -1709,14 +1681,14 @@ performance/ext/pb_ds/multimap_text_find_timing_large.cc

    The test checks the find-time scalability of different - "multimap" designs.

    + "multimap" designs.

    Results

    The graphic below show the results for "multimaps" which use a tree-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_mmap
    std::multimap @@ -1775,10 +1747,10 @@ αmin = 1/8 and αmax = 1/2

    The graphic below show the results for "multimaps" which use a hash-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_hash_mmap
    std::tr1::unordered_multimap @@ -1857,13 +1829,13 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    See Observations::Mapping-Semantics - Considerations.

    + Considerations.

    Text insert with Small Secondary-to-Primary Key Ratios -

    +

    Description

    This test inserts a number of pairs into a container. The first item of each pair is a string from an arbitrary text @@ -1885,14 +1857,14 @@ performance/ext/pb_ds/multimap_text_insert_timing_small.cc

    The test checks the insert-time scalability of different - "multimap" designs.

    + "multimap" designs.

    Results

    The graphic below show the results for "multimaps" which use a tree-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_mmap
    std::multimap @@ -1951,10 +1923,10 @@ αmin = 1/8 and αmax = 1/2

    The graphic below show the results for "multimaps" which use a hash-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_hash_mmap
    std::tr1::unordered_multimap @@ -2033,13 +2005,13 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    See Observations::Mapping-Semantics - Considerations.

    + Considerations.

    Text insert with Small Secondary-to-Primary Key Ratios -

    +

    Description

    This test inserts a number of pairs into a container. The first item of each pair is a string from an arbitrary text @@ -2061,14 +2033,14 @@ performance/ext/pb_ds/multimap_text_insert_timing_large.cc

    The test checks the insert-time scalability of different - "multimap" designs.

    + "multimap" designs.

    Results

    The graphic below show the results for "multimaps" which use a tree-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_mmap
    std::multimap @@ -2127,10 +2099,10 @@ αmin = 1/8 and αmax = 1/2

    The graphic below show the results for "multimaps" which use a hash-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_hash_mmap
    std::tr1::unordered_multimap @@ -2209,13 +2181,13 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    See Observations::Mapping-Semantics - Considerations.

    + Considerations.

    Text insert with Small Secondary-to-Primary Key Ratios Memory Use -

    +

    Description

    This test inserts a number of pairs into a container. The first item of each pair is a string from an arbitrary text @@ -2232,14 +2204,14 @@ performance/ext/pb_ds/multimap_text_insert_mem_usage_small.cc

    The test checks the memory scalability of different - "multimap" designs.

    + "multimap" designs.

    Results

    The graphic below show the results for "multimaps" which use a tree-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_mmap
    std::multimap @@ -2298,10 +2270,10 @@ αmin = 1/8 and αmax = 1/2

    The graphic below show the results for "multimaps" which use a hash-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_hash_mmap
    std::tr1::unordered_multimap @@ -2380,13 +2352,13 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    See Observations::Mapping-Semantics - Considerations.

    + Considerations.

    Text insert with Small Secondary-to-Primary Key Ratios Memory Use -

    +

    Description

    This test inserts a number of pairs into a container. The first item of each pair is a string from an arbitrary text @@ -2403,14 +2375,14 @@ performance/ext/pb_ds/multimap_text_insert_mem_usage_large.cc

    The test checks the memory scalability of different - "multimap" designs.

    + "multimap" designs.

    Results

    The graphic below show the results for "multimaps" which use a tree-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_mmap
    std::multimap @@ -2469,10 +2441,10 @@ αmin = 1/8 and αmax = 1/2

    The graphic below show the results for "multimaps" which use a hash-based container for primary keys. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    +

    Name/Instantiating TypeParameterDetailsParameterDetailsParameterDetails
    n_hash_mmap
    std::tr1::unordered_multimap @@ -2551,12 +2523,12 @@ hash_load_check_resize_trigger with αmin = 1/8 and αmax = 1/2 -
    +
    Observations

    See Observations::Mapping-Semantics - Considerations.

    Priority Queue

    + Considerations.

    Priority Queue

    Text push -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -2569,7 +2541,7 @@

    The test checks the effect of different underlying data structures. -

    +

    Results

    The two graphics below show the results for the native priority_queues and this library's priority_queues. @@ -2577,10 +2549,10 @@ native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -2639,10 +2611,10 @@

    The graphic below shows the results for the binary-heap based native priority queues and this library's pairing-heap priority_queue data structures. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -2674,7 +2646,7 @@ Tag pairing_heap_tag -
    +
    Observations

    Pairing heaps (priority_queue with Tag = pairing_heap_tag) @@ -2692,9 +2664,9 @@ operation, and the deque implementation is possibly hampered by its need to manipulate a relatively-complex type (deques support a O(1) push_front, even though it is - not used by std::priority_queue.)

    + not used by std::priority_queue.)

    Text push and pop -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -2707,7 +2679,7 @@

    The test checks the effect of different underlying data structures. -

    +

    Results

    The two graphics below show the results for the native priority_queues and this library's priority_queues. @@ -2715,10 +2687,10 @@ native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -2777,10 +2749,10 @@

    The graphic below shows the results for the native priority queues and this library's pairing-heap priority_queue data structures. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue adapting std::vector @@ -2804,7 +2776,7 @@ Tag pairing_heap_tag -
    +
    Observations

    These results are very similar to Priority Queue Text push Timing Test. As stated there, pairing heaps @@ -2824,9 +2796,9 @@ of push operations, pairing heaps are better in this case. See Priority Queue Random Integer push and pop - Timing Test for a case which is different.

    + Timing Test for a case which is different.

    Integer push -

    +

    Description

    This test inserts a number of values with integer keys into a container using push. It @@ -2838,7 +2810,7 @@

    The test checks the effect of different underlying data structures. -

    +

    Results

    The two graphics below show the results for the native priority_queues and this library's priority_queues. @@ -2846,10 +2818,10 @@ native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -2908,10 +2880,10 @@

    The graphic below shows the results for the binary-heap based native priority queues and this library's priority_queue data structures. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue adapting std::vector @@ -2935,7 +2907,7 @@ Tag binary_heap_tag -
    +
    Observations

    Binary heaps are the most suited for sequences of push and pop operations of primitive types @@ -2944,9 +2916,9 @@ such types in arrays, they outperform even pairing heaps. (See Priority Queue Text push Timing Test for the case of - non-primitive types.)

    + non-primitive types.)

    Integer push -

    +

    Description

    This test inserts a number of values with integer keys into a container using push , then removes them @@ -2959,16 +2931,16 @@

    The test checks the effect of different underlying data structures. -

    +

    Results

    The graphic immediately below shows the results for the native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -3024,7 +2996,7 @@ Tag pairing_heap_tag -
    +
    Observations

    Binary heaps are the most suited for sequences of push and pop operations of primitive types @@ -3046,9 +3018,9 @@ the number of pop operations is at most that of push operations, the test here is the "best" for the standard's - priority queue.

    + priority queue.

    Text pop Memory Use -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -3061,16 +3033,16 @@

    The test checks the effect of different underlying data structures. -

    +

    Results

    The graphic immediately below shows the results for the native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -3126,7 +3098,7 @@ Tag pairing_heap_tag -
    +
    Observations

    The priority queue implementations (excluding the standard's) use memory proportionally to the number of values they hold: @@ -3139,9 +3111,9 @@ impede performance compared to the standard's priority queues.

    See Hash-Based Erase Memory Use Test for a similar phenomenon regarding priority - queues.

    + queues.

    Text join -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -3156,16 +3128,16 @@

    The test checks the effect of different underlying data structures. -

    +

    Results

    The graphic immediately below shows the results for the native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -3221,7 +3193,7 @@ Tag pairing_heap_tag -
    +
    Observations

    In this test the node-based heaps perform join in either logarithmic or constant time. The binary heap requires @@ -3233,9 +3205,9 @@ and size() (since they are enough to expose the underlying array), but this is impossible for a std::deque-based standard priority queue. - Without heapify, the cost is super-linear.

    + Without heapify, the cost is super-linear.

    Text modify Up -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -3255,7 +3227,7 @@ arbitrary value larger (in the sense of the priority queue's comparison functor) corresponds to decrease-key in standard graph algorithms [clrs2001]. -

    +

    Results

    The two graphics below show the results for the native priority_queues and this library's priority_queues. @@ -3263,10 +3235,10 @@ native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -3325,10 +3297,10 @@

    The graphic below shows the results for the native priority queues and this library's pairing and thin heap priority_queue data structures. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    thin_heap
    priority_queue @@ -3344,7 +3316,7 @@ Tag pairing_heap_tag -
    +
    Observations

    As noted above, increasing an arbitrary value (in the sense of the priority queue's comparison functor) is very common in @@ -3372,9 +3344,9 @@ finding the appropriate value, then use the range-type iterator for the modify operation.

    The explanation for the standard's priority queues' performance is similar to that in Priority Queue Text - join Timing Test.

    + join Timing Test.

    Text modify Down -

    +

    Description

    This test inserts a number of values with keys from an arbitrary text ([ wickland96thirty ]) into @@ -3390,7 +3362,7 @@ performance/ext/pb_ds/priority_queue_text_modify_down_timing.cc

    The main purpose of this test is to contrast Priority Queue - Text modify Up Timing Test.

    + Text modify Up Timing Test.

    Results

    The two graphics below show the results for the native priority_queues and this library's priority_queues. @@ -3398,10 +3370,10 @@ native priority_queue type instantiated with different underlying container types versus several different versions of library's priority_queues. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    n_pq_vector
    std::priority_queue @@ -3460,10 +3432,10 @@

    The graphic below shows the results for the native priority queues and this library's pairing and thin heap priority_queue data structures. -

    +

    The abbreviated names in the legend of the graphic above are instantiated with the types in the following table. -

    Name/Instantiating TypeParameterDetails
    +

    Name/Instantiating TypeParameterDetails
    thin_heap
    priority_queue @@ -3479,7 +3451,7 @@ Tag pairing_heap_tag -
    +
    Observations

    Most points in these results are similar to Priority Queue Text modify Up Timing Test.

    It is interesting to note, however, that as opposed to that @@ -3494,7 +3466,7 @@ (in the sense of the priority queue's comparison functor), and so Priority Queue Text modify Up Timing Test - is more interesting - than this test.

    Observations

    Associative
    + than this test.

    Observations

    Associative
    Underlying Data-Structure Families

    In general, hash-based containers have better timing performance than containers based on different underlying-data structures. The @@ -3503,7 +3475,7 @@ order-preservation, or the ability to utilize node invariants. If memory-use is the major factor, an ordered-vector tree gives optimal results (albeit with high modificiation costs), and a - list-based container gives reasonable results.

    + list-based container gives reasonable results.

    Hash-Based Containers

    Hash-based containers are typically either collision chaining or probing. Collision-chaining @@ -3518,7 +3490,7 @@ useful also in multithreaded applications where each thread manipulates a hash-based container: in the standard, allocators have class-wise semantics (see [meyers96more] - Item 10); a - probing container might incur less contention in this case.

    + probing container might incur less contention in this case.

    Hash Policies

    In hash-based containers, the range-hashing scheme seems to affect performance more than other considerations. In most @@ -3537,7 +3509,7 @@ function.

    An orthogonal consideration is the trigger policy. This presents difficult tradeoffs. E.g., different load factors in a load-check trigger policy yield a - space/amortized-cost tradeoff.

    + space/amortized-cost tradeoff.

    Branch-Based Containers

    In general, there are several families of tree-based underlying data structures: balanced node-based trees @@ -3584,7 +3556,7 @@ maintaining such trees is higher than that of balanced trees. Moderate-fan-out trees might be useful for sequences where each element has a limited number of choices, e.g., DNA - strings.

    + strings.

    Mapping-Semantics

    Different mapping semantics were discussed in the introduction and design sections.Here the focus will be on the case where a keys can be composed into @@ -3664,11 +3636,11 @@ but with very high constants; using 1 with a tree-based container, the cost is Θ(nlog(mn)). Using 2, 3, and 4, the expected cost is Θ(n), but typically - with far lower costs than 1. 5 is similar to 1.

    Priority_Queue
    Complexity

    The following table shows the complexities of the different + with far lower costs than 1. 5 is similar to 1.

    Priority_Queue
    Complexity

    The following table shows the complexities of the different underlying data structures in terms of orders of growth. It is interesting to note that this table implies something about the constants of the operations as well (see Amortized push - and pop operations).

     pushpopmodifyerasejoin
    + and pop operations).

     pushpopmodifyerasejoin
    std::priority_queue Θ(n) worst @@ -3788,7 +3760,7 @@ of the priority queue's comparison functor), then the amortized time is O(1), but if II) it decreases it, then the amortized time is the same as the worst case time. Note that - for most algorithms, I) is important and II) is not.

    + for most algorithms, I) is important and II) is not.

    Amortized push and pop operations

    In many cases, a priority queue is needed primarily for @@ -3818,7 +3790,7 @@ Queue Random Integer push Timing Test and Priority Queue Random Integer push and pop Timing - Test.

    + Test.

    Graph Algorithms

    In some graph algorithms, a decrease-key operation is required [clrs2001]; @@ -3838,4 +3810,4 @@ as well. It is difficult to find an a-priori characterization of graphs in which the actual number of modify operations will dwarf the number of push and - pop operations.

    Prev Up Next
    Design Home Acknowledgments
    + pop operations.

    Prev Up Next
    Design Home Acknowledgments
    diff --git a/libstdc++-v3/doc/html/manual/policy_data_structures.html b/libstdc++-v3/doc/html/manual/policy_data_structures.html index f8909bb15fd..da7cbd18e0a 100644 --- a/libstdc++-v3/doc/html/manual/policy_data_structures.html +++ b/libstdc++-v3/doc/html/manual/policy_data_structures.html @@ -1,37 +1,9 @@ -Chapter 22. Policy-Based Data Structures
    Chapter 22. Policy-Based Data Structures
    Prev Part III.  + + +Chapter 22. Policy-Based Data Structures
    Chapter 22. Policy-Based Data Structures
    Prev Part III.  Extensions - Next

    Chapter 22. Policy-Based Data Structures

    Table of Contents

    Intro
    Performance Issues
    Associative
    Priority Que
    Goals
    Associative
    Policy Choices
    Underlying Data Structures
    Iterators
    Functional
    Priority Queues
    Policy Choices
    Underlying Data Structures
    Binary Heaps
    Using
    Prerequisites
    Organization
    Tutorial
    Basic Use
    +
    		 Next

    Chapter 22. Policy-Based Data Structures

    Table of Contents

    Intro
    Performance Issues
    Associative
    Priority Que
    Goals
    Associative
    Policy Choices
    Underlying Data Structures
    Iterators
    Functional
    Priority Queues
    Policy Choices
    Underlying Data Structures
    Binary Heaps
    Using
    Prerequisites
    Organization
    Tutorial
    Basic Use
    Configuring via Template Parameters
    Querying Container Attributes @@ -95,7 +67,7 @@ Text modify Down
    Observations
    Associative
    Priority_Queue
    Acknowledgments
    Bibliography -

    Intro

    +

    Intro

    This is a library of policy-based elementary data structures: associative containers and priority queues. It is designed for high-performance, flexibility, semantic safety, and conformance to @@ -103,7 +75,7 @@ std::tr1 (except for some points where it differs by design).

    -

    Performance Issues

    +

    Performance Issues

    An attempt is made to categorize the wide variety of possible container designs in terms of performance-impacting factors. These @@ -123,7 +95,7 @@

    Specific issues found while unraveling performance factors in the design of associative containers and priority queues follow. -

    Associative

    +

    Associative

    Associative containers depend on their composite policies to a very large extent. Implicitly hard-wiring policies can hamper their performance and limit their functionality. An efficient hash-based @@ -164,7 +136,7 @@ is a red-black tree, then splitting a reference to the container is exception-free; if it is an ordered-vector tree, exceptions can be thrown. -

    Priority Que

    +

    Priority Que

    Priority queues are useful when one needs to efficiently access a minimum (or maximum) value as the set of values changes.

    @@ -206,7 +178,7 @@ expense of more difference in the the kinds of operations that the underlying data structure can support. These differences pose a challenge when creating a uniform interface for priority queues. -

    Goals

    +

    Goals

    Many fine associative-container libraries were already written, most notably, the C++ standard's associative containers. Why then write another library? This section shows some possible @@ -217,8 +189,8 @@ only then adding hash-based containers, which are fundamentally different), did not standardize priority queues as containers, and (in our opinion) overloads the iterator concept. -

    Associative

    -

    Policy Choices

    +

    Associative

    +

    Policy Choices

    Associative containers require a relatively large number of policies to function efficiently in various settings. In some cases this is needed for making their common operations more @@ -279,7 +251,7 @@ these invariants, one must supply some policy that is aware of these changes. Without this, it would be better to use a linked list (in itself very efficient for these purposes). -

    Figure 22.1. Node Invariants

    Node Invariants

    Underlying Data Structures

    +

    Figure 22.1. Node Invariants

    Node Invariants

    Underlying Data Structures

    The standard C++ library contains associative containers based on red-black trees and collision-chaining hash tables. These are very useful, but they are not ideal for all types of @@ -287,7 +259,7 @@

    The figure below shows the different underlying data structures currently supported in this library. -

    Figure 22.2. Underlying Associative Data Structures

    Underlying Associative Data Structures

    +

    Figure 22.2. Underlying Associative Data Structures

    Underlying Associative Data Structures

    A shows a collision-chaining hash-table, B shows a probing hash-table, C shows a red-black tree, D shows a splay tree, E shows a tree based on an ordered vector(implicit in the order of the @@ -364,7 +336,7 @@ library iterators, for example) can ease generic manipulation of associative containers based on different underlying data structures. -

    Iterators

    +

    Iterators

    Iterators are centric to the design of the standard library containers, because of the container/algorithm/iterator decomposition that allows an algorithm to operate on a range @@ -389,7 +361,7 @@ "ds_gen.html#find_range">Design::Associative Containers::Data-Structure Genericity::Point-Type and Range-Type Methods. -

    Using Point Iterators for Range Operations

    +

    Using Point Iterators for Range Operations

    Suppose cntnr is some associative container, and say c is an object of type cntnr. Then what will be the outcome @@ -406,7 +378,7 @@ no guarantee that the elements traversed will coincide with the logical elements between 1 and 5, as in label B. -

    Figure 22.3. Range Iteration in Different Data Structures

    Node Invariants

    +

    Figure 22.3. Range Iteration in Different Data Structures

    Node Invariants

    In our opinion, this problem is not caused just because red-black trees are order preserving while collision-chaining hash tables are (generally) not - it @@ -427,7 +399,7 @@ Consequently, applying an algorithm to a sequence obtained from most containers may or may not make sense, but applying it to a sub-sequence of a self-organizing container does not. -

    Cost to Point Iterators to Enable Range Operations

    +

    Cost to Point Iterators to Enable Range Operations

    Suppose c is some collision-chaining hash-based container object, and one calls 

    c.find(3)

    @@ -457,11 +429,11 @@ list, as in the graphic below, label B. Here the iterators are as light as can be, but the hash-table's operations are more complicated. -

    Figure 22.4. Point Iteration in Hash Data Structures

    Point Iteration in Hash Data Structures

    +

    Figure 22.4. Point Iteration in Hash Data Structures

    Point Iteration in Hash Data Structures

    It should be noted that containers based on collision-chaining hash-tables are not the only ones with this type of behavior; many other self-organizing data structures display it as well. -

    Invalidation Guarantees

    Consider the following snippet:

    +
    Invalidation Guarantees

    Consider the following snippet:

     	      it = c.find(3);
 	      c.erase(5);

    @@ -473,7 +445,7 @@ container. The graphic below shows three cases: A1 and A2 show a red-black tree; B1 and B2 show a probing hash-table; C1 and C2 show a collision-chaining hash table. -

    Figure 22.5. Effect of erase in different underlying data structures

    Effect of erase in different underlying data structures

    1. +

      Figure 22.5. Effect of erase in different underlying data structures

      Effect of erase in different underlying data structures

      1. Erasing 5 from A1 yields A2. Clearly, an iterator to 3 can be de-referenced and incremented. The sequence of iterators changed, but in a way that is well-defined by the interface. @@ -495,7 +467,7 @@ to express whether it is valid or not. This is true also for insert. Again, the iterator concept seems overloaded. -

    Functional

    +

    Functional

    The design of the functional overlay to the underlying data structures differs slightly from some of the conventions used in @@ -506,7 +478,7 @@ rubric, the standard associative containers lack some useful methods, and provide other methods which would be better removed. -

    erase

    1. +

      erase

      1. Order-preserving standard associative containers provide the method 

        @@ -578,7 +550,7 @@
 		  is almost certain to do something
 		  different than erasing all elements whose keys are between 2
 		  and 5, and is likely to produce other undefined behavior.
-
      +

    split and join

    It is well-known that tree-based and trie-based container @@ -589,7 +561,7 @@ choices for tree-based container methods, especially, since as noted just before, they are efficient replacements for erasing sub-sequences. -

    +

    insert

    The standard associative containers provide methods of the form @@ -605,7 +577,7 @@ similar to constructors taking a range given by a pair of iterators; the constructors, however, are transactional, whereas the insert methods are not; this is possibly confusing. -

    +

    operator== and operator<=

    Associative containers are parametrized by policies allowing to @@ -625,7 +597,7 @@ equivalence; also, are two containers considered equivalent if they store the same values in different order? this is an arbitrary decision. -

    Priority Queues

    Policy Choices

    +

    Priority Queues

    Policy Choices

    Priority queues are containers that allow efficiently inserting values and accessing the maximal value (in the sense of the container's comparison functor). Their interface @@ -702,14 +674,14 @@ comparing the iterator returned by find to the iterator returned by end, and not by comparing a pointer returned by find to NULL. -

    Underlying Data Structures

    +

    Underlying Data Structures

    There are three main implementations of priority queues: the first employs a binary heap, typically one which uses a sequence; the second uses a tree (or forest of trees), which is typically less structured than an associative container's tree; the third simply uses an associative container. These are shown in the figure below with labels A1 and A2, B, and C. -

    Figure 22.6. Underlying Priority Queue Data Structures

    Underlying Priority Queue Data Structures

    +

    Figure 22.6. Underlying Priority Queue Data Structures

    Underlying Priority Queue Data Structures

    No single implementation can completely replace any of the others. Some have better push and pop amortized performance, some have @@ -724,7 +696,7 @@ important for priority queues, since the invalidation guarantees of one of the most useful data structures - binary heaps - is markedly different than those of most of the others. -

    Binary Heaps

    +

    Binary Heaps

    Binary heaps are one of the most useful underlying data structures for priority queues. They are very efficient in terms of memory (since they don't require per-value structure @@ -801,21 +773,21 @@ std::priority_queue, however, this will generally change the order of growth of the entire sequence of operations. -

    +

    Bibliography -

    [biblio.abrahams97exception] +

    [biblio.abrahams97exception] STL Exception Handling Contract - . 1997. + . 1997. Dave Abrahams . ISO SC22/WG21 - .

    [biblio.alexandrescu01modern] + .

    [biblio.alexandrescu01modern] Modern C++ Design: Generic Programming and Design Patterns Applied - . + . 2001 . Andrei @@ -823,10 +795,10 @@ Alexandrescu . Addison-Wesley Publishing Company - .

    [biblio.andrew04mtf] + .

    [biblio.andrew04mtf] MTF, Bit, and COMB: A Guide to Deterministic and Randomized Algorithms for the List Update Problem - . + . K. Andrew @@ -834,9 +806,9 @@ D. Gleich - .

    [biblio.austern00noset] + .

    [biblio.austern00noset] Why You Shouldn't Use set - and What You Should Use Instead - . + . April, 2000 . Matthew @@ -844,11 +816,11 @@ Austern . C++ Report - .

    [biblio.austern01htprop] + .

    [biblio.austern01htprop] A Proposal to Add Hashtables to the Standard Library - . + . 2001 . Matthew @@ -856,9 +828,9 @@ Austern . ISO SC22/WG21 - .

    [biblio.austern98segmentedit] + .

    [biblio.austern98segmentedit] Segmented iterators and hierarchical algorithms - . + . April, 1998 . Matthew @@ -866,31 +838,31 @@ Austern . Generic Programming - .

    [biblio.dawestimer] + .

    [biblio.dawestimer] Boost Timer Library - . + . Beeman Dawes . Boost - .

    [biblio.clearypool] + .

    [biblio.clearypool] Boost Pool Library - . + . Stephen Cleary . Boost - .

    [biblio.maddocktraits] + .

    [biblio.maddocktraits] Boost Type Traits Library - . + . Maddock John @@ -900,17 +872,17 @@ Cleary . Boost - .

    [biblio.brodal96priority] + .

    [biblio.brodal96priority] Worst-case efficient priority queues - . + . Gerth Stolting Brodal - .

    [biblio.bulkamayheweff] + .

    [biblio.bulkamayheweff] Efficient C++ Programming Techniques - . + . 1997 . D. @@ -922,9 +894,9 @@ Mayhew . Addison-Wesley Publishing Company - .

    [biblio.clrs2001] + .

    [biblio.clrs2001] Introduction to Algorithms, 2nd edition - . + . 2001 . T. H. @@ -944,9 +916,9 @@ Stein . MIT Press - .

    [biblio.dubhashi98neg] + .

    [biblio.dubhashi98neg] Balls and bins: A study in negative dependence - . + . 1998 . D. @@ -958,9 +930,9 @@ Ranjan . Random Structures and Algorithms 13 - .

    [biblio.fagin79extendible] + .

    [biblio.fagin79extendible] Extendible hashing - a fast access method for dynamic files - . + . 1979 . R. @@ -980,21 +952,21 @@ Strong . ACM Trans. Database Syst. 4 - .

    [biblio.filliatre2000ptset] + .

    [biblio.filliatre2000ptset] Ptset: Sets of integers implemented as Patricia trees - . + . 2000 . Jean-Christophe Filliatre - .

    [biblio.fredman86pairing] + .

    [biblio.fredman86pairing] The pairing heap: a new form of self-adjusting heap - . + . 1986 . M. L. @@ -1012,9 +984,9 @@ R. E. Tarjan - .

    [biblio.gof] + .

    [biblio.gof] Design Patterns - Elements of Reusable Object-Oriented Software - . + . 1995 . E. @@ -1034,9 +1006,9 @@ Vlissides . Addison-Wesley Publishing Company - .

    [biblio.garg86order] + .

    [biblio.garg86order] Order-preserving key transformations - . + . 1986 . A. K. @@ -1048,9 +1020,9 @@ Gotlieb . Trans. Database Syst. 11 - .

    [biblio.hyslop02making] + .

    [biblio.hyslop02making] Making a real hash of things - . + . May 2002 . J. @@ -1062,9 +1034,9 @@ Sutter . C++ Report - .

    [biblio.jossutis01stl] + .

    [biblio.jossutis01stl] The C++ Standard Library - A Tutorial and Reference - . + . 2001 . N. M. @@ -1072,11 +1044,11 @@ Jossutis . Addison-Wesley Publishing Company - .

    [biblio.kt99fat_heaps] + .

    [biblio.kt99fat_heaps] New Heap Data Structures - . + . 1999 . Haim @@ -1086,9 +1058,9 @@ Robert E. Tarjan - .

    [biblio.kleft00sets] + .

    [biblio.kleft00sets] Are Set Iterators Mutable or Immutable? - . + . October 2000 . Angelika @@ -1100,9 +1072,9 @@ Kleft . C/C++ Users Jornal - .

    [biblio.knuth98sorting] + .

    [biblio.knuth98sorting] The Art of Computer Programming - Sorting and Searching - . + . 1998 . D. E. @@ -1110,9 +1082,9 @@ Knuth . Addison-Wesley Publishing Company - .

    [biblio.liskov98data] + .

    [biblio.liskov98data] Data abstraction and hierarchy - . + . May 1998 . B. @@ -1120,9 +1092,9 @@ Liskov . SIGPLAN Notices 23 - .

    [biblio.litwin80lh] + .

    [biblio.litwin80lh] Linear hashing: A new tool for file and table addressing - . + . June 1980 . W. @@ -1130,19 +1102,19 @@ Litwin . Proceedings of International Conference on Very Large Data Bases - .

    [biblio.maverik_lowerbounds] + .

    [biblio.maverik_lowerbounds] Deamortization - Part 2: Binomial Heaps - . + . 2005 . Maverik Woo - .

    [biblio.meyers96more] + .

    [biblio.meyers96more] More Effective C++: 35 New Ways to Improve Your Programs and Designs - . + . 1996 . Scott @@ -1150,9 +1122,9 @@ Meyers . Addison-Wesley Publishing Company - .

    [biblio.meyers00nonmember] + .

    [biblio.meyers00nonmember] How Non-Member Functions Improve Encapsulation - . + . 2000 . Scott @@ -1160,9 +1132,9 @@ Meyers . C/C++ Users Journal - .

    [biblio.meyers01stl] + .

    [biblio.meyers01stl] Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library - . + . 2001 . Scott @@ -1170,9 +1142,9 @@ Meyers . Addison-Wesley Publishing Company - .

    [biblio.meyers02both] + .

    [biblio.meyers02both] Class Template, Member Template - or Both? - . + . 2003 . Scott @@ -1180,9 +1152,9 @@ Meyers . C/C++ Users Journal - .

    [biblio.motwani95random] + .

    [biblio.motwani95random] Randomized Algorithms - . + . 2003 . R. @@ -1194,23 +1166,23 @@ Raghavan . Cambridge University Press - .

    [biblio.mscom] + .

    [biblio.mscom] COM: Component Model Object Technologies - . + . Microsoft - .

    [biblio.musser95rationale] + .

    [biblio.musser95rationale] Rationale for Adding Hash Tables to the C++ Standard Template Library - . + . 1995 . David R. Musser - .

    [biblio.musser96stltutorial] + .

    [biblio.musser96stltutorial] STL Tutorial and Reference Guide - . + . 1996 . David R. @@ -1222,10 +1194,10 @@ Saini . Addison-Wesley Publishing Company - .

    [biblio.nelson96stlpq] + .

    [biblio.nelson96stlpq] Priority Queues and the STL - . + . January 1996 . Mark @@ -1233,9 +1205,9 @@ Nelson . Dr. Dobbs Journal - .

    [biblio.okasaki98mereable] + .

    [biblio.okasaki98mereable] Fast mergeable integer maps - . + . September 1998 . C. @@ -1247,23 +1219,23 @@ Gill . In Workshop on ML - .

    [biblio.sgi_stl] + .

    [biblio.sgi_stl] Standard Template Library Programmer's Guide - . + . Matt Austern . SGI - .

    [biblio.select_man] + .

    [biblio.select_man] select - .

    [biblio.sleator84amortized] + .

    [biblio.sleator84amortized] Amortized Efficiency of List Update Problems - . + . 1984 . D. D. @@ -1275,9 +1247,9 @@ Tarjan . ACM Symposium on Theory of Computing - .

    [biblio.sleator85self] + .

    [biblio.sleator85self] Self-Adjusting Binary Search Trees - . + . 1985 . D. D. @@ -1289,9 +1261,9 @@ Tarjan . ACM Symposium on Theory of Computing - .

    [biblio.stepanov94standard] + .

    [biblio.stepanov94standard] The Standard Template Library - . + . 1984 . A. A. @@ -1301,9 +1273,9 @@ M. Lee - .

    [biblio.stroustrup97cpp] + .

    [biblio.stroustrup97cpp] The C++ Programming Langugage - . + . 1997 . Bjarne @@ -1311,9 +1283,9 @@ Stroustrup . Addison-Wesley Publishing Company - .

    [biblio.vandevoorde2002cpptemplates] + .

    [biblio.vandevoorde2002cpptemplates] C++ Templates: The Complete Guide - . + . 2002 . D. @@ -1325,11 +1297,11 @@ Josuttis . Addison-Wesley Publishing Company - .

    [biblio.wickland96thirty] + .

    [biblio.wickland96thirty] Thirty Years Among the Dead - . + . 1996 . C. A. @@ -1337,4 +1309,4 @@ Wickland . National Psychological Institute - .

    Prev Up Next
    Implementation Home Using
    + .

    Prev Up Next
    Implementation Home Using
    diff --git a/libstdc++-v3/doc/html/manual/policy_data_structures_biblio.html b/libstdc++-v3/doc/html/manual/policy_data_structures_biblio.html index 0309961a8a9..9676af805b0 100644 --- a/libstdc++-v3/doc/html/manual/policy_data_structures_biblio.html +++ b/libstdc++-v3/doc/html/manual/policy_data_structures_biblio.html @@ -1,34 +1,6 @@ -Acknowledgments
    Acknowledgments
    Prev Chapter 22. Policy-Based Data Structures Next

    Acknowledgments

    + + +Acknowledgments

    Acknowledgments
    Prev Chapter 22. Policy-Based Data Structures Next

    Acknowledgments

    Written by Ami Tavory and Vladimir Dreizin (IBM Haifa Research Laboratories), and Benjamin Kosnik (Red Hat).

    @@ -54,4 +26,4 @@ attributing to him any flaws in the design or implementation of the library).

    We would like to thank Matt Austern for the suggestion to - include tries.

    Prev Up Next
    Testing Home Chapter 23. HP/SGI Extensions
    + include tries.

    Prev Up Next
    Testing Home Chapter 23. HP/SGI Extensions
    diff --git a/libstdc++-v3/doc/html/manual/policy_data_structures_design.html b/libstdc++-v3/doc/html/manual/policy_data_structures_design.html index 823920176cd..e711170a373 100644 --- a/libstdc++-v3/doc/html/manual/policy_data_structures_design.html +++ b/libstdc++-v3/doc/html/manual/policy_data_structures_design.html @@ -1,34 +1,6 @@ -Design
    Design
    Prev Chapter 22. Policy-Based Data Structures Next

    Design

    Concepts

    Null Policy Classes

    + + +Design

    Design
    Prev Chapter 22. Policy-Based Data Structures Next

    Design

    Concepts

    Null Policy Classes

    Associative containers are typically parametrized by various policies. For example, a hash-based associative container is parametrized by a hash-functor, transforming each key into an @@ -55,7 +27,7 @@ places simplifications are made possible with this technique include node updates in tree and trie data structures, and hash and probe functions for hash data structures. -

    Map and Set Semantics

    +

    Map and Set Semantics

    Distinguishing Between Maps and Sets

    Anyone familiar with the standard knows that there are four kinds @@ -121,7 +93,7 @@

    When one uses a "multimap," one should choose with care the type of container used for secondary keys. -

    Alternatives to std::multiset and std::multimap

    +

    Alternatives to std::multiset and std::multimap

    Brace onself: this library does not contain containers like std::multimap or std::multiset. Instead, these data @@ -199,7 +171,7 @@ naturally; collision-chaining hash tables (label B) store equivalent-key values in the same bucket, the bucket can be arranged so that equivalent-key values are consecutive. -

    Figure 22.8. Non-unique Mapping Standard Containers

    Non-unique Mapping Standard Containers

    +

    Figure 22.8. Non-unique Mapping Standard Containers

    Non-unique Mapping Standard Containers

    Put differently, the standards' non-unique mapping associative-containers are associative containers that map primary keys to linked lists that are embedded into the @@ -207,10 +179,10 @@ containers from the first graphic above, this time with the embedded linked lists of the grayed nodes marked explicitly. -

    Figure 22.9.  +

    Figure 22.9.  Effect of embedded lists in std::multimap -

    Effect of embedded lists in std::multimap

    +

    Effect of embedded lists in std::multimap

    These embedded linked lists have several disadvantages.

    1. The underlying data structure embeds the linked lists @@ -281,7 +253,7 @@ first graphic above. Labels A and B, respectively. Each shaded box represents some size-type or secondary associative-container. -

      Figure 22.10. Non-unique Mapping Containers

      Non-unique Mapping Containers

      +

      Figure 22.10. Non-unique Mapping Containers

      Non-unique Mapping Containers

      In the first example above, then, one would use an associative container mapping each user to an associative container which maps each application id to a start time (see @@ -293,7 +265,7 @@

      See the discussion in list-based container types for containers especially suited as secondary associative-containers. -

    Iterator Semantics

    Point and Range Iterators

    +

    Iterator Semantics

    Point and Range Iterators

    Iterator concepts are bifurcated in this design, and are comprised of point-type and range-type iteration.

    @@ -314,7 +286,7 @@ implementation, including that of C++ standard library components), but in this design, it is made explicit. They are distinct types. -

    Distinguishing Point and Range Iterators

    When using this library, is necessary to differentiate +

    Distinguishing Point and Range Iterators

    When using this library, is necessary to differentiate between two types of methods and iterators: point-type methods and iterators, and range-type methods and iterators. Each associative container's interface includes the methods:

    @@ -334,7 +306,7 @@
 	shows invariants for order-preserving containers: point-type
 	iterators are synonymous with range-type iterators.
 	Orthogonally,  Cshows invariants for "set"
-	containers: iterators are synonymous with const iterators.
    Figure 22.11. Point Iterator Hierarchy
    Point Iterator Hierarchy

    Note that point-type iterators in self-organizing containers
+	containers: iterators are synonymous with const iterators.
    Figure 22.11. Point Iterator Hierarchy
    Point Iterator Hierarchy

    Note that point-type iterators in self-organizing containers
 	(hash-based associative containers) lack movement
 	operators, such as operator++ - in fact, this
 	is the reason why this library differentiates from the standard C++ librarys
@@ -350,7 +322,7 @@
 	a concept in C++ standardese, which is the category of iterators
 	with no movement capabilities.) All other standard C++ library
 	tags, such as forward_iterator_tag retain their
-	common use.
    Invalidation Guarantees

    + common use.

    Invalidation Guarantees

    If one manipulates a container object, then iterators previously obtained from it can be invalidated. In some cases a previously-obtained iterator cannot be de-referenced; in other cases, @@ -373,7 +345,7 @@ to the question of whether point-type iterators and range-type iterators are valid. The graphic below shows tags corresponding to different types of invalidation guarantees. -

    Figure 22.12. Invalidation Guarantee Tags Hierarchy

    Invalidation Guarantee Tags Hierarchy

    • +

      Figure 22.12. Invalidation Guarantee Tags Hierarchy

      Invalidation Guarantee Tags Hierarchy

      • basic_invalidation_guarantee corresponds to a basic guarantee that a point-type iterator, a found pointer, or a found reference, remains valid as long @@ -404,7 +376,7 @@ our opinion, an invalidation-guarantee hierarchy would solve these problems in all container types - not just associative containers. -

    Genericity

    +

    Genericity

    The design attempts to address the following problem of data-structure genericity. When writing a function manipulating a generic container object, what is the behavior of the object? @@ -446,7 +418,7 @@ capabilities? What is the relationship between two different data structures, if anything?

    The remainder of this section explains these issues in - detail.

    Tag

    + detail.

    Tag

    Tags are very useful for manipulating generic types. For example, if It is an iterator class, then typename It::iterator_category or typename @@ -457,11 +429,11 @@

    This library contains a container tag hierarchy corresponding to the diagram below. -

    Figure 22.13. Container Tag Hierarchy

    Container Tag Hierarchy

    +

    Figure 22.13. Container Tag Hierarchy

    Container Tag Hierarchy

    Given any container Cntnr, the tag of the underlying data structure can be found via typename Cntnr::container_category. -

    Traits

    Additionally, a traits mechanism can be used to query a +

    Traits

    Additionally, a traits mechanism can be used to query a container type for its attributes. Given any container Cntnr, then <Cntnr> is a traits class identifying the properties of the @@ -481,7 +453,7 @@ otherwise container_traits<Cntnr>::split_join_can_throw will yield a compilation error. (This is somewhat similar to a compile-time version of the COM model). -

    By Container

    hash

    Interface

    +

    By Container

    hash

    Interface

    The collision-chaining hash-based container has the following declaration.

     	  template<
@@ -515,9 +487,9 @@

    The parameters are identical to those of the collision-chaining container, except for the following.

    1. Comb_Probe_Fn describes how to transform a probe sequence into a sequence of positions within the table.

    2. Probe_Fn describes a probe sequence policy.

    Some of the default template values depend on the values of - other parameters, and are explained below.

    Details
    Hash Policies
    General

    Following is an explanation of some functions which hashing - involves. The graphic below illustrates the discussion.

    Figure 22.14. Hash functions, ranged-hash functions, and - range-hashing functions

    Hash functions, ranged-hash functions, and range-hashing functions

    Let U be a domain (e.g., the integers, or the + other parameters, and are explained below.

    Details
    Hash Policies
    General

    Following is an explanation of some functions which hashing + involves. The graphic below illustrates the discussion.

    Figure 22.14. Hash functions, ranged-hash functions, and + range-hashing functions

    Hash functions, ranged-hash functions, and range-hashing functions

    Let U be a domain (e.g., the integers, or the strings of 3 characters). A hash-table algorithm needs to map elements of U "uniformly" into the range [0,..., m - 1] (where m is a non-negative integral value, and @@ -533,9 +505,9 @@ Z+,

    which maps a non-negative hash value, and a non-negative range upper-bound into a non-negative integral in the range between 0 (inclusive) and the range upper bound (exclusive), - i.e., for any r in Z+,

    0 ≤ g(r, m) ≤ m - 1

    The resulting ranged-hash function, is

    Equation 22.1. Ranged Hash Function

    + i.e., for any r in Z+,

    0 ≤ g(r, m) ≤ m - 1

    The resulting ranged-hash function, is

    Equation 22.1. Ranged Hash Function

    f(u , m) = g(h(u), m) -

    From the above, it is obvious that given g and +


    From the above, it is obvious that given g and h, f can always be composed (however the converse is not true). The standard's hash-based containers allow specifying a hash function, and use a hard-wired range-hashing function; @@ -551,11 +523,11 @@ probe function transforming the hash value into a sequence of hash values, and a range-hashing function transforming the sequence of hash values into a sequence of - positions.

    Range Hashing

    Some common choices for range-hashing functions are the + positions.

    Range Hashing

    Some common choices for range-hashing functions are the division, multiplication, and middle-square methods ([biblio.knuth98sorting]), defined - as

    Equation 22.2. Range-Hashing, Division Method

    + as

    Equation 22.2. Range-Hashing, Division Method

    g(r, m) = r mod m -

    g(r, m) = ⌈ u/v ( a r mod v ) ⌉

    and

    g(r, m) = ⌈ u/v ( r2 mod v ) ⌉

    respectively, for some positive integrals u and +


    g(r, m) = ⌈ u/v ( a r mod v ) ⌉

    and

    g(r, m) = ⌈ u/v ( r2 mod v ) ⌉

    respectively, for some positive integrals u and v (typically powers of 2), and some a. Each of these range-hashing functions works best for some different setting.

    The division method (see above) is a @@ -564,12 +536,12 @@ implement using the low level % (modulo) operation (for any m), or the low level & (bit-mask) operation (for the case where - m is a power of 2), i.e.,

    Equation 22.3. Division via Prime Modulo

    + m is a power of 2), i.e.,

    Equation 22.3. Division via Prime Modulo

    g(r, m) = r % m -

    and

    Equation 22.4. Division via Bit Mask

    +

    and

    Equation 22.4. Division via Bit Mask

    g(r, m) = r & m - 1, (with m = 2k for some k) -

    respectively.

    The % (modulo) implementation has the advantage that for +


    respectively.

    The % (modulo) implementation has the advantage that for m a prime far from a power of 2, g(r, m) is affected by all the bits of r (minimizing the chance of collision). It has the disadvantage of using the costly modulo @@ -578,7 +550,7 @@ relying on the fast bit-wise and operation. It has the disadvantage that for g(r, m) is affected only by the low order bits of r. This method is hard-wired into - Dinkumware's implementation.

    Ranged Hash

    In cases it is beneficial to allow the + Dinkumware's implementation.

    Ranged Hash

    In cases it is beneficial to allow the client to directly specify a ranged-hash hash function. It is true, that the writer of the ranged-hash function cannot rely on the values of m having specific numerical properties @@ -592,24 +564,24 @@ s = [ s0,..., st - 1]

    be a string of t characters, each of which is from domain S. Consider the following ranged-hash - function:

    Equation 22.5.  + function:

    Equation 22.5.  A Standard String Hash Function -

    +

    f1(s, m) = ∑ i = 0t - 1 si ai mod m -

    where a is some non-negative integral value. This is +


    where a is some non-negative integral value. This is the standard string-hashing function used in SGI's implementation (with a = 5). Its advantage is that it takes into account all of the characters of the string.

    Now assume that s is the string representation of a of a long DNA sequence (and so S = {'A', 'C', 'G', 'T'}). In this case, scanning the entire string might be prohibitively expensive. A possible alternative might be to use - only the first k characters of the string, where

    |S|k ≥ m ,

    i.e., using the hash function

    Equation 22.6.  + only the first k characters of the string, where

    |S|k ≥ m ,

    i.e., using the hash function

    Equation 22.6.  Only k String DNA Hash -

    +

    f2(s, m) = ∑ i = 0k - 1 si ai mod m -

    requiring scanning over only

    k = log4( m )

    characters.

    Other more elaborate hash-functions might scan k +


    requiring scanning over only

    k = log4( m )

    characters.

    Other more elaborate hash-functions might scan k characters starting at a random position (determined at each resize), or scanning k random positions (determined at each resize), i.e., using

    f3(s, m) = ∑ i = @@ -618,12 +590,12 @@ 1 sri ari mod m ,

    respectively, for r0,..., rk-1 each in the (inclusive) range [0,...,t-1].

    It should be noted that the above functions cannot be - decomposed as per a ranged hash composed of hash and range hashing.

    Implementation

    This sub-subsection describes the implementation of + decomposed as per a ranged hash composed of hash and range hashing.

    Implementation

    This sub-subsection describes the implementation of the above in this library. It first explains range-hashing functions in collision-chaining tables, then ranged-hash functions in collision-chaining tables, then probing-based tables, and finally lists the relevant classes in this - library.

    + library.

    Range-Hashing and Ranged-Hashes in Collision-Chaining Tables

    cc_hash_table is parametrized by Hash_Fn and Comb_Hash_Fn, a @@ -635,12 +607,12 @@ the container transforms the key into a non-negative integral using the hash functor (points B and C), and transforms the result into a position using the combining functor (points D - and E).

    Figure 22.15. Insert hash sequence diagram

    Insert hash sequence diagram

    If cc_hash_table's + and E).

    Figure 22.15. Insert hash sequence diagram

    Insert hash sequence diagram

    If cc_hash_table's hash-functor, Hash_Fn is instantiated by null_type , then Comb_Hash_Fn is taken to be a ranged-hash function. The graphic below shows an insert sequence diagram. The user inserts an element (point A), the container transforms the key into a position using the combining functor - (points B and C).

    Figure 22.16. Insert hash sequence diagram with a null policy

    Insert hash sequence diagram with a null policy

    + (points B and C).

    Figure 22.16. Insert hash sequence diagram with a null policy

    Insert hash sequence diagram with a null policy

    Probing tables

    gp_hash_table is parametrized by Hash_Fn, Probe_Fn, @@ -652,7 +624,7 @@ functor, Probe_Fn is a functor for offsets from a hash value, and Comb_Probe_Fn transforms a probe sequence into a sequence of positions within - the table.

    + the table.

    Pre-Defined Policies

    This library contains some pre-defined classes implementing range-hashing and probing functions:

    1. direct_mask_range_hashing @@ -663,14 +635,14 @@ a linear probe and a quadratic probe function, respectively.

    The graphic below shows the relationships. -

    Figure 22.17. Hash policy class diagram

    Hash policy class diagram

    Resize Policies
    General

    Hash-tables, as opposed to trees, do not naturally grow or +

    Figure 22.17. Hash policy class diagram

    Hash policy class diagram

    Resize Policies
    General

    Hash-tables, as opposed to trees, do not naturally grow or shrink. It is necessary to specify policies to determine how and when a hash table should change its size. Usually, resize policies can be decomposed into orthogonal policies:

    1. A size policy indicating how a hash table should grow (e.g., it should multiply by powers of 2).

    2. A trigger policy indicating when a hash table should grow (e.g., a load factor is - exceeded).

    Size Policies

    Size policies determine how a hash table changes size. These + exceeded).

    Size Policies

    Size policies determine how a hash table changes size. These policies are simple, and there are relatively few sensible options. An exponential-size policy (with the initial size and growth factors both powers of 2) works well with a mask-based @@ -678,7 +650,7 @@ hard-wired policy used by Dinkumware. A prime-list based policy works well with a modulo-prime range hashing function and is the hard-wired policy used by SGI's - implementation.

    Trigger Policies

    Trigger policies determine when a hash table changes size. + implementation.

    Trigger Policies

    Trigger policies determine when a hash table changes size. Following is a description of two policies: load-check policies, and collision-check policies.

    Load-check policies are straightforward. The user specifies two factors, Αmin and @@ -696,14 +668,14 @@ and some load factor be denoted by Α. We would like to calculate the minimal length of k, such that if there were Α m elements in the hash table, a probe sequence of length k would - be found with probability at most 1/m.

    Figure 22.18. Balls and bins

    Balls and bins

    Denote the probability that a probe sequence of length + be found with probability at most 1/m.

    Figure 22.18. Balls and bins

    Balls and bins

    Denote the probability that a probe sequence of length k appears in bin i by pi, the length of the probe sequence of bin i by - li, and assume uniform distribution. Then

    Equation 22.7.  + li, and assume uniform distribution. Then

    Equation 22.7.  Probability of Probe Sequence of Length k -

    +

    p1 = -

    P(l1 ≥ k) =

    +


    P(l1 ≥ k) =

    P(l1 ≥ α ( 1 + k / α - 1) ≤ (a)

    e ^ ( - ( α ( k / α - 1 )2 ) /2) @@ -713,11 +685,11 @@ li are negatively-dependent ([biblio.dubhashi98neg]) . Let - I(.) denote the indicator function. Then

    Equation 22.8.  + I(.) denote the indicator function. Then

    Equation 22.8.  Probability Probe Sequence in Some Bin -

    +

    P( existsi li ≥ k ) = -

    P ( ∑ i = 1m +


    P ( ∑ i = 1m I(li ≥ k) ≥ 1 ) =

    P ( ∑ i = 1m I ( li ≥ k ) ≥ m p1 ( 1 + 1 / (m p1) - 1 ) ) ≤ (a)

    e ^ ( ( - m p1 ( 1 / (m p1) @@ -725,11 +697,11 @@ be applied to negatively-dependent variables ([biblio.dubhashi98neg]). Inserting the first probability equation into the second one, and equating with 1/m, we obtain

    k ~ √ ( 2 α ln 2 m ln(m) ) - ) .

    Implementation

    This sub-subsection describes the implementation of the + ) .

    Implementation

    This sub-subsection describes the implementation of the above in this library. It first describes resize policies and their decomposition into trigger and size policies, then describes pre-defined classes, and finally discusses controlled - access the policies' internals.

    Decomposition

    Each hash-based container is parametrized by a + access the policies' internals.

    Decomposition

    Each hash-based container is parametrized by a Resize_Policy parameter; the container derives publicly from Resize_Policy. For example:

    @@ -752,7 +724,7 @@
 	      a resize is needed, and if so, what is the new size (points D
 	      to G); following the resize, it notifies the policy that a
 	      resize has completed (point H); finally, the element is
-	      inserted, and the policy notified (point I).
    Figure 22.19. Insert resize sequence diagram
    Insert resize sequence diagram

    In practice, a resize policy can be usually orthogonally
+	      inserted, and the policy notified (point I).
    Figure 22.19. Insert resize sequence diagram
    Insert resize sequence diagram

    In practice, a resize policy can be usually orthogonally
 	      decomposed to a size policy and a trigger policy. Consequently,
 	      the library contains a single class for instantiating a resize
 	      policy: hash_standard_resize_policy
@@ -761,9 +733,9 @@
 	      both, and acts as a standard delegate ([biblio.gof])
 	      to these policies.
    The two graphics immediately below show sequence diagrams
 	      illustrating the interaction between the standard resize policy
-	      and its trigger and size policies, respectively.
    Figure 22.20. Standard resize policy trigger sequence
-		diagram
    Standard resize policy trigger sequence diagram

    Figure 22.21. Standard resize policy size sequence
-		diagram
    Standard resize policy size sequence diagram

    Predefined Policies

    The library includes the following + and its trigger and size policies, respectively.

    Figure 22.20. Standard resize policy trigger sequence + diagram

    Standard resize policy trigger sequence diagram

    Figure 22.21. Standard resize policy size sequence + diagram

    Standard resize policy size sequence diagram

    Predefined Policies

    The library includes the following instantiations of size and trigger policies:

    1. hash_load_check_resize_trigger implements a load check trigger policy.

    2. cc_hash_max_collision_check_resize_trigger implements a collision check trigger policy.

    3. hash_exponential_size_policy @@ -781,7 +753,7 @@ instantiated by hash_load_check_resize_trigger, or cc_hash_max_collision_check_resize_trigger; Size_Policy is instantiated by hash_exponential_size_policy, - or hash_prime_size_policy.

    Controling Access to Internals

    There are cases where (controlled) access to resize + or hash_prime_size_policy.

    Controling Access to Internals

    There are cases where (controlled) access to resize policies' internals is beneficial. E.g., it is sometimes useful to query a hash-table for the table's actual size (as opposed to its size() - the number of values it @@ -826,11 +798,11 @@

    which resizes the container. Implementations of Resize_Policy can export public methods for resizing the container externally; these methods internally call - do_resize to resize the table.

    Policy Interactions

    + do_resize to resize the table.

    Policy Interactions

    Hash-tables are unfortunately especially susceptible to choice of policies. One of the more complicated aspects of this is that poor combinations of good policies can form a poor - container. Following are some considerations.

    probe/size/trigger

    Some combinations do not work well for probing containers. + container. Following are some considerations.

    probe/size/trigger

    Some combinations do not work well for probing containers. For example, combining a quadratic probe policy with an exponential size policy can yield a poor container: when an element is inserted, a trigger policy might decide that there @@ -839,13 +811,13 @@ the unused entries.

    Unfortunately, this library cannot detect such problems at compilation (they are halting reducible). It therefore defines an exception class insert_error to throw an - exception in this case.

    hash/trigger

    Some trigger policies are especially susceptible to poor + exception in this case.

    hash/trigger

    Some trigger policies are especially susceptible to poor hash functions. Suppose, as an extreme case, that the hash function transforms each key to the same hash value. After some inserts, a collision detecting policy will always indicate that the container needs to grow.

    The library, therefore, by design, limits each operation to one resize. For each insert, for example, it queries - only once whether a resize is needed.

    equivalence functors/storing hash values/hash

    cc_hash_table and + only once whether a resize is needed.

    equivalence functors/storing hash values/hash

    cc_hash_table and gp_hash_table are parametrized by an equivalence functor and by a Store_Hash parameter. If the latter parameter is @@ -856,7 +828,7 @@ collisions for other types.

    If a ranged-hash function or ranged probe function is directly supplied, however, then it makes no sense to store the hash value with each entry. This library's container will - fail at compilation, by design, if this is attempted.

    size/load-check trigger

    Assume a size policy issues an increasing sequence of sizes + fail at compilation, by design, if this is attempted.

    size/load-check trigger

    Assume a size policy issues an increasing sequence of sizes a, a q, a q1, a q2, ... For example, an exponential size policy might issue the sequence of sizes 8, 16, 32, 64, ...

    If a load-check trigger policy is used, with loads @@ -864,7 +836,7 @@ respectively, then it is a good idea to have:

    1. αmax ~ 1 / q

    2. αmin < 1 / (2 q)

    This will ensure that the amortized hash cost of each modifying operation is at most approximately 3.

    αmin ~ αmax is, in any case, a bad choice, and αmin > - α max is horrendous.

    tree

    Interface

    The tree-based container has the following declaration:

    +	    α max is horrendous.

    tree

    Interface

    The tree-based container has the following declaration:

     	  template<
 	  typename Key,
 	  typename Mapped,
@@ -889,7 +861,7 @@
 	Note that containers based on the former two contain more types
 	and methods than the latter (e.g.,
 	reverse_iterator and rbegin), and different
-	exception and invalidation guarantees.
    Details
    Node Invariants

    Consider the two trees in the graphic below, labels A and B. The first + exception and invalidation guarantees.

    Details
    Node Invariants

    Consider the two trees in the graphic below, labels A and B. The first is a tree of floats; the second is a tree of pairs, each signifying a geometric line interval. Each element in a tree is refered to as a node of the tree. Of course, each of these trees can support the usual queries: the first can easily @@ -905,7 +877,7 @@ each node, and maintains node invariants (see [biblio.clrs2001].) The first stores in each node the size of the sub-tree rooted at the node; the second stores at each node the maximal endpoint of the - intervals at the sub-tree rooted at the node.

    Figure 22.22. Tree node invariants

    Tree node invariants

    Supporting such trees is difficult for a number of + intervals at the sub-tree rooted at the node.

    Figure 22.22. Tree node invariants

    Tree node invariants

    Supporting such trees is difficult for a number of reasons:

    1. There must be a way to specify what a node's metadata should be (if any).

    2. Various operations can invalidate node invariants. The graphic below shows how a right rotation, @@ -919,9 +891,9 @@ metadata.

    3. It is not feasible to know in advance which methods trees can support. Besides the usual find method, the first tree can support a find_by_order method, while - the second can support an overlaps method.

    Figure 22.23. Tree node invalidation

    Tree node invalidation

    These problems are solved by a combination of two means: + the second can support an overlaps method.

    Figure 22.23. Tree node invalidation

    Tree node invalidation

    These problems are solved by a combination of two means: node iterators, and template-template node updater - parameters.

    Node Iterators

    Each tree-based container defines two additional iterator + parameters.

    Node Iterators

    Each tree-based container defines two additional iterator types, const_node_iterator and node_iterator. These iterators allow descending from a node to one of its @@ -941,14 +913,14 @@ node_end();

    The first pairs return node iterators corresponding to the root node of the tree; the latter pair returns node iterators - corresponding to a just-after-leaf node.

    Node Updator

    The tree-based containers are parametrized by a + corresponding to a just-after-leaf node.

    Node Updator

    The tree-based containers are parametrized by a Node_Update template-template parameter. A tree-based container instantiates Node_Update to some node_update class, and publicly subclasses node_update. The graphic below shows this scheme, as well as some predefined policies (which are explained - below).

    Figure 22.24. A tree and its update policy

    A tree and its update policy

    node_update (an instantiation of + below).

    Figure 22.24. A tree and its update policy

    A tree and its update policy

    node_update (an instantiation of Node_Update) must define metadata_type as the type of metadata it requires. For order statistics, e.g., metadata_type might be size_t. @@ -967,7 +939,7 @@ nd_it. For example, say node x in the graphic below label A has an invalid invariant, but its' children, y and z have valid invariants. After the invocation, all three - nodes should have valid invariants, as in label B.

    Figure 22.25. Restoring node invariants

    Restoring node invariants

    When a tree operation might invalidate some node invariant, + nodes should have valid invariants, as in label B.

    Figure 22.25. Restoring node invariants

    Restoring node invariants

    When a tree operation might invalidate some node invariant, it invokes this method in its node_update base to restore the invariant. For example, the graphic below shows an insert operation (point A); the tree performs some @@ -975,7 +947,7 @@ C, and D). (It is well known that any insert, erase, split or join, can restore all node invariants by a small number of node invariant updates ([biblio.clrs2001]) - .

    Figure 22.26. Insert update sequence

    Insert update sequence

    To complete the description of the scheme, three questions + .

    Figure 22.26. Insert update sequence

    Insert update sequence

    To complete the description of the scheme, three questions need to be answered:

    1. How can a tree which supports order statistics define a method such as find_by_order?

    2. How can the node updater base access methods of the tree?

    3. How can the following cyclic dependency be resolved? @@ -1017,9 +989,9 @@ node's metadata (this is halting reducible). In the graphic below, assume the shaded node is inserted. The tree would have to traverse the useless path shown to the root, applying - redundant updates all the way.

    Figure 22.27. Useless update path

    Useless update path

    A null policy class, null_node_update + redundant updates all the way.

    Figure 22.27. Useless update path

    Useless update path

    A null policy class, null_node_update solves both these problems. The tree detects that node - invariants are irrelevant, and defines all accordingly.

    Split and Join

    Tree-based containers support split and join methods. + invariants are irrelevant, and defines all accordingly.

    Split and Join

    Tree-based containers support split and join methods. It is possible to split a tree so that it passes all nodes with keys larger than a given key to a different tree. These methods have the following advantages over the @@ -1029,7 +1001,7 @@ trees are split and joined at linear complexity. The alternatives have super-linear complexity.

  • Aside from orders of growth, these operations perform few allocations and de-allocations. For red-black trees, allocations are not performed, - and the methods are exception-free.

    • Trie

    Interface

    The trie-based container has the following declaration:

    +	    and the methods are exception-free.

    Trie

    Interface

    The trie-based container has the following declaration:

     	  template<typename Key,
 	  typename Mapped,
 	  typename Cmp_Fn = std::less<Key>,
@@ -1063,7 +1035,7 @@
 	  complexity and size).
  • It works well for common-prefix keys.
  • It can support efficiently queries such as which
 	  keys match a certain prefix. This is sometimes useful in file
 	  systems and routers, and for "type-ahead" aka predictive text matching
-	  on mobile devices.
    • Details
    Element Access Traits

    A trie inherently views its keys as sequences of elements. + on mobile devices.

    Details
    Element Access Traits

    A trie inherently views its keys as sequences of elements. For example, a trie can view a string as a sequence of characters. A trie needs to map each of n elements to a number in {0, n - 1}. For example, a trie can map a @@ -1100,7 +1072,7 @@ sub-tree with leafs "a" and "as". The maximal common prefix is "a". The internal node contains, consequently, to const iterators, one pointing to 'a', and the other to - 's'.

    Figure 22.28. A PATRICIA trie

    A PATRICIA trie

    Node Invariants

    Trie-based containers support node invariants, as do + 's'.

    Figure 22.28. A PATRICIA trie

    A PATRICIA trie

    Node Invariants

    Trie-based containers support node invariants, as do tree-based containers. There are two minor differences, though, which, unfortunately, thwart sharing them sharing the same node-updating policies:

    1. A trie's Node_Update template-template @@ -1109,15 +1081,15 @@ parametrized by Cmp_Fn.

    2. Tree-based containers store values in all nodes, while trie-based containers (at least in this implementation) store values in leafs.

    The graphic below shows the scheme, as well as some predefined - policies (which are explained below).

    Figure 22.29. A trie and its update policy

    A trie and its update policy

    This library offers the following pre-defined trie node + policies (which are explained below).

    Figure 22.29. A trie and its update policy

    A trie and its update policy

    This library offers the following pre-defined trie node updating policies:

    1. trie_order_statistics_node_update supports order statistics.

    2. trie_prefix_search_node_update supports searching for ranges that match a given prefix.

    3. null_node_update - is the null node updater.

    Split and Join

    Trie-based containers support split and join methods; the + is the null node updater.

    Split and Join

    Trie-based containers support split and join methods; the rationale is equal to that of tree-based containers supporting - these methods.

    List

    Interface

    The list-based container has the following declaration:

    +	  these methods.

    List

    Interface

    The list-based container has the following declaration:

     	  template<typename Key,
 	  typename Mapped,
 	  typename Eq_Fn = std::equal_to<Key>,
@@ -1152,12 +1124,12 @@
 	useful manner? Remarkably, many on-line competitive
 	algorithms exist for reordering lists to reflect access
 	prediction. (See [biblio.motwani95random] and [biblio.andrew04mtf]).
-
    Details

    -

    Underlying Data Structure

    The graphic below shows a +

    Details

    +

    Underlying Data Structure

    The graphic below shows a simple list of integer keys. If we search for the integer 6, we are paying an overhead: the link with key 6 is only the fifth link; if it were the first link, it could be accessed - faster.

    Figure 22.30. A simple list

    A simple list

    List-update algorithms reorder lists as elements are + faster.

    Figure 22.30. A simple list

    A simple list

    List-update algorithms reorder lists as elements are accessed. They try to determine, by the access history, which keys to move to the front of the list. Some of these algorithms require adding some metadata alongside each entry.

    For example, in the graphic below label A shows the counter @@ -1167,7 +1139,7 @@ predetermined value, say 10, as shown in label C, the count is set to 0 and the node is moved to the front of the list, as in label D. -

    Figure 22.31. The counter algorithm

    The counter algorithm

    Policies

    this library allows instantiating lists with policies +

    Figure 22.31. The counter algorithm

    The counter algorithm

    Policies

    this library allows instantiating lists with policies implementing any algorithm moving nodes to the front of the list (policies implementing algorithms interchanging nodes are unsupported).

    Associative containers based on lists are parametrized by a @@ -1202,7 +1174,7 @@ the list. The latter type is very useful in this library, since there is no need to associate metadata with each element. (See [biblio.andrew04mtf] -

    Use in Multimaps

    In this library, there are no equivalents for the standard's +

    Use in Multimaps

    In this library, there are no equivalents for the standard's multimaps and multisets; instead one uses an associative container mapping primary keys to secondary keys.

    List-based containers are especially useful as associative containers for secondary keys. In fact, they are implemented @@ -1231,7 +1203,7 @@ object (a hash-based container object holds a hash functor). List-based containers, conversely, only have class-wide policy objects. -

    Priority Queue

    Interface

    The priority queue container has the following +

    Priority Queue

    Interface

    The priority queue container has the following declaration: 

     	  template<typename  Value_Type,
@@ -1267,7 +1239,7 @@
 	insufficient for manipulating priority-queues. 
    Different settings require different priority-queue
 	implementations which are described in later; see traits
 	discusses ways to differentiate between the different traits of
-	different implementations.
    Details
    Iterators

    There are many different underlying-data structures for + different implementations.

    Details
    Iterators

    There are many different underlying-data structures for implementing priority queues. Unfortunately, most such structures are oriented towards making push and top efficient, and consequently don't allow efficient @@ -1334,12 +1306,12 @@ this data and a priority queue's iterator. Using the embedded method would need to use two associative containers. Similar problems might arise in cases where a value can reside - simultaneously in many priority queues.

    Underlying Data Structure

    There are three main implementations of priority queues: the + simultaneously in many priority queues.

    Underlying Data Structure

    There are three main implementations of priority queues: the first employs a binary heap, typically one which uses a sequence; the second uses a tree (or forest of trees), which is typically less structured than an associative container's tree; the third simply uses an associative container. These are - shown in the graphic below, in labels A1 and A2, label B, and label C.

    Figure 22.32. Underlying Priority-Queue Data-Structures.

    Underlying Priority-Queue Data-Structures.

    Roughly speaking, any value that is both pushed and popped + shown in the graphic below, in labels A1 and A2, label B, and label C.

    Figure 22.32. Underlying Priority-Queue Data-Structures.

    Underlying Priority-Queue Data-Structures.

    Roughly speaking, any value that is both pushed and popped from a priority queue must incur a logarithmic expense (in the amortized sense). Any priority queue implementation that would avoid this, would violate known bounds on comparison-based @@ -1409,7 +1381,7 @@ at all; the priority queue itself is an associative container. Most associative containers are too structured to compete with priority queues in terms of push and pop - performance.

    Traits

    It would be nice if all priority queues could + performance.

    Traits

    It would be nice if all priority queues could share exactly the same behavior regardless of implementation. Sadly, this is not possible. Just one for instance is in join operations: joining two binary heaps might throw an exception (not corrupt any of the heaps on which it operates), but joining two pairing @@ -1419,7 +1391,7 @@ container Cntnr, the tag of the underlying data structure can be found via typename Cntnr::container_category; this is one of the possible tags shown in the graphic below. -

    Figure 22.33. Priority-Queue Data-Structure Tags.

    Priority-Queue Data-Structure Tags.

    Additionally, a traits mechanism can be used to query a +

    Figure 22.33. Priority-Queue Data-Structure Tags.

    Priority-Queue Data-Structure Tags.

    Additionally, a traits mechanism can be used to query a container type for its attributes. Given any container Cntnr, then 

    __gnu_pbds::container_traits<Cntnr>

    is a traits class identifying the properties of the @@ -1455,4 +1427,4 @@ erase operations is non-negligible (say super-logarithmic in the total sequence of operations) - binary heaps will perform badly. -

    Prev Up Next
    Using Home Testing
    +

    Prev Up Next
    Using Home Testing
    diff --git a/libstdc++-v3/doc/html/manual/policy_data_structures_using.html b/libstdc++-v3/doc/html/manual/policy_data_structures_using.html index ba5c2234024..9c2d537014f 100644 --- a/libstdc++-v3/doc/html/manual/policy_data_structures_using.html +++ b/libstdc++-v3/doc/html/manual/policy_data_structures_using.html @@ -1,34 +1,6 @@ -Using
    Using
    Prev Chapter 22. Policy-Based Data Structures Next

    Using

    Prerequisites

    The library contains only header files, and does not require any + + +Using

    Using
    Prev Chapter 22. Policy-Based Data Structures Next

    Using

    Prerequisites

    The library contains only header files, and does not require any other libraries except the standard C++ library . All classes are defined in namespace __gnu_pbds. The library internally uses macros beginning with PB_DS, but @@ -39,7 +11,7 @@ Further dependencies are necessary to create the visual output for the performance tests. To create these graphs, an additional package is needed: pychart. -

    Organization

    +

    Organization

    The various data structures are organized as follows.

    • Branch-Based @@ -90,7 +62,7 @@ In addition, there are the following diagnostics classes, used to report errors specific to this library's data structures. -

      Figure 22.7. Exception Hierarchy

      Exception Hierarchy

    Tutorial

    Basic Use

    +

    Figure 22.7. Exception Hierarchy

    Exception Hierarchy

    Tutorial

    Basic Use

    For the most part, the policy-based containers containers in namespace __gnu_pbds have the same interface as the equivalent containers in the standard C++ library, except for @@ -214,7 +186,7 @@

    so all hash-based associative containers inherit the same hash-functor accessor methods. -

    +

    Configuring via Template Parameters

    In general, each of this library's containers is @@ -268,7 +240,7 @@ by one of them.

    Note that as opposed to the std::priority_queue, __gnu_pbds::priority_queue is not a - sequence-adapter; it is a regular container.

    + sequence-adapter; it is a regular container.

    Querying Container Attributes

    A containers underlying data structure affect their performance; Unfortunately, they can also affect @@ -306,7 +278,7 @@

    is the container's invalidation guarantee. Invalidation guarantees are especially important regarding priority queues, since in this library's design, iterators are practically the - only way to manipulate them.

    + only way to manipulate them.

    Point and Range Iteration

    This library differentiates between two types of methods and iterators: point-type, and range-type. For example, @@ -405,11 +377,11 @@

    gives one of three pre-determined types that answer this query. -

    Examples

    +

    Examples

    Additional code examples are provided in the source distribution, as part of the regression and performance testsuite. -

    Intermediate Use

    • +

      Intermediate Use

      • Basic use of maps: basic_map.cc

      • @@ -433,7 +405,7 @@

      • Conditionally erasing values from a priority queue: priority_queue_erase_if.cc -

      Querying with container_traits

      • +

      Querying with container_traits

      • Using container_traits to query about underlying data structure behavior: assoc_container_traits.cc @@ -444,7 +416,7 @@ Using container_traits to query about underlying data structure behavior: priority_queue_container_traits.cc -

      By Container Method

      Hash-Based
      size Related

      • +

      By Container Method

      Hash-Based
      size Related

      • Setting the initial size of a hash-based container object: hash_initial_size.cc @@ -462,7 +434,7 @@

      • Changing the load factors of a hash-based container object: hash_load_set_change.cc -

      Hashing Function Related

      • +

      Hashing Function Related

      • Using a modulo range-hashing function for the case of an unknown skewed key distribution: hash_mod.cc @@ -476,7 +448,7 @@

      • Writing a ranged-hash functor: ranged_hash.cc -

      Branch-Based
      split or join Related

      • +

      Branch-Based
      split or join Related

      • Joining two tree-based container objects: tree_join.cc

      • @@ -486,21 +458,21 @@ Order statistics while joining two tree-based container objects: tree_order_statistics_join.cc -

      Node Invariants

      • +

      Node Invariants

      • Using trees for order statistics: tree_order_statistics.cc

      • Augmenting trees to support operations on line intervals: tree_intervals.cc -

      trie

      • +

      trie

      • Using a PATRICIA trie for DNA strings: trie_dna.cc

      • Using a PATRICIA trie for finding all entries whose key matches a given prefix: trie_prefix_search.cc -

      Priority Queues

      • +

      Priority Queues

      • Cross referencing an associative container and a priority queue: priority_queue_xref.cc

      • @@ -508,4 +480,4 @@ very simple version of Dijkstra's shortest path algorithm: priority_queue_dijkstra.cc -

    Prev Up Next
    Chapter 22. Policy-Based Data Structures Home Design
    +

    Prev Up Next
    Chapter 22. Policy-Based Data Structures Home Design
    diff --git a/libstdc++-v3/doc/html/manual/profile_mode.html b/libstdc++-v3/doc/html/manual/profile_mode.html index 67b8adbc806..f47c6b7e316 100644 --- a/libstdc++-v3/doc/html/manual/profile_mode.html +++ b/libstdc++-v3/doc/html/manual/profile_mode.html @@ -1,23 +1,9 @@ -Chapter 19. Profile Mode
    Chapter 19. Profile Mode
    Prev Part III.  + + +Chapter 19. Profile Mode
    Chapter 19. Profile Mode
    Prev Part III.  Extensions - Next

    Chapter 19. Profile Mode

    Table of Contents

    Intro
    Using the Profile Mode
    Tuning the Profile Mode
    Design
    Wrapper Model
    Instrumentation
    Run Time Behavior
    Analysis and Diagnostics
    Cost Model
    Reports
    Testing
    Extensions for Custom Containers
    Empirical Cost Model
    Implementation Issues
    Stack Traces
    Symbolization of Instruction Addresses
    Concurrency
    Using the Standard Library in the Instrumentation Implementation
    Malloc Hooks
    Construction and Destruction of Global Objects
    Developer Information
    Big Picture
    How To Add A Diagnostic
    Diagnostics
    Diagnostic Template
    Containers
    Hashtable Too Small
    Hashtable Too Large
    Inefficient Hash
    Vector Too Small
    Vector Too Large
    Vector to Hashtable
    Hashtable to Vector
    Vector to List
    List to Vector
    List to Forward List (Slist)
    Ordered to Unordered Associative Container
    Algorithms
    Sort Algorithm Performance
    Data Locality
    Need Software Prefetch
    Linked Structure Locality
    Multithreaded Data Access
    Data Dependence Violations at Container Level
    False Sharing
    Statistics
    Bibliography

    Intro

    +

    		 Next

    Chapter 19. Profile Mode

    Table of Contents

    Intro
    Using the Profile Mode
    Tuning the Profile Mode
    Design
    Wrapper Model
    Instrumentation
    Run Time Behavior
    Analysis and Diagnostics
    Cost Model
    Reports
    Testing
    Extensions for Custom Containers
    Empirical Cost Model
    Implementation Issues
    Stack Traces
    Symbolization of Instruction Addresses
    Concurrency
    Using the Standard Library in the Instrumentation Implementation
    Malloc Hooks
    Construction and Destruction of Global Objects
    Developer Information
    Big Picture
    How To Add A Diagnostic
    Diagnostics
    Diagnostic Template
    Containers
    Hashtable Too Small
    Hashtable Too Large
    Inefficient Hash
    Vector Too Small
    Vector Too Large
    Vector to Hashtable
    Hashtable to Vector
    Vector to List
    List to Vector
    List to Forward List (Slist)
    Ordered to Unordered Associative Container
    Algorithms
    Sort Algorithm Performance
    Data Locality
    Need Software Prefetch
    Linked Structure Locality
    Multithreaded Data Access
    Data Dependence Violations at Container Level
    False Sharing
    Statistics
    Bibliography

    Intro

    Goal: Give performance improvement advice based on recognition of suboptimal usage patterns of the standard library.

    @@ -48,7 +34,7 @@

  • The execution time will increase, in some cases by factors.

    • -

    Using the Profile Mode

    +

    Using the Profile Mode

    This is the anticipated common workflow for program foo.cc: 

     $ cat foo.cc
@@ -108,7 +94,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
   We believe such warnings can help users understand the performance
   behavior of their application better, which can lead to changes
   at a higher abstraction level.
-

    Tuning the Profile Mode

    Compile time switches and environment variables (see also file +

    Tuning the Profile Mode

    Compile time switches and environment variables (see also file profiler.h). Unless specified otherwise, they can be set at compile time using -D_<name> or by setting variable <name> in the environment where the program is run, before starting execution. @@ -152,9 +138,9 @@ vector-size: improvement = 3: call stack = 0x804842c ... call context. (Environment variable not supported.)

    -

    Bibliography

    +

    Bibliography

    Perflint: A Context Sensitive Performance Advisor for C++ Programs . Lixia Liu. Silvius Rus. Copyright © 2009 . Proceedings of the 2009 International Symposium on Code Generation and Optimization - .

    Prev Up Next
    Testing Home Design
    + .

    Prev Up Next
    Testing Home Design
    diff --git a/libstdc++-v3/doc/html/manual/setup.html b/libstdc++-v3/doc/html/manual/setup.html index 0371632f948..c83774b8f48 100644 --- a/libstdc++-v3/doc/html/manual/setup.html +++ b/libstdc++-v3/doc/html/manual/setup.html @@ -1,17 +1,9 @@ -Chapter 2. Setup
    Chapter 2. Setup
    Prev Part I.  + + +Chapter 2. Setup
    Chapter 2. Setup
    Prev Part I.  Introduction - Next

    Chapter 2. Setup

    Table of Contents

    Prerequisites
    Configure
    Make

    To transform libstdc++ sources into installed include files +

    		 Next

    Chapter 2. Setup

    Table of Contents

    Prerequisites
    Configure
    Make

    To transform libstdc++ sources into installed include files and properly built binaries useful for linking to other software is a multi-step process. Steps include getting the sources, configuring and building the sources, testing, and installation. @@ -27,7 +19,7 @@ make install

    Each step is described in more detail in the following sections. -

    Prerequisites

    +

    Prerequisites

    Because libstdc++ is part of GCC, the primary source for installation instructions is the GCC install page. @@ -98,4 +90,4 @@ zh_TW BIG5

    • install all locales

    • install just the necessary locales

      • with Debian GNU/Linux:

        Add the above list, as shown, to the file /etc/locale.gen

        run /usr/sbin/locale-gen

      • on most Unix-like operating systems:

        localedef -i de_DE -f ISO-8859-1 de_DE

        (repeat for each entry in the above list)

      • Instructions for other operating systems solicited. -

    Prev Up Next
    Bugs Home Configure
    +

    Prev Up Next
    Bugs Home Configure
    diff --git a/libstdc++-v3/doc/html/manual/source_code_style.html b/libstdc++-v3/doc/html/manual/source_code_style.html index fde94999f61..0927ece403c 100644 --- a/libstdc++-v3/doc/html/manual/source_code_style.html +++ b/libstdc++-v3/doc/html/manual/source_code_style.html @@ -1,628 +1,620 @@ -Coding Style
    Coding Style
    Prev Appendix A.  + + +Coding Style
    Coding Style
    Prev Appendix A.  Contributing - Next

    Coding Style

    -

    Bad Identifiers

    +

    		 Next

    Coding Style

    +

    Bad Identifiers

    Identifiers that conflict and should be avoided. -


    -      This is the list of names “reserved to the
    -      implementation    ”     that have been claimed by certain
    -      compilers and system headers of interest, and should not be used
    -      in the library. It will grow, of course.  We generally are
    -      interested in names that are not all-caps, except for those like
    -      "_T"
    -
    -      For Solaris:
    -      _B
    -      _C
    -      _L
    -      _N
    -      _P
    -      _S
    -      _U
    -      _X
    -      _E1
    -      ..
    -      _E24
    -
    -      Irix adds:
    -      _A
    -      _G
    -
    -      MS adds:
    -      _T
    -
    -      BSD adds:
    -      __used
    -      __unused
    -      __inline
    -      _Complex
    -      __istype
    -      __maskrune
    -      __tolower
    -      __toupper
    -      __wchar_t
    -      __wint_t
    -      _res
    -      _res_ext
    -      __tg_*
    -
    -      SPU adds:
    -      __ea
    -
    -      For GCC:
    -
    -      [Note that this list is out of date. It applies to the old
    -      name-mangling; in G++ 3.0 and higher a different name-mangling is
    -      used. In addition, many of the bugs relating to G++ interpreting
    -      these names as operators have been fixed.]
    -
    -      The full set of __* identifiers (combined from gcc/cp/lex.c and
    -      gcc/cplus-dem.c) that are either old or new, but are definitely
    -      recognized by the demangler, is:
    -
    -      __aa
    -      __aad
    -      __ad
    -      __addr
    -      __adv
    -      __aer
    -      __als
    -      __alshift
    -      __amd
    -      __ami
    -      __aml
    -      __amu
    -      __aor
    -      __apl
    -      __array
    -      __ars
    -      __arshift
    -      __as
    -      __bit_and
    -      __bit_ior
    -      __bit_not
    -      __bit_xor
    -      __call
    -      __cl
    -      __cm
    -      __cn
    -      __co
    -      __component
    -      __compound
    -      __cond
    -      __convert
    -      __delete
    -      __dl
    -      __dv
    -      __eq
    -      __er
    -      __ge
    -      __gt
    -      __indirect
    -      __le
    -      __ls
    -      __lt
    -      __max
    -      __md
    -      __method_call
    -      __mi
    -      __min
    -      __minus
    -      __ml
    -      __mm
    -      __mn
    -      __mult
    -      __mx
    -      __ne
    -      __negate
    -      __new
    -      __nop
    -      __nt
    -      __nw
    -      __oo
    -      __op
    -      __or
    -      __pl
    -      __plus
    -      __postdecrement
    -      __postincrement
    -      __pp
    -      __pt
    -      __rf
    -      __rm
    -      __rs
    -      __sz
    -      __trunc_div
    -      __trunc_mod
    -      __truth_andif
    -      __truth_not
    -      __truth_orif
    -      __vc
    -      __vd
    -      __vn
    -
    -      SGI badnames:
    -      __builtin_alloca
    -      __builtin_fsqrt
    -      __builtin_sqrt
    -      __builtin_fabs
    -      __builtin_dabs
    -      __builtin_cast_f2i
    -      __builtin_cast_i2f
    -      __builtin_cast_d2ll
    -      __builtin_cast_ll2d
    -      __builtin_copy_dhi2i
    -      __builtin_copy_i2dhi
    -      __builtin_copy_dlo2i
    -      __builtin_copy_i2dlo
    -      __add_and_fetch
    -      __sub_and_fetch
    -      __or_and_fetch
    -      __xor_and_fetch
    -      __and_and_fetch
    -      __nand_and_fetch
    -      __mpy_and_fetch
    -      __min_and_fetch
    -      __max_and_fetch
    -      __fetch_and_add
    -      __fetch_and_sub
    -      __fetch_and_or
    -      __fetch_and_xor
    -      __fetch_and_and
    -      __fetch_and_nand
    -      __fetch_and_mpy
    -      __fetch_and_min
    -      __fetch_and_max
    -      __lock_test_and_set
    -      __lock_release
    -      __lock_acquire
    -      __compare_and_swap
    -      __synchronize
    -      __high_multiply
    -      __unix
    -      __sgi
    -      __linux__
    -      __i386__
    -      __i486__
    -      __cplusplus
    -      __embedded_cplusplus
    -      // long double conversion members mangled as __opr
    -      // http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00060.html
    -      __opr
    -    

    By Example


    -      This library is written to appropriate C++ coding standards. As such,
    -      it is intended to precede the recommendations of the GNU Coding
    -      Standard, which can be referenced in full here:
    -
    -      http://www.gnu.org/prep/standards/standards.html#Formatting
    -
    -      The rest of this is also interesting reading, but skip the "Design
    -      Advice" part.
    -
    -      The GCC coding conventions are here, and are also useful:
    -      http://gcc.gnu.org/codingconventions.html
    -
    -      In addition, because it doesn't seem to be stated explicitly anywhere
    -      else, there is an 80 column source limit.
    -
    -      ChangeLog entries for member functions should use the
    -      classname::member function name syntax as follows:
    -
    -
    -1999-04-15  Dennis Ritchie  <dr@att.com>
    -
    -      * src/basic_file.cc (__basic_file::open): Fix thinko in
    -      _G_HAVE_IO_FILE_OPEN bits.
    -
    -
    -      Notable areas of divergence from what may be previous local practice
    -      (particularly for GNU C) include:
    -
    -      01. Pointers and references
    -      
    -        char* p = "flop";
    -        char& c = *p;
    -          -NOT-
    -        char *p = "flop";  // wrong
    -        char &c = *p;      // wrong
    -      
    -
    -      Reason: In C++, definitions are mixed with executable code. Here,
    -      p is being initialized, not *p.  This is near-universal
    -      practice among C++ programmers; it is normal for C hackers
    -      to switch spontaneously as they gain experience.
    -
    -      02. Operator names and parentheses
    -      
    -        operator==(type)
    -          -NOT-
    -        operator == (type)  // wrong
    -      
    -
    -      Reason: The == is part of the function name. Separating
    -      it makes the declaration look like an expression.
    -
    -      03. Function names and parentheses
    -      
    -        void mangle()
    -          -NOT-
    -        void mangle ()  // wrong
    -      
    -
    -      Reason: no space before parentheses (except after a control-flow
    -      keyword) is near-universal practice for C++. It identifies the
    -      parentheses as the function-call operator or declarator, as
    -      opposed to an expression or other overloaded use of parentheses.
    -
    -      04. Template function indentation
    -      
    -        template<typename T>
    -          void
    -          template_function(args)
    -          { }
    -          -NOT-
    -        template<class T>
    -        void template_function(args) {};
    -      
    -
    -      Reason: In class definitions, without indentation whitespace is
    -      needed both above and below the declaration to distinguish
    -      it visually from other members. (Also, re: "typename"
    -      rather than "class".)  T often could be int, which is
    -      not a class. ("class", here, is an anachronism.)
    -
    -      05. Template class indentation
    -      
    -        template<typename _CharT, typename _Traits>
    -          class basic_ios : public ios_base
    -          {
    -          public:
    -            // Types:
    -          };
    -          -NOT-
    -        template<class _CharT, class _Traits>
    -        class basic_ios : public ios_base
    -          {
    -          public:
    -            // Types:
    -          };
    -          -NOT-
    -        template<class _CharT, class _Traits>
    -          class basic_ios : public ios_base
    -        {
    -          public:
    -            // Types:
    -        };
    -      
    -
    -      06. Enumerators
    -      
    -        enum
    -        {
    -          space = _ISspace,
    -          print = _ISprint,
    -          cntrl = _IScntrl
    -        };
    -          -NOT-
    -        enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl };
    -      
    -
    -      07. Member initialization lists
    -      All one line, separate from class name.
    -
    -      
    -        gribble::gribble()
    -        : _M_private_data(0), _M_more_stuff(0), _M_helper(0)
    -        { }
    -          -NOT-
    -        gribble::gribble() : _M_private_data(0), _M_more_stuff(0), _M_helper(0)
    -        { }
    -      
    -
    -      08. Try/Catch blocks
    -      
    -        try
    -          {
    -            //
    -          }
    -        catch (...)
    -          {
    -            //
    -          }
    -          -NOT-
    -        try {
    -          //
    -        } catch(...) {
    -          //
    -        }
    -      
    -
    -      09. Member functions declarations and definitions
    -      Keywords such as extern, static, export, explicit, inline, etc
    -      go on the line above the function name. Thus
    -
    -      
    -      virtual int
    -      foo()
    -      -NOT-
    -      virtual int foo()
    -      
    -
    -      Reason: GNU coding conventions dictate return types for functions
    -      are on a separate line than the function name and parameter list
    -      for definitions. For C++, where we have member functions that can
    -      be either inline definitions or declarations, keeping to this
    -      standard allows all member function names for a given class to be
    -      aligned to the same margin, increasing readability.
    -
    -
    -      10. Invocation of member functions with "this->"
    -      For non-uglified names, use this->name to call the function.
    -
    -      
    -      this->sync()
    -      -NOT-
    -      sync()
    -      
    -
    -      Reason: Koenig lookup.
    -
    -      11. Namespaces
    -      
    -      namespace std
    -      {
    -        blah blah blah;
    -      } // namespace std
    -
    -      -NOT-
    -
    -      namespace std {
    -        blah blah blah;
    -      } // namespace std
    -      
    -
    -      12. Spacing under protected and private in class declarations:
    -      space above, none below
    -      i.e.
    -
    -      
    -      public:
    -        int foo;
    -
    -      -NOT-
    -      public:
    -
    -        int foo;
    -      
    -
    -      13. Spacing WRT return statements.
    -      no extra spacing before returns, no parenthesis
    -      i.e.
    -
    -      
    -      }
    -      return __ret;
    -
    -      -NOT-
    -      }
    -
    -      return __ret;
    -
    -      -NOT-
    -
    -      }
    -      return (__ret);
    -      
    -
    -
    -      14. Location of global variables.
    -      All global variables of class type, whether in the "user visible"
    -      space (e.g., cin) or the implementation namespace, must be defined
    -      as a character array with the appropriate alignment and then later
    -      re-initialized to the correct value.
    -
    -      This is due to startup issues on certain platforms, such as AIX.
    -      For more explanation and examples, see src/globals.cc. All such
    -      variables should be contained in that file, for simplicity.
    -
    -      15. Exception abstractions
    -      Use the exception abstractions found in functexcept.h, which allow
    -      C++ programmers to use this library with -fno-exceptions.  (Even if
    -      that is rarely advisable, it's a necessary evil for backwards
    -      compatibility.)
    -
    -      16. Exception error messages
    -      All start with the name of the function where the exception is
    -      thrown, and then (optional) descriptive text is added. Example:
    -
    -      
    -      __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
    -      
    -
    -      Reason: The verbose terminate handler prints out exception::what(),
    -      as well as the typeinfo for the thrown exception. As this is the
    -      default terminate handler, by putting location info into the
    -      exception string, a very useful error message is printed out for
    -      uncaught exceptions. So useful, in fact, that non-programmers can
    -      give useful error messages, and programmers can intelligently
    -      speculate what went wrong without even using a debugger.
    -
    -      17. The doxygen style guide to comments is a separate document,
    -      see index.
    -
    -      The library currently has a mixture of GNU-C and modern C++ coding
    -      styles. The GNU C usages will be combed out gradually.
    -
    -      Name patterns:
    -
    -      For nonstandard names appearing in Standard headers, we are constrained
    -      to use names that begin with underscores. This is called "uglification".
    -      The convention is:
    -
    -      Local and argument names:  __[a-z].*
    -
    -      Examples:  __count  __ix  __s1
    -
    -      Type names and template formal-argument names: _[A-Z][^_].*
    -
    -      Examples:  _Helper  _CharT  _N
    -
    -      Member data and function names: _M_.*
    -
    -      Examples:  _M_num_elements  _M_initialize ()
    -
    -      Static data members, constants, and enumerations: _S_.*
    -
    -      Examples: _S_max_elements  _S_default_value
    -
    -      Don't use names in the same scope that differ only in the prefix,
    -      e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names.
    -      (The most tempting of these seem to be and "_T" and "__sz".)
    -
    -      Names must never have "__" internally; it would confuse name
    -      unmanglers on some targets. Also, never use "__[0-9]", same reason.
    -
    -      --------------------------
    -
    -      [BY EXAMPLE]
    -      
    -
    -      #ifndef  _HEADER_
    -      #define  _HEADER_ 1
    -
    -      namespace std
    -      {
    -        class gribble
    -        {
    -        public:
    -          gribble() throw();
    -
    -          gribble(const gribble&);
    -
    -          explicit
    -          gribble(int __howmany);
    -
    -          gribble&
    -          operator=(const gribble&);
    -
    -          virtual
    -          ~gribble() throw ();
    -
    -          // Start with a capital letter, end with a period.
    -          inline void
    -          public_member(const char* __arg) const;
    -
    -          // In-class function definitions should be restricted to one-liners.
    -          int
    -          one_line() { return 0 }
    -
    -          int
    -          two_lines(const char* arg)
    -          { return strchr(arg, 'a'); }
    -
    -          inline int
    -          three_lines();  // inline, but defined below.
    -
    -          // Note indentation.
    -          template<typename _Formal_argument>
    -            void
    -            public_template() const throw();
    -
    -          template<typename _Iterator>
    -            void
    -            other_template();
    -
    -        private:
    -          class _Helper;
    -
    -          int _M_private_data;
    -          int _M_more_stuff;
    -          _Helper* _M_helper;
    -          int _M_private_function();
    -
    -          enum _Enum
    -            {
    -              _S_one,
    -              _S_two
    -            };
    -
    -          static void
    -          _S_initialize_library();
    -        };
    -
    -        // More-or-less-standard language features described by lack, not presence.
    -      # ifndef _G_NO_LONGLONG
    -        extern long long _G_global_with_a_good_long_name;  // avoid globals!
    -      # endif
    -
    -        // Avoid in-class inline definitions, define separately;
    -        // likewise for member class definitions:
    -        inline int
    -        gribble::public_member() const
    -        { int __local = 0; return __local; }
    -
    -        class gribble::_Helper
    -        {
    -          int _M_stuff;
    -
    -          friend class gribble;
    -        };
    -      }
    -
    -      // Names beginning with "__": only for arguments and
    -      //   local variables; never use "__" in a type name, or
    -      //   within any name; never use "__[0-9]".
    -
    -      #endif /* _HEADER_ */
    -
    -
    -      namespace std
    -      {
    -        template<typename T>  // notice: "typename", not "class", no space
    -          long_return_value_type<with_many, args>
    -          function_name(char* pointer,               // "char *pointer" is wrong.
    -                        char* argument,
    -                        const Reference& ref)
    -          {
    -            // int a_local;  /* wrong; see below. */
    -            if (test)
    -            {
    -              nested code
    -            }
    -
    -            int a_local = 0;  // declare variable at first use.
    -
    -            //  char a, b, *p;   /* wrong */
    -            char a = 'a';
    -            char b = a + 1;
    -            char* c = "abc";  // each variable goes on its own line, always.
    -
    -            // except maybe here...
    -            for (unsigned i = 0, mask = 1; mask; ++i, mask <<= 1) {
    -              // ...
    -            }
    -          }
    -
    -        gribble::gribble()
    -        : _M_private_data(0), _M_more_stuff(0), _M_helper(0)
    -        { }
    -
    -        int
    -        gribble::three_lines()
    -        {
    -          // doesn't fit in one line.
    -        }
    -      } // namespace std
    -      
    -    

    Prev Up Next
    Directory Layout and Source Conventions Home Design Notes
    +


    +      This is the list of names “reserved to the
    +      implementation    ”     that have been claimed by certain
    +      compilers and system headers of interest, and should not be used
    +      in the library. It will grow, of course.  We generally are
    +      interested in names that are not all-caps, except for those like
    +      "_T"
    +
    +      For Solaris:
    +      _B
    +      _C
    +      _L
    +      _N
    +      _P
    +      _S
    +      _U
    +      _X
    +      _E1
    +      ..
    +      _E24
    +
    +      Irix adds:
    +      _A
    +      _G
    +
    +      MS adds:
    +      _T
    +
    +      BSD adds:
    +      __used
    +      __unused
    +      __inline
    +      _Complex
    +      __istype
    +      __maskrune
    +      __tolower
    +      __toupper
    +      __wchar_t
    +      __wint_t
    +      _res
    +      _res_ext
    +      __tg_*
    +
    +      SPU adds:
    +      __ea
    +
    +      For GCC:
    +
    +      [Note that this list is out of date. It applies to the old
    +      name-mangling; in G++ 3.0 and higher a different name-mangling is
    +      used. In addition, many of the bugs relating to G++ interpreting
    +      these names as operators have been fixed.]
    +
    +      The full set of __* identifiers (combined from gcc/cp/lex.c and
    +      gcc/cplus-dem.c) that are either old or new, but are definitely
    +      recognized by the demangler, is:
    +
    +      __aa
    +      __aad
    +      __ad
    +      __addr
    +      __adv
    +      __aer
    +      __als
    +      __alshift
    +      __amd
    +      __ami
    +      __aml
    +      __amu
    +      __aor
    +      __apl
    +      __array
    +      __ars
    +      __arshift
    +      __as
    +      __bit_and
    +      __bit_ior
    +      __bit_not
    +      __bit_xor
    +      __call
    +      __cl
    +      __cm
    +      __cn
    +      __co
    +      __component
    +      __compound
    +      __cond
    +      __convert
    +      __delete
    +      __dl
    +      __dv
    +      __eq
    +      __er
    +      __ge
    +      __gt
    +      __indirect
    +      __le
    +      __ls
    +      __lt
    +      __max
    +      __md
    +      __method_call
    +      __mi
    +      __min
    +      __minus
    +      __ml
    +      __mm
    +      __mn
    +      __mult
    +      __mx
    +      __ne
    +      __negate
    +      __new
    +      __nop
    +      __nt
    +      __nw
    +      __oo
    +      __op
    +      __or
    +      __pl
    +      __plus
    +      __postdecrement
    +      __postincrement
    +      __pp
    +      __pt
    +      __rf
    +      __rm
    +      __rs
    +      __sz
    +      __trunc_div
    +      __trunc_mod
    +      __truth_andif
    +      __truth_not
    +      __truth_orif
    +      __vc
    +      __vd
    +      __vn
    +
    +      SGI badnames:
    +      __builtin_alloca
    +      __builtin_fsqrt
    +      __builtin_sqrt
    +      __builtin_fabs
    +      __builtin_dabs
    +      __builtin_cast_f2i
    +      __builtin_cast_i2f
    +      __builtin_cast_d2ll
    +      __builtin_cast_ll2d
    +      __builtin_copy_dhi2i
    +      __builtin_copy_i2dhi
    +      __builtin_copy_dlo2i
    +      __builtin_copy_i2dlo
    +      __add_and_fetch
    +      __sub_and_fetch
    +      __or_and_fetch
    +      __xor_and_fetch
    +      __and_and_fetch
    +      __nand_and_fetch
    +      __mpy_and_fetch
    +      __min_and_fetch
    +      __max_and_fetch
    +      __fetch_and_add
    +      __fetch_and_sub
    +      __fetch_and_or
    +      __fetch_and_xor
    +      __fetch_and_and
    +      __fetch_and_nand
    +      __fetch_and_mpy
    +      __fetch_and_min
    +      __fetch_and_max
    +      __lock_test_and_set
    +      __lock_release
    +      __lock_acquire
    +      __compare_and_swap
    +      __synchronize
    +      __high_multiply
    +      __unix
    +      __sgi
    +      __linux__
    +      __i386__
    +      __i486__
    +      __cplusplus
    +      __embedded_cplusplus
    +      // long double conversion members mangled as __opr
    +      // http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00060.html
    +      __opr
    +    

    By Example


    +      This library is written to appropriate C++ coding standards. As such,
    +      it is intended to precede the recommendations of the GNU Coding
    +      Standard, which can be referenced in full here:
    +
    +      http://www.gnu.org/prep/standards/standards.html#Formatting
    +
    +      The rest of this is also interesting reading, but skip the "Design
    +      Advice" part.
    +
    +      The GCC coding conventions are here, and are also useful:
    +      http://gcc.gnu.org/codingconventions.html
    +
    +      In addition, because it doesn't seem to be stated explicitly anywhere
    +      else, there is an 80 column source limit.
    +
    +      ChangeLog entries for member functions should use the
    +      classname::member function name syntax as follows:
    +
    +
    +1999-04-15  Dennis Ritchie  <dr@att.com>
    +
    +      * src/basic_file.cc (__basic_file::open): Fix thinko in
    +      _G_HAVE_IO_FILE_OPEN bits.
    +
    +
    +      Notable areas of divergence from what may be previous local practice
    +      (particularly for GNU C) include:
    +
    +      01. Pointers and references
    +      
    +        char* p = "flop";
    +        char& c = *p;
    +          -NOT-
    +        char *p = "flop";  // wrong
    +        char &c = *p;      // wrong
    +      
    +
    +      Reason: In C++, definitions are mixed with executable code. Here,
    +      p is being initialized, not *p.  This is near-universal
    +      practice among C++ programmers; it is normal for C hackers
    +      to switch spontaneously as they gain experience.
    +
    +      02. Operator names and parentheses
    +      
    +        operator==(type)
    +          -NOT-
    +        operator == (type)  // wrong
    +      
    +
    +      Reason: The == is part of the function name. Separating
    +      it makes the declaration look like an expression.
    +
    +      03. Function names and parentheses
    +      
    +        void mangle()
    +          -NOT-
    +        void mangle ()  // wrong
    +      
    +
    +      Reason: no space before parentheses (except after a control-flow
    +      keyword) is near-universal practice for C++. It identifies the
    +      parentheses as the function-call operator or declarator, as
    +      opposed to an expression or other overloaded use of parentheses.
    +
    +      04. Template function indentation
    +      
    +        template<typename T>
    +          void
    +          template_function(args)
    +          { }
    +          -NOT-
    +        template<class T>
    +        void template_function(args) {};
    +      
    +
    +      Reason: In class definitions, without indentation whitespace is
    +      needed both above and below the declaration to distinguish
    +      it visually from other members. (Also, re: "typename"
    +      rather than "class".)  T often could be int, which is
    +      not a class. ("class", here, is an anachronism.)
    +
    +      05. Template class indentation
    +      
    +        template<typename _CharT, typename _Traits>
    +          class basic_ios : public ios_base
    +          {
    +          public:
    +            // Types:
    +          };
    +          -NOT-
    +        template<class _CharT, class _Traits>
    +        class basic_ios : public ios_base
    +          {
    +          public:
    +            // Types:
    +          };
    +          -NOT-
    +        template<class _CharT, class _Traits>
    +          class basic_ios : public ios_base
    +        {
    +          public:
    +            // Types:
    +        };
    +      
    +
    +      06. Enumerators
    +      
    +        enum
    +        {
    +          space = _ISspace,
    +          print = _ISprint,
    +          cntrl = _IScntrl
    +        };
    +          -NOT-
    +        enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl };
    +      
    +
    +      07. Member initialization lists
    +      All one line, separate from class name.
    +
    +      
    +        gribble::gribble()
    +        : _M_private_data(0), _M_more_stuff(0), _M_helper(0)
    +        { }
    +          -NOT-
    +        gribble::gribble() : _M_private_data(0), _M_more_stuff(0), _M_helper(0)
    +        { }
    +      
    +
    +      08. Try/Catch blocks
    +      
    +        try
    +          {
    +            //
    +          }
    +        catch (...)
    +          {
    +            //
    +          }
    +          -NOT-
    +        try {
    +          //
    +        } catch(...) {
    +          //
    +        }
    +      
    +
    +      09. Member functions declarations and definitions
    +      Keywords such as extern, static, export, explicit, inline, etc
    +      go on the line above the function name. Thus
    +
    +      
    +      virtual int
    +      foo()
    +      -NOT-
    +      virtual int foo()
    +      
    +
    +      Reason: GNU coding conventions dictate return types for functions
    +      are on a separate line than the function name and parameter list
    +      for definitions. For C++, where we have member functions that can
    +      be either inline definitions or declarations, keeping to this
    +      standard allows all member function names for a given class to be
    +      aligned to the same margin, increasing readability.
    +
    +
    +      10. Invocation of member functions with "this->"
    +      For non-uglified names, use this->name to call the function.
    +
    +      
    +      this->sync()
    +      -NOT-
    +      sync()
    +      
    +
    +      Reason: Koenig lookup.
    +
    +      11. Namespaces
    +      
    +      namespace std
    +      {
    +        blah blah blah;
    +      } // namespace std
    +
    +      -NOT-
    +
    +      namespace std {
    +        blah blah blah;
    +      } // namespace std
    +      
    +
    +      12. Spacing under protected and private in class declarations:
    +      space above, none below
    +      i.e.
    +
    +      
    +      public:
    +        int foo;
    +
    +      -NOT-
    +      public:
    +
    +        int foo;
    +      
    +
    +      13. Spacing WRT return statements.
    +      no extra spacing before returns, no parenthesis
    +      i.e.
    +
    +      
    +      }
    +      return __ret;
    +
    +      -NOT-
    +      }
    +
    +      return __ret;
    +
    +      -NOT-
    +
    +      }
    +      return (__ret);
    +      
    +
    +
    +      14. Location of global variables.
    +      All global variables of class type, whether in the "user visible"
    +      space (e.g., cin) or the implementation namespace, must be defined
    +      as a character array with the appropriate alignment and then later
    +      re-initialized to the correct value.
    +
    +      This is due to startup issues on certain platforms, such as AIX.
    +      For more explanation and examples, see src/globals.cc. All such
    +      variables should be contained in that file, for simplicity.
    +
    +      15. Exception abstractions
    +      Use the exception abstractions found in functexcept.h, which allow
    +      C++ programmers to use this library with -fno-exceptions.  (Even if
    +      that is rarely advisable, it's a necessary evil for backwards
    +      compatibility.)
    +
    +      16. Exception error messages
    +      All start with the name of the function where the exception is
    +      thrown, and then (optional) descriptive text is added. Example:
    +
    +      
    +      __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
    +      
    +
    +      Reason: The verbose terminate handler prints out exception::what(),
    +      as well as the typeinfo for the thrown exception. As this is the
    +      default terminate handler, by putting location info into the
    +      exception string, a very useful error message is printed out for
    +      uncaught exceptions. So useful, in fact, that non-programmers can
    +      give useful error messages, and programmers can intelligently
    +      speculate what went wrong without even using a debugger.
    +
    +      17. The doxygen style guide to comments is a separate document,
    +      see index.
    +
    +      The library currently has a mixture of GNU-C and modern C++ coding
    +      styles. The GNU C usages will be combed out gradually.
    +
    +      Name patterns:
    +
    +      For nonstandard names appearing in Standard headers, we are constrained
    +      to use names that begin with underscores. This is called "uglification".
    +      The convention is:
    +
    +      Local and argument names:  __[a-z].*
    +
    +      Examples:  __count  __ix  __s1
    +
    +      Type names and template formal-argument names: _[A-Z][^_].*
    +
    +      Examples:  _Helper  _CharT  _N
    +
    +      Member data and function names: _M_.*
    +
    +      Examples:  _M_num_elements  _M_initialize ()
    +
    +      Static data members, constants, and enumerations: _S_.*
    +
    +      Examples: _S_max_elements  _S_default_value
    +
    +      Don't use names in the same scope that differ only in the prefix,
    +      e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names.
    +      (The most tempting of these seem to be and "_T" and "__sz".)
    +
    +      Names must never have "__" internally; it would confuse name
    +      unmanglers on some targets. Also, never use "__[0-9]", same reason.
    +
    +      --------------------------
    +
    +      [BY EXAMPLE]
    +      
    +
    +      #ifndef  _HEADER_
    +      #define  _HEADER_ 1
    +
    +      namespace std
    +      {
    +        class gribble
    +        {
    +        public:
    +          gribble() throw();
    +
    +          gribble(const gribble&);
    +
    +          explicit
    +          gribble(int __howmany);
    +
    +          gribble&
    +          operator=(const gribble&);
    +
    +          virtual
    +          ~gribble() throw ();
    +
    +          // Start with a capital letter, end with a period.
    +          inline void
    +          public_member(const char* __arg) const;
    +
    +          // In-class function definitions should be restricted to one-liners.
    +          int
    +          one_line() { return 0 }
    +
    +          int
    +          two_lines(const char* arg)
    +          { return strchr(arg, 'a'); }
    +
    +          inline int
    +          three_lines();  // inline, but defined below.
    +
    +          // Note indentation.
    +          template<typename _Formal_argument>
    +            void
    +            public_template() const throw();
    +
    +          template<typename _Iterator>
    +            void
    +            other_template();
    +
    +        private:
    +          class _Helper;
    +
    +          int _M_private_data;
    +          int _M_more_stuff;
    +          _Helper* _M_helper;
    +          int _M_private_function();
    +
    +          enum _Enum
    +            {
    +              _S_one,
    +              _S_two
    +            };
    +
    +          static void
    +          _S_initialize_library();
    +        };
    +
    +        // More-or-less-standard language features described by lack, not presence.
    +      # ifndef _G_NO_LONGLONG
    +        extern long long _G_global_with_a_good_long_name;  // avoid globals!
    +      # endif
    +
    +        // Avoid in-class inline definitions, define separately;
    +        // likewise for member class definitions:
    +        inline int
    +        gribble::public_member() const
    +        { int __local = 0; return __local; }
    +
    +        class gribble::_Helper
    +        {
    +          int _M_stuff;
    +
    +          friend class gribble;
    +        };
    +      }
    +
    +      // Names beginning with "__": only for arguments and
    +      //   local variables; never use "__" in a type name, or
    +      //   within any name; never use "__[0-9]".
    +
    +      #endif /* _HEADER_ */
    +
    +
    +      namespace std
    +      {
    +        template<typename T>  // notice: "typename", not "class", no space
    +          long_return_value_type<with_many, args>
    +          function_name(char* pointer,               // "char *pointer" is wrong.
    +                        char* argument,
    +                        const Reference& ref)
    +          {
    +            // int a_local;  /* wrong; see below. */
    +            if (test)
    +            {
    +              nested code
    +            }
    +
    +            int a_local = 0;  // declare variable at first use.
    +
    +            //  char a, b, *p;   /* wrong */
    +            char a = 'a';
    +            char b = a + 1;
    +            char* c = "abc";  // each variable goes on its own line, always.
    +
    +            // except maybe here...
    +            for (unsigned i = 0, mask = 1; mask; ++i, mask <<= 1) {
    +              // ...
    +            }
    +          }
    +
    +        gribble::gribble()
    +        : _M_private_data(0), _M_more_stuff(0), _M_helper(0)
    +        { }
    +
    +        int
    +        gribble::three_lines()
    +        {
    +          // doesn't fit in one line.
    +        }
    +      } // namespace std
    +      
    +    

    Prev Up Next
    Directory Layout and Source Conventions Home Design Notes
    diff --git a/libstdc++-v3/doc/html/manual/source_design_notes.html b/libstdc++-v3/doc/html/manual/source_design_notes.html index 407b3e4c0f4..5f5bb50f065 100644 --- a/libstdc++-v3/doc/html/manual/source_design_notes.html +++ b/libstdc++-v3/doc/html/manual/source_design_notes.html @@ -1,871 +1,863 @@ -Design Notes
    Design Notes
    Prev Appendix A.  + + +Design Notes
    Design Notes
    Prev Appendix A.  Contributing - Next

    Design Notes

    -


    -
    -    The Library
    -    -----------
    -
    -    This paper is covers two major areas:
    -
    -    - Features and policies not mentioned in the standard that
    -    the quality of the library implementation depends on, including
    -    extensions and "implementation-defined" features;
    -
    -    - Plans for required but unimplemented library features and
    -    optimizations to them.
    -
    -    Overhead
    -    --------
    -
    -    The standard defines a large library, much larger than the standard
    -    C library. A naive implementation would suffer substantial overhead
    -    in compile time, executable size, and speed, rendering it unusable
    -    in many (particularly embedded) applications. The alternative demands
    -    care in construction, and some compiler support, but there is no
    -    need for library subsets.
    -
    -    What are the sources of this overhead?  There are four main causes:
    -
    -    - The library is specified almost entirely as templates, which
    -    with current compilers must be included in-line, resulting in
    -    very slow builds as tens or hundreds of thousands of lines
    -    of function definitions are read for each user source file.
    -    Indeed, the entire SGI STL, as well as the dos Reis valarray,
    -    are provided purely as header files, largely for simplicity in
    -    porting. Iostream/locale is (or will be) as large again.
    -
    -    - The library is very flexible, specifying a multitude of hooks
    -    where users can insert their own code in place of defaults.
    -    When these hooks are not used, any time and code expended to
    -    support that flexibility is wasted.
    -
    -    - Templates are often described as causing to "code bloat". In
    -    practice, this refers (when it refers to anything real) to several
    -    independent processes. First, when a class template is manually
    -    instantiated in its entirely, current compilers place the definitions
    -    for all members in a single object file, so that a program linking
    -    to one member gets definitions of all. Second, template functions
    -    which do not actually depend on the template argument are, under
    -    current compilers, generated anew for each instantiation, rather
    -    than being shared with other instantiations. Third, some of the
    -    flexibility mentioned above comes from virtual functions (both in
    -    regular classes and template classes) which current linkers add
    -    to the executable file even when they manifestly cannot be called.
    -
    -    - The library is specified to use a language feature, exceptions,
    -    which in the current gcc compiler ABI imposes a run time and
    -    code space cost to handle the possibility of exceptions even when
    -    they are not used. Under the new ABI (accessed with -fnew-abi),
    -    there is a space overhead and a small reduction in code efficiency
    -    resulting from lost optimization opportunities associated with
    -    non-local branches associated with exceptions.
    -
    -    What can be done to eliminate this overhead?  A variety of coding
    -    techniques, and compiler, linker and library improvements and
    -    extensions may be used, as covered below. Most are not difficult,
    -    and some are already implemented in varying degrees.
    -
    -    Overhead: Compilation Time
    -    --------------------------
    -
    -    Providing "ready-instantiated" template code in object code archives
    -    allows us to avoid generating and optimizing template instantiations
    -    in each compilation unit which uses them. However, the number of such
    -    instantiations that are useful to provide is limited, and anyway this
    -    is not enough, by itself, to minimize compilation time. In particular,
    -    it does not reduce time spent parsing conforming headers.
    -
    -    Quicker header parsing will depend on library extensions and compiler
    -    improvements.  One approach is some variation on the techniques
    -    previously marketed as "pre-compiled headers", now standardized as
    -    support for the "export" keyword. "Exported" template definitions
    -    can be placed (once) in a "repository" -- really just a library, but
    -    of template definitions rather than object code -- to be drawn upon
    -    at link time when an instantiation is needed, rather than placed in
    -    header files to be parsed along with every compilation unit.
    -
    -    Until "export" is implemented we can put some of the lengthy template
    -    definitions in #if guards or alternative headers so that users can skip
    -    over the full definitions when they need only the ready-instantiated
    -    specializations.
    -
    -    To be precise, this means that certain headers which define
    -    templates which users normally use only for certain arguments
    -    can be instrumented to avoid exposing the template definitions
    -    to the compiler unless a macro is defined. For example, in
    -    <string>, we might have:
    -
    -    template <class _CharT, ... > class basic_string {
    -    ... // member declarations
    -    };
    -    ... // operator declarations
    -
    -    #ifdef _STRICT_ISO_
    -    # if _G_NO_TEMPLATE_EXPORT
    -    #   include <bits/std_locale.h>  // headers needed by definitions
    -    #   ...
    -    #   include <bits/string.tcc>  // member and global template definitions.
    -    # endif
    -    #endif
    -
    -    Users who compile without specifying a strict-ISO-conforming flag
    -    would not see many of the template definitions they now see, and rely
    -    instead on ready-instantiated specializations in the library. This
    -    technique would be useful for the following substantial components:
    -    string, locale/iostreams, valarray. It would *not* be useful or
    -    usable with the following: containers, algorithms, iterators,
    -    allocator. Since these constitute a large (though decreasing)
    -    fraction of the library, the benefit the technique offers is
    -    limited.
    -
    -    The language specifies the semantics of the "export" keyword, but
    -    the gcc compiler does not yet support it. When it does, problems
    -    with large template inclusions can largely disappear, given some
    -    minor library reorganization, along with the need for the apparatus
    -    described above.
    -
    -    Overhead: Flexibility Cost
    -    --------------------------
    -
    -    The library offers many places where users can specify operations
    -    to be performed by the library in place of defaults. Sometimes
    -    this seems to require that the library use a more-roundabout, and
    -    possibly slower, way to accomplish the default requirements than
    -    would be used otherwise.
    -
    -    The primary protection against this overhead is thorough compiler
    -    optimization, to crush out layers of inline function interfaces.
    -    Kuck & Associates has demonstrated the practicality of this kind
    -    of optimization.
    -
    -    The second line of defense against this overhead is explicit
    -    specialization. By defining helper function templates, and writing
    -    specialized code for the default case, overhead can be eliminated
    -    for that case without sacrificing flexibility. This takes full
    -    advantage of any ability of the optimizer to crush out degenerate
    -    code.
    -
    -    The library specifies many virtual functions which current linkers
    -    load even when they cannot be called. Some minor improvements to the
    -    compiler and to ld would eliminate any such overhead by simply
    -    omitting virtual functions that the complete program does not call.
    -    A prototype of this work has already been done. For targets where
    -    GNU ld is not used, a "pre-linker" could do the same job.
    -
    -    The main areas in the standard interface where user flexibility
    -    can result in overhead are:
    -
    -    - Allocators:  Containers are specified to use user-definable
    -    allocator types and objects, making tuning for the container
    -    characteristics tricky.
    -
    -    - Locales: the standard specifies locale objects used to implement
    -    iostream operations, involving many virtual functions which use
    -    streambuf iterators.
    -
    -    - Algorithms and containers: these may be instantiated on any type,
    -    frequently duplicating code for identical operations.
    -
    -    - Iostreams and strings: users are permitted to use these on their
    -    own types, and specify the operations the stream must use on these
    -    types.
    -
    -    Note that these sources of overhead are _avoidable_. The techniques
    -    to avoid them are covered below.
    -
    -    Code Bloat
    -    ----------
    -
    -    In the SGI STL, and in some other headers, many of the templates
    -    are defined "inline" -- either explicitly or by their placement
    -    in class definitions -- which should not be inline. This is a
    -    source of code bloat. Matt had remarked that he was relying on
    -    the compiler to recognize what was too big to benefit from inlining,
    -    and generate it out-of-line automatically. However, this also can
    -    result in code bloat except where the linker can eliminate the extra
    -    copies.
    -
    -    Fixing these cases will require an audit of all inline functions
    -    defined in the library to determine which merit inlining, and moving
    -    the rest out of line. This is an issue mainly in chapters 23, 25, and
    -    27. Of course it can be done incrementally, and we should generally
    -    accept patches that move large functions out of line and into ".tcc"
    -    files, which can later be pulled into a repository. Compiler/linker
    -    improvements to recognize very large inline functions and move them
    -    out-of-line, but shared among compilation units, could make this
    -    work unnecessary.
    -
    -    Pre-instantiating template specializations currently produces large
    -    amounts of dead code which bloats statically linked programs. The
    -    current state of the static library, libstdc++.a, is intolerable on
    -    this account, and will fuel further confused speculation about a need
    -    for a library "subset". A compiler improvement that treats each
    -    instantiated function as a separate object file, for linking purposes,
    -    would be one solution to this problem. An alternative would be to
    -    split up the manual instantiation files into dozens upon dozens of
    -    little files, each compiled separately, but an abortive attempt at
    -    this was done for <string> and, though it is far from complete, it
    -    is already a nuisance. A better interim solution (just until we have
    -    "export") is badly needed.
    -
    -    When building a shared library, the current compiler/linker cannot
    -    automatically generate the instantiations needed. This creates a
    -    miserable situation; it means any time something is changed in the
    -    library, before a shared library can be built someone must manually
    -    copy the declarations of all templates that are needed by other parts
    -    of the library to an "instantiation" file, and add it to the build
    -    system to be compiled and linked to the library. This process is
    -    readily automated, and should be automated as soon as possible.
    -    Users building their own shared libraries experience identical
    -    frustrations.
    -
    -    Sharing common aspects of template definitions among instantiations
    -    can radically reduce code bloat. The compiler could help a great
    -    deal here by recognizing when a function depends on nothing about
    -    a template parameter, or only on its size, and giving the resulting
    -    function a link-name "equate" that allows it to be shared with other
    -    instantiations. Implementation code could take advantage of the
    -    capability by factoring out code that does not depend on the template
    -    argument into separate functions to be merged by the compiler.
    -
    -    Until such a compiler optimization is implemented, much can be done
    -    manually (if tediously) in this direction. One such optimization is
    -    to derive class templates from non-template classes, and move as much
    -    implementation as possible into the base class. Another is to partial-
    -    specialize certain common instantiations, such as vector<T*>, to share
    -    code for instantiations on all types T. While these techniques work,
    -    they are far from the complete solution that a compiler improvement
    -    would afford.
    -
    -    Overhead: Expensive Language Features
    -    -------------------------------------
    -
    -    The main "expensive" language feature used in the standard library
    -    is exception support, which requires compiling in cleanup code with
    -    static table data to locate it, and linking in library code to use
    -    the table. For small embedded programs the amount of such library
    -    code and table data is assumed by some to be excessive. Under the
    -    "new" ABI this perception is generally exaggerated, although in some
    -    cases it may actually be excessive.
    -
    -    To implement a library which does not use exceptions directly is
    -    not difficult given minor compiler support (to "turn off" exceptions
    -    and ignore exception constructs), and results in no great library
    -    maintenance difficulties. To be precise, given "-fno-exceptions",
    -    the compiler should treat "try" blocks as ordinary blocks, and
    -    "catch" blocks as dead code to ignore or eliminate. Compiler
    -    support is not strictly necessary, except in the case of "function
    -    try blocks"; otherwise the following macros almost suffice:
    -
    -    #define throw(X)
    -    #define try      if (true)
    -    #define catch(X) else if (false)
    -
    -    However, there may be a need to use function try blocks in the
    -    library implementation, and use of macros in this way can make
    -    correct diagnostics impossible. Furthermore, use of this scheme
    -    would require the library to call a function to re-throw exceptions
    -    from a try block. Implementing the above semantics in the compiler
    -    is preferable.
    -
    -    Given the support above (however implemented) it only remains to
    -    replace code that "throws" with a call to a well-documented "handler"
    -    function in a separate compilation unit which may be replaced by
    -    the user. The main source of exceptions that would be difficult
    -    for users to avoid is memory allocation failures, but users can
    -    define their own memory allocation primitives that never throw.
    -    Otherwise, the complete list of such handlers, and which library
    -    functions may call them, would be needed for users to be able to
    -    implement the necessary substitutes. (Fortunately, they have the
    -    source code.)
    -
    -    Opportunities
    -    -------------
    -
    -    The template capabilities of C++ offer enormous opportunities for
    -    optimizing common library operations, well beyond what would be
    -    considered "eliminating overhead". In particular, many operations
    -    done in Glibc with macros that depend on proprietary language
    -    extensions can be implemented in pristine Standard C++. For example,
    -    the chapter 25 algorithms, and even C library functions such as strchr,
    -    can be specialized for the case of static arrays of known (small) size.
    -
    -    Detailed optimization opportunities are identified below where
    -    the component where they would appear is discussed. Of course new
    -    opportunities will be identified during implementation.
    -
    -    Unimplemented Required Library Features
    -    ---------------------------------------
    -
    -    The standard specifies hundreds of components, grouped broadly by
    -    chapter. These are listed in excruciating detail in the CHECKLIST
    -    file.
    -
    -    17 general
    -    18 support
    -    19 diagnostics
    -    20 utilities
    -    21 string
    -    22 locale
    -    23 containers
    -    24 iterators
    -    25 algorithms
    -    26 numerics
    -    27 iostreams
    -    Annex D  backward compatibility
    -
    -    Anyone participating in implementation of the library should obtain
    -    a copy of the standard, ISO 14882.  People in the U.S. can obtain an
    -    electronic copy for US$18 from ANSI's web site. Those from other
    -    countries should visit http://www.iso.org/ to find out the location
    -    of their country's representation in ISO, in order to know who can
    -    sell them a copy.
    -
    -    The emphasis in the following sections is on unimplemented features
    -    and optimization opportunities.
    -
    -    Chapter 17  General
    -    -------------------
    -
    -    Chapter 17 concerns overall library requirements.
    -
    -    The standard doesn't mention threads. A multi-thread (MT) extension
    -    primarily affects operators new and delete (18), allocator (20),
    -    string (21), locale (22), and iostreams (27). The common underlying
    -    support needed for this is discussed under chapter 20.
    -
    -    The standard requirements on names from the C headers create a
    -    lot of work, mostly done. Names in the C headers must be visible
    -    in the std:: and sometimes the global namespace; the names in the
    -    two scopes must refer to the same object. More stringent is that
    -    Koenig lookup implies that any types specified as defined in std::
    -    really are defined in std::. Names optionally implemented as
    -    macros in C cannot be macros in C++. (An overview may be read at
    -    <http://www.cantrip.org/cheaders.html>). The scripts "inclosure"
    -    and "mkcshadow", and the directories shadow/ and cshadow/, are the
    -    beginning of an effort to conform in this area.
    -
    -    A correct conforming definition of C header names based on underlying
    -    C library headers, and practical linking of conforming namespaced
    -    customer code with third-party C libraries depends ultimately on
    -    an ABI change, allowing namespaced C type names to be mangled into
    -    type names as if they were global, somewhat as C function names in a
    -    namespace, or C++ global variable names, are left unmangled. Perhaps
    -    another "extern" mode, such as 'extern "C-global"' would be an
    -    appropriate place for such type definitions. Such a type would
    -    affect mangling as follows:
    -
    -    namespace A {
    -    struct X {};
    -    extern "C-global" {  // or maybe just 'extern "C"'
    -    struct Y {};
    -    };
    -    }
    -    void f(A::X*);  // mangles to f__FPQ21A1X
    -    void f(A::Y*);  // mangles to f__FP1Y
    -
    -    (It may be that this is really the appropriate semantics for regular
    -    'extern "C"', and 'extern "C-global"', as an extension, would not be
    -    necessary.) This would allow functions declared in non-standard C headers
    -    (and thus fixable by neither us nor users) to link properly with functions
    -    declared using C types defined in properly-namespaced headers. The
    -    problem this solves is that C headers (which C++ programmers do persist
    -    in using) frequently forward-declare C struct tags without including
    -    the header where the type is defined, as in
    -
    -    struct tm;
    -    void munge(tm*);
    -
    -    Without some compiler accommodation, munge cannot be called by correct
    -    C++ code using a pointer to a correctly-scoped tm* value.
    -
    -    The current C headers use the preprocessor extension "#include_next",
    -    which the compiler complains about when run "-pedantic".
    -    (Incidentally, it appears that "-fpedantic" is currently ignored,
    -    probably a bug.)  The solution in the C compiler is to use
    -    "-isystem" rather than "-I", but unfortunately in g++ this seems
    -    also to wrap the whole header in an 'extern "C"' block, so it's
    -    unusable for C++ headers. The correct solution appears to be to
    -    allow the various special include-directory options, if not given
    -    an argument, to affect subsequent include-directory options additively,
    -    so that if one said
    -
    -    -pedantic -iprefix $(prefix) \
    -    -idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \
    -    -iwithprefix -I g++-v3/ext
    -
    -    the compiler would search $(prefix)/g++-v3 and not report
    -    pedantic warnings for files found there, but treat files in
    -    $(prefix)/g++-v3/ext pedantically. (The undocumented semantics
    -    of "-isystem" in g++ stink. Can they be rescinded?  If not it
    -    must be replaced with something more rationally behaved.)
    -
    -    All the C headers need the treatment above; in the standard these
    -    headers are mentioned in various chapters. Below, I have only
    -    mentioned those that present interesting implementation issues.
    -
    -    The components identified as "mostly complete", below, have not been
    -    audited for conformance. In many cases where the library passes
    -    conformance tests we have non-conforming extensions that must be
    -    wrapped in #if guards for "pedantic" use, and in some cases renamed
    -    in a conforming way for continued use in the implementation regardless
    -    of conformance flags.
    -
    -    The STL portion of the library still depends on a header
    -    stl/bits/stl_config.h full of #ifdef clauses. This apparatus
    -    should be replaced with autoconf/automake machinery.
    -
    -    The SGI STL defines a type_traits<> template, specialized for
    -    many types in their code including the built-in numeric and
    -    pointer types and some library types, to direct optimizations of
    -    standard functions. The SGI compiler has been extended to generate
    -    specializations of this template automatically for user types,
    -    so that use of STL templates on user types can take advantage of
    -    these optimizations. Specializations for other, non-STL, types
    -    would make more optimizations possible, but extending the gcc
    -    compiler in the same way would be much better. Probably the next
    -    round of standardization will ratify this, but probably with
    -    changes, so it probably should be renamed to place it in the
    -    implementation namespace.
    -
    -    The SGI STL also defines a large number of extensions visible in
    -    standard headers. (Other extensions that appear in separate headers
    -    have been sequestered in subdirectories ext/ and backward/.)  All
    -    these extensions should be moved to other headers where possible,
    -    and in any case wrapped in a namespace (not std!), and (where kept
    -    in a standard header) girded about with macro guards. Some cannot be
    -    moved out of standard headers because they are used to implement
    -    standard features.  The canonical method for accommodating these
    -    is to use a protected name, aliased in macro guards to a user-space
    -    name. Unfortunately C++ offers no satisfactory template typedef
    -    mechanism, so very ad-hoc and unsatisfactory aliasing must be used
    -    instead.
    -
    -    Implementation of a template typedef mechanism should have the highest
    -    priority among possible extensions, on the same level as implementation
    -    of the template "export" feature.
    -
    -    Chapter 18  Language support
    -    ----------------------------
    -
    -    Headers: <limits> <new> <typeinfo> <exception>
    -    C headers: <cstddef> <climits> <cfloat>  <cstdarg> <csetjmp>
    -    <ctime>   <csignal> <cstdlib> (also 21, 25, 26)
    -
    -    This defines the built-in exceptions, rtti, numeric_limits<>,
    -    operator new and delete. Much of this is provided by the
    -    compiler in its static runtime library.
    -
    -    Work to do includes defining numeric_limits<> specializations in
    -    separate files for all target architectures. Values for integer types
    -    except for bool and wchar_t are readily obtained from the C header
    -    <limits.h>, but values for the remaining numeric types (bool, wchar_t,
    -    float, double, long double) must be entered manually. This is
    -    largely dog work except for those members whose values are not
    -    easily deduced from available documentation. Also, this involves
    -    some work in target configuration to identify the correct choice of
    -    file to build against and to install.
    -
    -    The definitions of the various operators new and delete must be
    -    made thread-safe, which depends on a portable exclusion mechanism,
    -    discussed under chapter 20.  Of course there is always plenty of
    -    room for improvements to the speed of operators new and delete.
    -
    -    <cstdarg>, in Glibc, defines some macros that gcc does not allow to
    -    be wrapped into an inline function. Probably this header will demand
    -    attention whenever a new target is chosen. The functions atexit(),
    -    exit(), and abort() in cstdlib have different semantics in C++, so
    -    must be re-implemented for C++.
    -
    -    Chapter 19  Diagnostics
    -    -----------------------
    -
    -    Headers: <stdexcept>
    -    C headers: <cassert> <cerrno>
    -
    -    This defines the standard exception objects, which are "mostly complete".
    -    Cygnus has a version, and now SGI provides a slightly different one.
    -    It makes little difference which we use.
    -
    -    The C global name "errno", which C allows to be a variable or a macro,
    -    is required in C++ to be a macro. For MT it must typically result in
    -    a function call.
    -
    -    Chapter 20  Utilities
    -    ---------------------
    -    Headers: <utility> <functional> <memory>
    -    C header: <ctime> (also in 18)
    -
    -    SGI STL provides "mostly complete" versions of all the components
    -    defined in this chapter. However, the auto_ptr<> implementation
    -    is known to be wrong. Furthermore, the standard definition of it
    -    is known to be unimplementable as written. A minor change to the
    -    standard would fix it, and auto_ptr<> should be adjusted to match.
    -
    -    Multi-threading affects the allocator implementation, and there must
    -    be configuration/installation choices for different users' MT
    -    requirements. Anyway, users will want to tune allocator options
    -    to support different target conditions, MT or no.
    -
    -    The primitives used for MT implementation should be exposed, as an
    -    extension, for users' own work. We need cross-CPU "mutex" support,
    -    multi-processor shared-memory atomic integer operations, and single-
    -    processor uninterruptible integer operations, and all three configurable
    -    to be stubbed out for non-MT use, or to use an appropriately-loaded
    -    dynamic library for the actual runtime environment, or statically
    -    compiled in for cases where the target architecture is known.
    -
    -    Chapter 21  String
    -    ------------------
    -    Headers: <string>
    -    C headers: <cctype> <cwctype> <cstring> <cwchar> (also in 27)
    -    <cstdlib> (also in 18, 25, 26)
    -
    -    We have "mostly-complete" char_traits<> implementations. Many of the
    -    char_traits<char> operations might be optimized further using existing
    -    proprietary language extensions.
    -
    -    We have a "mostly-complete" basic_string<> implementation. The work
    -    to manually instantiate char and wchar_t specializations in object
    -    files to improve link-time behavior is extremely unsatisfactory,
    -    literally tripling library-build time with no commensurate improvement
    -    in static program link sizes. It must be redone. (Similar work is
    -    needed for some components in chapters 22 and 27.)
    -
    -    Other work needed for strings is MT-safety, as discussed under the
    -    chapter 20 heading.
    -
    -    The standard C type mbstate_t from <cwchar> and used in char_traits<>
    -    must be different in C++ than in C, because in C++ the default constructor
    -    value mbstate_t() must be the "base" or "ground" sequence state.
    -    (According to the likely resolution of a recently raised Core issue,
    -    this may become unnecessary. However, there are other reasons to
    -    use a state type not as limited as whatever the C library provides.)
    -    If we might want to provide conversions from (e.g.) internally-
    -    represented EUC-wide to externally-represented Unicode, or vice-
    -    versa, the mbstate_t we choose will need to be more accommodating
    -    than what might be provided by an underlying C library.
    -
    -    There remain some basic_string template-member functions which do
    -    not overload properly with their non-template brethren. The infamous
    -    hack akin to what was done in vector<> is needed, to conform to
    -    23.1.1 para 10. The CHECKLIST items for basic_string marked 'X',
    -    or incomplete, are so marked for this reason.
    -
    -    Replacing the string iterators, which currently are simple character
    -    pointers, with class objects would greatly increase the safety of the
    -    client interface, and also permit a "debug" mode in which range,
    -    ownership, and validity are rigorously checked. The current use of
    -    raw pointers as string iterators is evil. vector<> iterators need the
    -    same treatment. Note that the current implementation freely mixes
    -    pointers and iterators, and that must be fixed before safer iterators
    -    can be introduced.
    -
    -    Some of the functions in <cstring> are different from the C version.
    -    generally overloaded on const and non-const argument pointers. For
    -    example, in <cstring> strchr is overloaded. The functions isupper
    -    etc. in <cctype> typically implemented as macros in C are functions
    -    in C++, because they are overloaded with others of the same name
    -    defined in <locale>.
    -
    -    Many of the functions required in <cwctype> and <cwchar> cannot be
    -    implemented using underlying C facilities on intended targets because
    -    such facilities only partly exist.
    -
    -    Chapter 22  Locale
    -    ------------------
    -    Headers: <locale>
    -    C headers: <clocale>
    -
    -    We have a "mostly complete" class locale, with the exception of
    -    code for constructing, and handling the names of, named locales.
    -    The ways that locales are named (particularly when categories
    -    (e.g. LC_TIME, LC_COLLATE) are different) varies among all target
    -    environments. This code must be written in various versions and
    -    chosen by configuration parameters.
    -
    -    Members of many of the facets defined in <locale> are stubs. Generally,
    -    there are two sets of facets: the base class facets (which are supposed
    -    to implement the "C" locale) and the "byname" facets, which are supposed
    -    to read files to determine their behavior. The base ctype<>, collate<>,
    -    and numpunct<> facets are "mostly complete", except that the table of
    -    bitmask values used for "is" operations, and corresponding mask values,
    -    are still defined in libio and just included/linked. (We will need to
    -    implement these tables independently, soon, but should take advantage
    -    of libio where possible.)  The num_put<>::put members for integer types
    -    are "mostly complete".
    -
    -    A complete list of what has and has not been implemented may be
    -    found in CHECKLIST. However, note that the current definition of
    -    codecvt<wchar_t,char,mbstate_t> is wrong. It should simply write
    -    out the raw bytes representing the wide characters, rather than
    -    trying to convert each to a corresponding single "char" value.
    -
    -    Some of the facets are more important than others. Specifically,
    -    the members of ctype<>, numpunct<>, num_put<>, and num_get<> facets
    -    are used by other library facilities defined in <string>, <istream>,
    -    and <ostream>, and the codecvt<> facet is used by basic_filebuf<>
    -    in <fstream>, so a conforming iostream implementation depends on
    -    these.
    -
    -    The "long long" type eventually must be supported, but code mentioning
    -    it should be wrapped in #if guards to allow pedantic-mode compiling.
    -
    -    Performance of num_put<> and num_get<> depend critically on
    -    caching computed values in ios_base objects, and on extensions
    -    to the interface with streambufs.
    -
    -    Specifically: retrieving a copy of the locale object, extracting
    -    the needed facets, and gathering data from them, for each call to
    -    (e.g.) operator<< would be prohibitively slow.  To cache format
    -    data for use by num_put<> and num_get<> we have a _Format_cache<>
    -    object stored in the ios_base::pword() array. This is constructed
    -    and initialized lazily, and is organized purely for utility. It
    -    is discarded when a new locale with different facets is imbued.
    -
    -    Using only the public interfaces of the iterator arguments to the
    -    facet functions would limit performance by forbidding "vector-style"
    -    character operations. The streambuf iterator optimizations are
    -    described under chapter 24, but facets can also bypass the streambuf
    -    iterators via explicit specializations and operate directly on the
    -    streambufs, and use extended interfaces to get direct access to the
    -    streambuf internal buffer arrays. These extensions are mentioned
    -    under chapter 27. These optimizations are particularly important
    -    for input parsing.
    -
    -    Unused virtual members of locale facets can be omitted, as mentioned
    -    above, by a smart linker.
    -
    -    Chapter 23  Containers
    -    ----------------------
    -    Headers: <deque> <list> <queue> <stack> <vector> <map> <set> <bitset>
    -
    -    All the components in chapter 23 are implemented in the SGI STL.
    -    They are "mostly complete"; they include a large number of
    -    nonconforming extensions which must be wrapped. Some of these
    -    are used internally and must be renamed or duplicated.
    -
    -    The SGI components are optimized for large-memory environments. For
    -    embedded targets, different criteria might be more appropriate. Users
    -    will want to be able to tune this behavior. We should provide
    -    ways for users to compile the library with different memory usage
    -    characteristics.
    -
    -    A lot more work is needed on factoring out common code from different
    -    specializations to reduce code size here and in chapter 25. The
    -    easiest fix for this would be a compiler/ABI improvement that allows
    -    the compiler to recognize when a specialization depends only on the
    -    size (or other gross quality) of a template argument, and allow the
    -    linker to share the code with similar specializations. In its
    -    absence, many of the algorithms and containers can be partial-
    -    specialized, at least for the case of pointers, but this only solves
    -    a small part of the problem. Use of a type_traits-style template
    -    allows a few more optimization opportunities, more if the compiler
    -    can generate the specializations automatically.
    -
    -    As an optimization, containers can specialize on the default allocator
    -    and bypass it, or take advantage of details of its implementation
    -    after it has been improved upon.
    -
    -    Replacing the vector iterators, which currently are simple element
    -    pointers, with class objects would greatly increase the safety of the
    -    client interface, and also permit a "debug" mode in which range,
    -    ownership, and validity are rigorously checked. The current use of
    -    pointers for iterators is evil.
    -
    -    As mentioned for chapter 24, the deque iterator is a good example of
    -    an opportunity to implement a "staged" iterator that would benefit
    -    from specializations of some algorithms.
    -
    -    Chapter 24  Iterators
    -    ---------------------
    -    Headers: <iterator>
    -
    -    Standard iterators are "mostly complete", with the exception of
    -    the stream iterators, which are not yet templatized on the
    -    stream type. Also, the base class template iterator<> appears
    -    to be wrong, so everything derived from it must also be wrong,
    -    currently.
    -
    -    The streambuf iterators (currently located in stl/bits/std_iterator.h,
    -    but should be under bits/) can be rewritten to take advantage of
    -    friendship with the streambuf implementation.
    -
    -    Matt Austern has identified opportunities where certain iterator
    -    types, particularly including streambuf iterators and deque
    -    iterators, have a "two-stage" quality, such that an intermediate
    -    limit can be checked much more quickly than the true limit on
    -    range operations. If identified with a member of iterator_traits,
    -    algorithms may be specialized for this case. Of course the
    -    iterators that have this quality can be identified by specializing
    -    a traits class.
    -
    -    Many of the algorithms must be specialized for the streambuf
    -    iterators, to take advantage of block-mode operations, in order
    -    to allow iostream/locale operations' performance not to suffer.
    -    It may be that they could be treated as staged iterators and
    -    take advantage of those optimizations.
    -
    -    Chapter 25  Algorithms
    -    ----------------------
    -    Headers: <algorithm>
    -    C headers: <cstdlib> (also in 18, 21, 26))
    -
    -    The algorithms are "mostly complete". As mentioned above, they
    -    are optimized for speed at the expense of code and data size.
    -
    -    Specializations of many of the algorithms for non-STL types would
    -    give performance improvements, but we must use great care not to
    -    interfere with fragile template overloading semantics for the
    -    standard interfaces. Conventionally the standard function template
    -    interface is an inline which delegates to a non-standard function
    -    which is then overloaded (this is already done in many places in
    -    the library). Particularly appealing opportunities for the sake of
    -    iostream performance are for copy and find applied to streambuf
    -    iterators or (as noted elsewhere) for staged iterators, of which
    -    the streambuf iterators are a good example.
    -
    -    The bsearch and qsort functions cannot be overloaded properly as
    -    required by the standard because gcc does not yet allow overloading
    -    on the extern-"C"-ness of a function pointer.
    -
    -    Chapter 26  Numerics
    -    --------------------
    -    Headers: <complex> <valarray> <numeric>
    -    C headers: <cmath>, <cstdlib> (also 18, 21, 25)
    -
    -    Numeric components: Gabriel dos Reis's valarray, Drepper's complex,
    -    and the few algorithms from the STL are "mostly done".  Of course
    -    optimization opportunities abound for the numerically literate. It
    -    is not clear whether the valarray implementation really conforms
    -    fully, in the assumptions it makes about aliasing (and lack thereof)
    -    in its arguments.
    -
    -    The C div() and ldiv() functions are interesting, because they are the
    -    only case where a C library function returns a class object by value.
    -    Since the C++ type div_t must be different from the underlying C type
    -    (which is in the wrong namespace) the underlying functions div() and
    -    ldiv() cannot be re-used efficiently. Fortunately they are trivial to
    -    re-implement.
    -
    -    Chapter 27  Iostreams
    -    ---------------------
    -    Headers: <iosfwd> <streambuf> <ios> <ostream> <istream> <iostream>
    -    <iomanip> <sstream> <fstream>
    -    C headers: <cstdio> <cwchar> (also in 21)
    -
    -    Iostream is currently in a very incomplete state. <iosfwd>, <iomanip>,
    -    ios_base, and basic_ios<> are "mostly complete". basic_streambuf<> and
    -    basic_ostream<> are well along, but basic_istream<> has had little work
    -    done. The standard stream objects, <sstream> and <fstream> have been
    -    started; basic_filebuf<> "write" functions have been implemented just
    -    enough to do "hello, world".
    -
    -    Most of the istream and ostream operators << and >> (with the exception
    -    of the op<<(integer) ones) have not been changed to use locale primitives,
    -    sentry objects, or char_traits members.
    -
    -    All these templates should be manually instantiated for char and
    -    wchar_t in a way that links only used members into user programs.
    -
    -    Streambuf is fertile ground for optimization extensions. An extended
    -    interface giving iterator access to its internal buffer would be very
    -    useful for other library components.
    -
    -    Iostream operations (primarily operators << and >>) can take advantage
    -    of the case where user code has not specified a locale, and bypass locale
    -    operations entirely. The current implementation of op<</num_put<>::put,
    -    for the integer types, demonstrates how they can cache encoding details
    -    from the locale on each operation. There is lots more room for
    -    optimization in this area.
    -
    -    The definition of the relationship between the standard streams
    -    cout et al. and stdout et al. requires something like a "stdiobuf".
    -    The SGI solution of using double-indirection to actually use a
    -    stdio FILE object for buffering is unsatisfactory, because it
    -    interferes with peephole loop optimizations.
    -
    -    The <sstream> header work has begun. stringbuf can benefit from
    -    friendship with basic_string<> and basic_string<>::_Rep to use
    -    those objects directly as buffers, and avoid allocating and making
    -    copies.
    -
    -    The basic_filebuf<> template is a complex beast. It is specified to
    -    use the locale facet codecvt<> to translate characters between native
    -    files and the locale character encoding. In general this involves
    -    two buffers, one of "char" representing the file and another of
    -    "char_type", for the stream, with codecvt<> translating. The process
    -    is complicated by the variable-length nature of the translation, and
    -    the need to seek to corresponding places in the two representations.
    -    For the case of basic_filebuf<char>, when no translation is needed,
    -    a single buffer suffices. A specialized filebuf can be used to reduce
    -    code space overhead when no locale has been imbued. Matt Austern's
    -    work at SGI will be useful, perhaps directly as a source of code, or
    -    at least as an example to draw on.
    -
    -    Filebuf, almost uniquely (cf. operator new), depends heavily on
    -    underlying environmental facilities. In current releases iostream
    -    depends fairly heavily on libio constant definitions, but it should
    -    be made independent.  It also depends on operating system primitives
    -    for file operations. There is immense room for optimizations using
    -    (e.g.) mmap for reading. The shadow/ directory wraps, besides the
    -    standard C headers, the libio.h and unistd.h headers, for use mainly
    -    by filebuf. These wrappings have not been completed, though there
    -    is scaffolding in place.
    -
    -    The encapsulation of certain C header <cstdio> names presents an
    -    interesting problem. It is possible to define an inline std::fprintf()
    -    implemented in terms of the 'extern "C"' vfprintf(), but there is no
    -    standard vfscanf() to use to implement std::fscanf(). It appears that
    -    vfscanf but be re-implemented in C++ for targets where no vfscanf
    -    extension has been defined. This is interesting in that it seems
    -    to be the only significant case in the C library where this kind of
    -    rewriting is necessary. (Of course Glibc provides the vfscanf()
    -    extension.)  (The functions related to exit() must be rewritten
    -    for other reasons.)
    -
    -
    -    Annex D
    -    -------
    -    Headers: <strstream>
    -
    -    Annex D defines many non-library features, and many minor
    -    modifications to various headers, and a complete header.
    -    It is "mostly done", except that the libstdc++-2 <strstream>
    -    header has not been adopted into the library, or checked to
    -    verify that it matches the draft in those details that were
    -    clarified by the committee. Certainly it must at least be
    -    moved into the std namespace.
    -
    -    We still need to wrap all the deprecated features in #if guards
    -    so that pedantic compile modes can detect their use.
    -
    -    Nonstandard Extensions
    -    ----------------------
    -    Headers: <iostream.h> <strstream.h> <hash> <rbtree>
    -    <pthread_alloc> <stdiobuf> (etc.)
    -
    -    User code has come to depend on a variety of nonstandard components
    -    that we must not omit. Much of this code can be adopted from
    -    libstdc++-v2 or from the SGI STL. This particularly includes
    -    <iostream.h>, <strstream.h>, and various SGI extensions such
    -    as <hash_map.h>. Many of these are already placed in the
    -    subdirectories ext/ and backward/. (Note that it is better to
    -    include them via "<backward/hash_map.h>" or "<ext/hash_map>" than
    -    to search the subdirectory itself via a "-I" directive.
    -  

    Prev Up Next
    Coding Style Home Appendix B.  + Next

    Design Notes

    +


    +
    +    The Library
    +    -----------
    +
    +    This paper is covers two major areas:
    +
    +    - Features and policies not mentioned in the standard that
    +    the quality of the library implementation depends on, including
    +    extensions and "implementation-defined" features;
    +
    +    - Plans for required but unimplemented library features and
    +    optimizations to them.
    +
    +    Overhead
    +    --------
    +
    +    The standard defines a large library, much larger than the standard
    +    C library. A naive implementation would suffer substantial overhead
    +    in compile time, executable size, and speed, rendering it unusable
    +    in many (particularly embedded) applications. The alternative demands
    +    care in construction, and some compiler support, but there is no
    +    need for library subsets.
    +
    +    What are the sources of this overhead?  There are four main causes:
    +
    +    - The library is specified almost entirely as templates, which
    +    with current compilers must be included in-line, resulting in
    +    very slow builds as tens or hundreds of thousands of lines
    +    of function definitions are read for each user source file.
    +    Indeed, the entire SGI STL, as well as the dos Reis valarray,
    +    are provided purely as header files, largely for simplicity in
    +    porting. Iostream/locale is (or will be) as large again.
    +
    +    - The library is very flexible, specifying a multitude of hooks
    +    where users can insert their own code in place of defaults.
    +    When these hooks are not used, any time and code expended to
    +    support that flexibility is wasted.
    +
    +    - Templates are often described as causing to "code bloat". In
    +    practice, this refers (when it refers to anything real) to several
    +    independent processes. First, when a class template is manually
    +    instantiated in its entirely, current compilers place the definitions
    +    for all members in a single object file, so that a program linking
    +    to one member gets definitions of all. Second, template functions
    +    which do not actually depend on the template argument are, under
    +    current compilers, generated anew for each instantiation, rather
    +    than being shared with other instantiations. Third, some of the
    +    flexibility mentioned above comes from virtual functions (both in
    +    regular classes and template classes) which current linkers add
    +    to the executable file even when they manifestly cannot be called.
    +
    +    - The library is specified to use a language feature, exceptions,
    +    which in the current gcc compiler ABI imposes a run time and
    +    code space cost to handle the possibility of exceptions even when
    +    they are not used. Under the new ABI (accessed with -fnew-abi),
    +    there is a space overhead and a small reduction in code efficiency
    +    resulting from lost optimization opportunities associated with
    +    non-local branches associated with exceptions.
    +
    +    What can be done to eliminate this overhead?  A variety of coding
    +    techniques, and compiler, linker and library improvements and
    +    extensions may be used, as covered below. Most are not difficult,
    +    and some are already implemented in varying degrees.
    +
    +    Overhead: Compilation Time
    +    --------------------------
    +
    +    Providing "ready-instantiated" template code in object code archives
    +    allows us to avoid generating and optimizing template instantiations
    +    in each compilation unit which uses them. However, the number of such
    +    instantiations that are useful to provide is limited, and anyway this
    +    is not enough, by itself, to minimize compilation time. In particular,
    +    it does not reduce time spent parsing conforming headers.
    +
    +    Quicker header parsing will depend on library extensions and compiler
    +    improvements.  One approach is some variation on the techniques
    +    previously marketed as "pre-compiled headers", now standardized as
    +    support for the "export" keyword. "Exported" template definitions
    +    can be placed (once) in a "repository" -- really just a library, but
    +    of template definitions rather than object code -- to be drawn upon
    +    at link time when an instantiation is needed, rather than placed in
    +    header files to be parsed along with every compilation unit.
    +
    +    Until "export" is implemented we can put some of the lengthy template
    +    definitions in #if guards or alternative headers so that users can skip
    +    over the full definitions when they need only the ready-instantiated
    +    specializations.
    +
    +    To be precise, this means that certain headers which define
    +    templates which users normally use only for certain arguments
    +    can be instrumented to avoid exposing the template definitions
    +    to the compiler unless a macro is defined. For example, in
    +    <string>, we might have:
    +
    +    template <class _CharT, ... > class basic_string {
    +    ... // member declarations
    +    };
    +    ... // operator declarations
    +
    +    #ifdef _STRICT_ISO_
    +    # if _G_NO_TEMPLATE_EXPORT
    +    #   include <bits/std_locale.h>  // headers needed by definitions
    +    #   ...
    +    #   include <bits/string.tcc>  // member and global template definitions.
    +    # endif
    +    #endif
    +
    +    Users who compile without specifying a strict-ISO-conforming flag
    +    would not see many of the template definitions they now see, and rely
    +    instead on ready-instantiated specializations in the library. This
    +    technique would be useful for the following substantial components:
    +    string, locale/iostreams, valarray. It would *not* be useful or
    +    usable with the following: containers, algorithms, iterators,
    +    allocator. Since these constitute a large (though decreasing)
    +    fraction of the library, the benefit the technique offers is
    +    limited.
    +
    +    The language specifies the semantics of the "export" keyword, but
    +    the gcc compiler does not yet support it. When it does, problems
    +    with large template inclusions can largely disappear, given some
    +    minor library reorganization, along with the need for the apparatus
    +    described above.
    +
    +    Overhead: Flexibility Cost
    +    --------------------------
    +
    +    The library offers many places where users can specify operations
    +    to be performed by the library in place of defaults. Sometimes
    +    this seems to require that the library use a more-roundabout, and
    +    possibly slower, way to accomplish the default requirements than
    +    would be used otherwise.
    +
    +    The primary protection against this overhead is thorough compiler
    +    optimization, to crush out layers of inline function interfaces.
    +    Kuck & Associates has demonstrated the practicality of this kind
    +    of optimization.
    +
    +    The second line of defense against this overhead is explicit
    +    specialization. By defining helper function templates, and writing
    +    specialized code for the default case, overhead can be eliminated
    +    for that case without sacrificing flexibility. This takes full
    +    advantage of any ability of the optimizer to crush out degenerate
    +    code.
    +
    +    The library specifies many virtual functions which current linkers
    +    load even when they cannot be called. Some minor improvements to the
    +    compiler and to ld would eliminate any such overhead by simply
    +    omitting virtual functions that the complete program does not call.
    +    A prototype of this work has already been done. For targets where
    +    GNU ld is not used, a "pre-linker" could do the same job.
    +
    +    The main areas in the standard interface where user flexibility
    +    can result in overhead are:
    +
    +    - Allocators:  Containers are specified to use user-definable
    +    allocator types and objects, making tuning for the container
    +    characteristics tricky.
    +
    +    - Locales: the standard specifies locale objects used to implement
    +    iostream operations, involving many virtual functions which use
    +    streambuf iterators.
    +
    +    - Algorithms and containers: these may be instantiated on any type,
    +    frequently duplicating code for identical operations.
    +
    +    - Iostreams and strings: users are permitted to use these on their
    +    own types, and specify the operations the stream must use on these
    +    types.
    +
    +    Note that these sources of overhead are _avoidable_. The techniques
    +    to avoid them are covered below.
    +
    +    Code Bloat
    +    ----------
    +
    +    In the SGI STL, and in some other headers, many of the templates
    +    are defined "inline" -- either explicitly or by their placement
    +    in class definitions -- which should not be inline. This is a
    +    source of code bloat. Matt had remarked that he was relying on
    +    the compiler to recognize what was too big to benefit from inlining,
    +    and generate it out-of-line automatically. However, this also can
    +    result in code bloat except where the linker can eliminate the extra
    +    copies.
    +
    +    Fixing these cases will require an audit of all inline functions
    +    defined in the library to determine which merit inlining, and moving
    +    the rest out of line. This is an issue mainly in chapters 23, 25, and
    +    27. Of course it can be done incrementally, and we should generally
    +    accept patches that move large functions out of line and into ".tcc"
    +    files, which can later be pulled into a repository. Compiler/linker
    +    improvements to recognize very large inline functions and move them
    +    out-of-line, but shared among compilation units, could make this
    +    work unnecessary.
    +
    +    Pre-instantiating template specializations currently produces large
    +    amounts of dead code which bloats statically linked programs. The
    +    current state of the static library, libstdc++.a, is intolerable on
    +    this account, and will fuel further confused speculation about a need
    +    for a library "subset". A compiler improvement that treats each
    +    instantiated function as a separate object file, for linking purposes,
    +    would be one solution to this problem. An alternative would be to
    +    split up the manual instantiation files into dozens upon dozens of
    +    little files, each compiled separately, but an abortive attempt at
    +    this was done for <string> and, though it is far from complete, it
    +    is already a nuisance. A better interim solution (just until we have
    +    "export") is badly needed.
    +
    +    When building a shared library, the current compiler/linker cannot
    +    automatically generate the instantiations needed. This creates a
    +    miserable situation; it means any time something is changed in the
    +    library, before a shared library can be built someone must manually
    +    copy the declarations of all templates that are needed by other parts
    +    of the library to an "instantiation" file, and add it to the build
    +    system to be compiled and linked to the library. This process is
    +    readily automated, and should be automated as soon as possible.
    +    Users building their own shared libraries experience identical
    +    frustrations.
    +
    +    Sharing common aspects of template definitions among instantiations
    +    can radically reduce code bloat. The compiler could help a great
    +    deal here by recognizing when a function depends on nothing about
    +    a template parameter, or only on its size, and giving the resulting
    +    function a link-name "equate" that allows it to be shared with other
    +    instantiations. Implementation code could take advantage of the
    +    capability by factoring out code that does not depend on the template
    +    argument into separate functions to be merged by the compiler.
    +
    +    Until such a compiler optimization is implemented, much can be done
    +    manually (if tediously) in this direction. One such optimization is
    +    to derive class templates from non-template classes, and move as much
    +    implementation as possible into the base class. Another is to partial-
    +    specialize certain common instantiations, such as vector<T*>, to share
    +    code for instantiations on all types T. While these techniques work,
    +    they are far from the complete solution that a compiler improvement
    +    would afford.
    +
    +    Overhead: Expensive Language Features
    +    -------------------------------------
    +
    +    The main "expensive" language feature used in the standard library
    +    is exception support, which requires compiling in cleanup code with
    +    static table data to locate it, and linking in library code to use
    +    the table. For small embedded programs the amount of such library
    +    code and table data is assumed by some to be excessive. Under the
    +    "new" ABI this perception is generally exaggerated, although in some
    +    cases it may actually be excessive.
    +
    +    To implement a library which does not use exceptions directly is
    +    not difficult given minor compiler support (to "turn off" exceptions
    +    and ignore exception constructs), and results in no great library
    +    maintenance difficulties. To be precise, given "-fno-exceptions",
    +    the compiler should treat "try" blocks as ordinary blocks, and
    +    "catch" blocks as dead code to ignore or eliminate. Compiler
    +    support is not strictly necessary, except in the case of "function
    +    try blocks"; otherwise the following macros almost suffice:
    +
    +    #define throw(X)
    +    #define try      if (true)
    +    #define catch(X) else if (false)
    +
    +    However, there may be a need to use function try blocks in the
    +    library implementation, and use of macros in this way can make
    +    correct diagnostics impossible. Furthermore, use of this scheme
    +    would require the library to call a function to re-throw exceptions
    +    from a try block. Implementing the above semantics in the compiler
    +    is preferable.
    +
    +    Given the support above (however implemented) it only remains to
    +    replace code that "throws" with a call to a well-documented "handler"
    +    function in a separate compilation unit which may be replaced by
    +    the user. The main source of exceptions that would be difficult
    +    for users to avoid is memory allocation failures, but users can
    +    define their own memory allocation primitives that never throw.
    +    Otherwise, the complete list of such handlers, and which library
    +    functions may call them, would be needed for users to be able to
    +    implement the necessary substitutes. (Fortunately, they have the
    +    source code.)
    +
    +    Opportunities
    +    -------------
    +
    +    The template capabilities of C++ offer enormous opportunities for
    +    optimizing common library operations, well beyond what would be
    +    considered "eliminating overhead". In particular, many operations
    +    done in Glibc with macros that depend on proprietary language
    +    extensions can be implemented in pristine Standard C++. For example,
    +    the chapter 25 algorithms, and even C library functions such as strchr,
    +    can be specialized for the case of static arrays of known (small) size.
    +
    +    Detailed optimization opportunities are identified below where
    +    the component where they would appear is discussed. Of course new
    +    opportunities will be identified during implementation.
    +
    +    Unimplemented Required Library Features
    +    ---------------------------------------
    +
    +    The standard specifies hundreds of components, grouped broadly by
    +    chapter. These are listed in excruciating detail in the CHECKLIST
    +    file.
    +
    +    17 general
    +    18 support
    +    19 diagnostics
    +    20 utilities
    +    21 string
    +    22 locale
    +    23 containers
    +    24 iterators
    +    25 algorithms
    +    26 numerics
    +    27 iostreams
    +    Annex D  backward compatibility
    +
    +    Anyone participating in implementation of the library should obtain
    +    a copy of the standard, ISO 14882.  People in the U.S. can obtain an
    +    electronic copy for US$18 from ANSI's web site. Those from other
    +    countries should visit http://www.iso.org/ to find out the location
    +    of their country's representation in ISO, in order to know who can
    +    sell them a copy.
    +
    +    The emphasis in the following sections is on unimplemented features
    +    and optimization opportunities.
    +
    +    Chapter 17  General
    +    -------------------
    +
    +    Chapter 17 concerns overall library requirements.
    +
    +    The standard doesn't mention threads. A multi-thread (MT) extension
    +    primarily affects operators new and delete (18), allocator (20),
    +    string (21), locale (22), and iostreams (27). The common underlying
    +    support needed for this is discussed under chapter 20.
    +
    +    The standard requirements on names from the C headers create a
    +    lot of work, mostly done. Names in the C headers must be visible
    +    in the std:: and sometimes the global namespace; the names in the
    +    two scopes must refer to the same object. More stringent is that
    +    Koenig lookup implies that any types specified as defined in std::
    +    really are defined in std::. Names optionally implemented as
    +    macros in C cannot be macros in C++. (An overview may be read at
    +    <http://www.cantrip.org/cheaders.html>). The scripts "inclosure"
    +    and "mkcshadow", and the directories shadow/ and cshadow/, are the
    +    beginning of an effort to conform in this area.
    +
    +    A correct conforming definition of C header names based on underlying
    +    C library headers, and practical linking of conforming namespaced
    +    customer code with third-party C libraries depends ultimately on
    +    an ABI change, allowing namespaced C type names to be mangled into
    +    type names as if they were global, somewhat as C function names in a
    +    namespace, or C++ global variable names, are left unmangled. Perhaps
    +    another "extern" mode, such as 'extern "C-global"' would be an
    +    appropriate place for such type definitions. Such a type would
    +    affect mangling as follows:
    +
    +    namespace A {
    +    struct X {};
    +    extern "C-global" {  // or maybe just 'extern "C"'
    +    struct Y {};
    +    };
    +    }
    +    void f(A::X*);  // mangles to f__FPQ21A1X
    +    void f(A::Y*);  // mangles to f__FP1Y
    +
    +    (It may be that this is really the appropriate semantics for regular
    +    'extern "C"', and 'extern "C-global"', as an extension, would not be
    +    necessary.) This would allow functions declared in non-standard C headers
    +    (and thus fixable by neither us nor users) to link properly with functions
    +    declared using C types defined in properly-namespaced headers. The
    +    problem this solves is that C headers (which C++ programmers do persist
    +    in using) frequently forward-declare C struct tags without including
    +    the header where the type is defined, as in
    +
    +    struct tm;
    +    void munge(tm*);
    +
    +    Without some compiler accommodation, munge cannot be called by correct
    +    C++ code using a pointer to a correctly-scoped tm* value.
    +
    +    The current C headers use the preprocessor extension "#include_next",
    +    which the compiler complains about when run "-pedantic".
    +    (Incidentally, it appears that "-fpedantic" is currently ignored,
    +    probably a bug.)  The solution in the C compiler is to use
    +    "-isystem" rather than "-I", but unfortunately in g++ this seems
    +    also to wrap the whole header in an 'extern "C"' block, so it's
    +    unusable for C++ headers. The correct solution appears to be to
    +    allow the various special include-directory options, if not given
    +    an argument, to affect subsequent include-directory options additively,
    +    so that if one said
    +
    +    -pedantic -iprefix $(prefix) \
    +    -idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \
    +    -iwithprefix -I g++-v3/ext
    +
    +    the compiler would search $(prefix)/g++-v3 and not report
    +    pedantic warnings for files found there, but treat files in
    +    $(prefix)/g++-v3/ext pedantically. (The undocumented semantics
    +    of "-isystem" in g++ stink. Can they be rescinded?  If not it
    +    must be replaced with something more rationally behaved.)
    +
    +    All the C headers need the treatment above; in the standard these
    +    headers are mentioned in various chapters. Below, I have only
    +    mentioned those that present interesting implementation issues.
    +
    +    The components identified as "mostly complete", below, have not been
    +    audited for conformance. In many cases where the library passes
    +    conformance tests we have non-conforming extensions that must be
    +    wrapped in #if guards for "pedantic" use, and in some cases renamed
    +    in a conforming way for continued use in the implementation regardless
    +    of conformance flags.
    +
    +    The STL portion of the library still depends on a header
    +    stl/bits/stl_config.h full of #ifdef clauses. This apparatus
    +    should be replaced with autoconf/automake machinery.
    +
    +    The SGI STL defines a type_traits<> template, specialized for
    +    many types in their code including the built-in numeric and
    +    pointer types and some library types, to direct optimizations of
    +    standard functions. The SGI compiler has been extended to generate
    +    specializations of this template automatically for user types,
    +    so that use of STL templates on user types can take advantage of
    +    these optimizations. Specializations for other, non-STL, types
    +    would make more optimizations possible, but extending the gcc
    +    compiler in the same way would be much better. Probably the next
    +    round of standardization will ratify this, but probably with
    +    changes, so it probably should be renamed to place it in the
    +    implementation namespace.
    +
    +    The SGI STL also defines a large number of extensions visible in
    +    standard headers. (Other extensions that appear in separate headers
    +    have been sequestered in subdirectories ext/ and backward/.)  All
    +    these extensions should be moved to other headers where possible,
    +    and in any case wrapped in a namespace (not std!), and (where kept
    +    in a standard header) girded about with macro guards. Some cannot be
    +    moved out of standard headers because they are used to implement
    +    standard features.  The canonical method for accommodating these
    +    is to use a protected name, aliased in macro guards to a user-space
    +    name. Unfortunately C++ offers no satisfactory template typedef
    +    mechanism, so very ad-hoc and unsatisfactory aliasing must be used
    +    instead.
    +
    +    Implementation of a template typedef mechanism should have the highest
    +    priority among possible extensions, on the same level as implementation
    +    of the template "export" feature.
    +
    +    Chapter 18  Language support
    +    ----------------------------
    +
    +    Headers: <limits> <new> <typeinfo> <exception>
    +    C headers: <cstddef> <climits> <cfloat>  <cstdarg> <csetjmp>
    +    <ctime>   <csignal> <cstdlib> (also 21, 25, 26)
    +
    +    This defines the built-in exceptions, rtti, numeric_limits<>,
    +    operator new and delete. Much of this is provided by the
    +    compiler in its static runtime library.
    +
    +    Work to do includes defining numeric_limits<> specializations in
    +    separate files for all target architectures. Values for integer types
    +    except for bool and wchar_t are readily obtained from the C header
    +    <limits.h>, but values for the remaining numeric types (bool, wchar_t,
    +    float, double, long double) must be entered manually. This is
    +    largely dog work except for those members whose values are not
    +    easily deduced from available documentation. Also, this involves
    +    some work in target configuration to identify the correct choice of
    +    file to build against and to install.
    +
    +    The definitions of the various operators new and delete must be
    +    made thread-safe, which depends on a portable exclusion mechanism,
    +    discussed under chapter 20.  Of course there is always plenty of
    +    room for improvements to the speed of operators new and delete.
    +
    +    <cstdarg>, in Glibc, defines some macros that gcc does not allow to
    +    be wrapped into an inline function. Probably this header will demand
    +    attention whenever a new target is chosen. The functions atexit(),
    +    exit(), and abort() in cstdlib have different semantics in C++, so
    +    must be re-implemented for C++.
    +
    +    Chapter 19  Diagnostics
    +    -----------------------
    +
    +    Headers: <stdexcept>
    +    C headers: <cassert> <cerrno>
    +
    +    This defines the standard exception objects, which are "mostly complete".
    +    Cygnus has a version, and now SGI provides a slightly different one.
    +    It makes little difference which we use.
    +
    +    The C global name "errno", which C allows to be a variable or a macro,
    +    is required in C++ to be a macro. For MT it must typically result in
    +    a function call.
    +
    +    Chapter 20  Utilities
    +    ---------------------
    +    Headers: <utility> <functional> <memory>
    +    C header: <ctime> (also in 18)
    +
    +    SGI STL provides "mostly complete" versions of all the components
    +    defined in this chapter. However, the auto_ptr<> implementation
    +    is known to be wrong. Furthermore, the standard definition of it
    +    is known to be unimplementable as written. A minor change to the
    +    standard would fix it, and auto_ptr<> should be adjusted to match.
    +
    +    Multi-threading affects the allocator implementation, and there must
    +    be configuration/installation choices for different users' MT
    +    requirements. Anyway, users will want to tune allocator options
    +    to support different target conditions, MT or no.
    +
    +    The primitives used for MT implementation should be exposed, as an
    +    extension, for users' own work. We need cross-CPU "mutex" support,
    +    multi-processor shared-memory atomic integer operations, and single-
    +    processor uninterruptible integer operations, and all three configurable
    +    to be stubbed out for non-MT use, or to use an appropriately-loaded
    +    dynamic library for the actual runtime environment, or statically
    +    compiled in for cases where the target architecture is known.
    +
    +    Chapter 21  String
    +    ------------------
    +    Headers: <string>
    +    C headers: <cctype> <cwctype> <cstring> <cwchar> (also in 27)
    +    <cstdlib> (also in 18, 25, 26)
    +
    +    We have "mostly-complete" char_traits<> implementations. Many of the
    +    char_traits<char> operations might be optimized further using existing
    +    proprietary language extensions.
    +
    +    We have a "mostly-complete" basic_string<> implementation. The work
    +    to manually instantiate char and wchar_t specializations in object
    +    files to improve link-time behavior is extremely unsatisfactory,
    +    literally tripling library-build time with no commensurate improvement
    +    in static program link sizes. It must be redone. (Similar work is
    +    needed for some components in chapters 22 and 27.)
    +
    +    Other work needed for strings is MT-safety, as discussed under the
    +    chapter 20 heading.
    +
    +    The standard C type mbstate_t from <cwchar> and used in char_traits<>
    +    must be different in C++ than in C, because in C++ the default constructor
    +    value mbstate_t() must be the "base" or "ground" sequence state.
    +    (According to the likely resolution of a recently raised Core issue,
    +    this may become unnecessary. However, there are other reasons to
    +    use a state type not as limited as whatever the C library provides.)
    +    If we might want to provide conversions from (e.g.) internally-
    +    represented EUC-wide to externally-represented Unicode, or vice-
    +    versa, the mbstate_t we choose will need to be more accommodating
    +    than what might be provided by an underlying C library.
    +
    +    There remain some basic_string template-member functions which do
    +    not overload properly with their non-template brethren. The infamous
    +    hack akin to what was done in vector<> is needed, to conform to
    +    23.1.1 para 10. The CHECKLIST items for basic_string marked 'X',
    +    or incomplete, are so marked for this reason.
    +
    +    Replacing the string iterators, which currently are simple character
    +    pointers, with class objects would greatly increase the safety of the
    +    client interface, and also permit a "debug" mode in which range,
    +    ownership, and validity are rigorously checked. The current use of
    +    raw pointers as string iterators is evil. vector<> iterators need the
    +    same treatment. Note that the current implementation freely mixes
    +    pointers and iterators, and that must be fixed before safer iterators
    +    can be introduced.
    +
    +    Some of the functions in <cstring> are different from the C version.
    +    generally overloaded on const and non-const argument pointers. For
    +    example, in <cstring> strchr is overloaded. The functions isupper
    +    etc. in <cctype> typically implemented as macros in C are functions
    +    in C++, because they are overloaded with others of the same name
    +    defined in <locale>.
    +
    +    Many of the functions required in <cwctype> and <cwchar> cannot be
    +    implemented using underlying C facilities on intended targets because
    +    such facilities only partly exist.
    +
    +    Chapter 22  Locale
    +    ------------------
    +    Headers: <locale>
    +    C headers: <clocale>
    +
    +    We have a "mostly complete" class locale, with the exception of
    +    code for constructing, and handling the names of, named locales.
    +    The ways that locales are named (particularly when categories
    +    (e.g. LC_TIME, LC_COLLATE) are different) varies among all target
    +    environments. This code must be written in various versions and
    +    chosen by configuration parameters.
    +
    +    Members of many of the facets defined in <locale> are stubs. Generally,
    +    there are two sets of facets: the base class facets (which are supposed
    +    to implement the "C" locale) and the "byname" facets, which are supposed
    +    to read files to determine their behavior. The base ctype<>, collate<>,
    +    and numpunct<> facets are "mostly complete", except that the table of
    +    bitmask values used for "is" operations, and corresponding mask values,
    +    are still defined in libio and just included/linked. (We will need to
    +    implement these tables independently, soon, but should take advantage
    +    of libio where possible.)  The num_put<>::put members for integer types
    +    are "mostly complete".
    +
    +    A complete list of what has and has not been implemented may be
    +    found in CHECKLIST. However, note that the current definition of
    +    codecvt<wchar_t,char,mbstate_t> is wrong. It should simply write
    +    out the raw bytes representing the wide characters, rather than
    +    trying to convert each to a corresponding single "char" value.
    +
    +    Some of the facets are more important than others. Specifically,
    +    the members of ctype<>, numpunct<>, num_put<>, and num_get<> facets
    +    are used by other library facilities defined in <string>, <istream>,
    +    and <ostream>, and the codecvt<> facet is used by basic_filebuf<>
    +    in <fstream>, so a conforming iostream implementation depends on
    +    these.
    +
    +    The "long long" type eventually must be supported, but code mentioning
    +    it should be wrapped in #if guards to allow pedantic-mode compiling.
    +
    +    Performance of num_put<> and num_get<> depend critically on
    +    caching computed values in ios_base objects, and on extensions
    +    to the interface with streambufs.
    +
    +    Specifically: retrieving a copy of the locale object, extracting
    +    the needed facets, and gathering data from them, for each call to
    +    (e.g.) operator<< would be prohibitively slow.  To cache format
    +    data for use by num_put<> and num_get<> we have a _Format_cache<>
    +    object stored in the ios_base::pword() array. This is constructed
    +    and initialized lazily, and is organized purely for utility. It
    +    is discarded when a new locale with different facets is imbued.
    +
    +    Using only the public interfaces of the iterator arguments to the
    +    facet functions would limit performance by forbidding "vector-style"
    +    character operations. The streambuf iterator optimizations are
    +    described under chapter 24, but facets can also bypass the streambuf
    +    iterators via explicit specializations and operate directly on the
    +    streambufs, and use extended interfaces to get direct access to the
    +    streambuf internal buffer arrays. These extensions are mentioned
    +    under chapter 27. These optimizations are particularly important
    +    for input parsing.
    +
    +    Unused virtual members of locale facets can be omitted, as mentioned
    +    above, by a smart linker.
    +
    +    Chapter 23  Containers
    +    ----------------------
    +    Headers: <deque> <list> <queue> <stack> <vector> <map> <set> <bitset>
    +
    +    All the components in chapter 23 are implemented in the SGI STL.
    +    They are "mostly complete"; they include a large number of
    +    nonconforming extensions which must be wrapped. Some of these
    +    are used internally and must be renamed or duplicated.
    +
    +    The SGI components are optimized for large-memory environments. For
    +    embedded targets, different criteria might be more appropriate. Users
    +    will want to be able to tune this behavior. We should provide
    +    ways for users to compile the library with different memory usage
    +    characteristics.
    +
    +    A lot more work is needed on factoring out common code from different
    +    specializations to reduce code size here and in chapter 25. The
    +    easiest fix for this would be a compiler/ABI improvement that allows
    +    the compiler to recognize when a specialization depends only on the
    +    size (or other gross quality) of a template argument, and allow the
    +    linker to share the code with similar specializations. In its
    +    absence, many of the algorithms and containers can be partial-
    +    specialized, at least for the case of pointers, but this only solves
    +    a small part of the problem. Use of a type_traits-style template
    +    allows a few more optimization opportunities, more if the compiler
    +    can generate the specializations automatically.
    +
    +    As an optimization, containers can specialize on the default allocator
    +    and bypass it, or take advantage of details of its implementation
    +    after it has been improved upon.
    +
    +    Replacing the vector iterators, which currently are simple element
    +    pointers, with class objects would greatly increase the safety of the
    +    client interface, and also permit a "debug" mode in which range,
    +    ownership, and validity are rigorously checked. The current use of
    +    pointers for iterators is evil.
    +
    +    As mentioned for chapter 24, the deque iterator is a good example of
    +    an opportunity to implement a "staged" iterator that would benefit
    +    from specializations of some algorithms.
    +
    +    Chapter 24  Iterators
    +    ---------------------
    +    Headers: <iterator>
    +
    +    Standard iterators are "mostly complete", with the exception of
    +    the stream iterators, which are not yet templatized on the
    +    stream type. Also, the base class template iterator<> appears
    +    to be wrong, so everything derived from it must also be wrong,
    +    currently.
    +
    +    The streambuf iterators (currently located in stl/bits/std_iterator.h,
    +    but should be under bits/) can be rewritten to take advantage of
    +    friendship with the streambuf implementation.
    +
    +    Matt Austern has identified opportunities where certain iterator
    +    types, particularly including streambuf iterators and deque
    +    iterators, have a "two-stage" quality, such that an intermediate
    +    limit can be checked much more quickly than the true limit on
    +    range operations. If identified with a member of iterator_traits,
    +    algorithms may be specialized for this case. Of course the
    +    iterators that have this quality can be identified by specializing
    +    a traits class.
    +
    +    Many of the algorithms must be specialized for the streambuf
    +    iterators, to take advantage of block-mode operations, in order
    +    to allow iostream/locale operations' performance not to suffer.
    +    It may be that they could be treated as staged iterators and
    +    take advantage of those optimizations.
    +
    +    Chapter 25  Algorithms
    +    ----------------------
    +    Headers: <algorithm>
    +    C headers: <cstdlib> (also in 18, 21, 26))
    +
    +    The algorithms are "mostly complete". As mentioned above, they
    +    are optimized for speed at the expense of code and data size.
    +
    +    Specializations of many of the algorithms for non-STL types would
    +    give performance improvements, but we must use great care not to
    +    interfere with fragile template overloading semantics for the
    +    standard interfaces. Conventionally the standard function template
    +    interface is an inline which delegates to a non-standard function
    +    which is then overloaded (this is already done in many places in
    +    the library). Particularly appealing opportunities for the sake of
    +    iostream performance are for copy and find applied to streambuf
    +    iterators or (as noted elsewhere) for staged iterators, of which
    +    the streambuf iterators are a good example.
    +
    +    The bsearch and qsort functions cannot be overloaded properly as
    +    required by the standard because gcc does not yet allow overloading
    +    on the extern-"C"-ness of a function pointer.
    +
    +    Chapter 26  Numerics
    +    --------------------
    +    Headers: <complex> <valarray> <numeric>
    +    C headers: <cmath>, <cstdlib> (also 18, 21, 25)
    +
    +    Numeric components: Gabriel dos Reis's valarray, Drepper's complex,
    +    and the few algorithms from the STL are "mostly done".  Of course
    +    optimization opportunities abound for the numerically literate. It
    +    is not clear whether the valarray implementation really conforms
    +    fully, in the assumptions it makes about aliasing (and lack thereof)
    +    in its arguments.
    +
    +    The C div() and ldiv() functions are interesting, because they are the
    +    only case where a C library function returns a class object by value.
    +    Since the C++ type div_t must be different from the underlying C type
    +    (which is in the wrong namespace) the underlying functions div() and
    +    ldiv() cannot be re-used efficiently. Fortunately they are trivial to
    +    re-implement.
    +
    +    Chapter 27  Iostreams
    +    ---------------------
    +    Headers: <iosfwd> <streambuf> <ios> <ostream> <istream> <iostream>
    +    <iomanip> <sstream> <fstream>
    +    C headers: <cstdio> <cwchar> (also in 21)
    +
    +    Iostream is currently in a very incomplete state. <iosfwd>, <iomanip>,
    +    ios_base, and basic_ios<> are "mostly complete". basic_streambuf<> and
    +    basic_ostream<> are well along, but basic_istream<> has had little work
    +    done. The standard stream objects, <sstream> and <fstream> have been
    +    started; basic_filebuf<> "write" functions have been implemented just
    +    enough to do "hello, world".
    +
    +    Most of the istream and ostream operators << and >> (with the exception
    +    of the op<<(integer) ones) have not been changed to use locale primitives,
    +    sentry objects, or char_traits members.
    +
    +    All these templates should be manually instantiated for char and
    +    wchar_t in a way that links only used members into user programs.
    +
    +    Streambuf is fertile ground for optimization extensions. An extended
    +    interface giving iterator access to its internal buffer would be very
    +    useful for other library components.
    +
    +    Iostream operations (primarily operators << and >>) can take advantage
    +    of the case where user code has not specified a locale, and bypass locale
    +    operations entirely. The current implementation of op<</num_put<>::put,
    +    for the integer types, demonstrates how they can cache encoding details
    +    from the locale on each operation. There is lots more room for
    +    optimization in this area.
    +
    +    The definition of the relationship between the standard streams
    +    cout et al. and stdout et al. requires something like a "stdiobuf".
    +    The SGI solution of using double-indirection to actually use a
    +    stdio FILE object for buffering is unsatisfactory, because it
    +    interferes with peephole loop optimizations.
    +
    +    The <sstream> header work has begun. stringbuf can benefit from
    +    friendship with basic_string<> and basic_string<>::_Rep to use
    +    those objects directly as buffers, and avoid allocating and making
    +    copies.
    +
    +    The basic_filebuf<> template is a complex beast. It is specified to
    +    use the locale facet codecvt<> to translate characters between native
    +    files and the locale character encoding. In general this involves
    +    two buffers, one of "char" representing the file and another of
    +    "char_type", for the stream, with codecvt<> translating. The process
    +    is complicated by the variable-length nature of the translation, and
    +    the need to seek to corresponding places in the two representations.
    +    For the case of basic_filebuf<char>, when no translation is needed,
    +    a single buffer suffices. A specialized filebuf can be used to reduce
    +    code space overhead when no locale has been imbued. Matt Austern's
    +    work at SGI will be useful, perhaps directly as a source of code, or
    +    at least as an example to draw on.
    +
    +    Filebuf, almost uniquely (cf. operator new), depends heavily on
    +    underlying environmental facilities. In current releases iostream
    +    depends fairly heavily on libio constant definitions, but it should
    +    be made independent.  It also depends on operating system primitives
    +    for file operations. There is immense room for optimizations using
    +    (e.g.) mmap for reading. The shadow/ directory wraps, besides the
    +    standard C headers, the libio.h and unistd.h headers, for use mainly
    +    by filebuf. These wrappings have not been completed, though there
    +    is scaffolding in place.
    +
    +    The encapsulation of certain C header <cstdio> names presents an
    +    interesting problem. It is possible to define an inline std::fprintf()
    +    implemented in terms of the 'extern "C"' vfprintf(), but there is no
    +    standard vfscanf() to use to implement std::fscanf(). It appears that
    +    vfscanf but be re-implemented in C++ for targets where no vfscanf
    +    extension has been defined. This is interesting in that it seems
    +    to be the only significant case in the C library where this kind of
    +    rewriting is necessary. (Of course Glibc provides the vfscanf()
    +    extension.)  (The functions related to exit() must be rewritten
    +    for other reasons.)
    +
    +
    +    Annex D
    +    -------
    +    Headers: <strstream>
    +
    +    Annex D defines many non-library features, and many minor
    +    modifications to various headers, and a complete header.
    +    It is "mostly done", except that the libstdc++-2 <strstream>
    +    header has not been adopted into the library, or checked to
    +    verify that it matches the draft in those details that were
    +    clarified by the committee. Certainly it must at least be
    +    moved into the std namespace.
    +
    +    We still need to wrap all the deprecated features in #if guards
    +    so that pedantic compile modes can detect their use.
    +
    +    Nonstandard Extensions
    +    ----------------------
    +    Headers: <iostream.h> <strstream.h> <hash> <rbtree>
    +    <pthread_alloc> <stdiobuf> (etc.)
    +
    +    User code has come to depend on a variety of nonstandard components
    +    that we must not omit. Much of this code can be adopted from
    +    libstdc++-v2 or from the SGI STL. This particularly includes
    +    <iostream.h>, <strstream.h>, and various SGI extensions such
    +    as <hash_map.h>. Many of these are already placed in the
    +    subdirectories ext/ and backward/. (Note that it is better to
    +    include them via "<backward/hash_map.h>" or "<ext/hash_map>" than
    +    to search the subdirectory itself via a "-I" directive.
    +  

    Prev Up Next
    Coding Style Home Appendix B.  Porting and Maintenance
    diff --git a/libstdc++-v3/doc/html/manual/source_organization.html b/libstdc++-v3/doc/html/manual/source_organization.html index 967a9adcf04..c47baa24918 100644 --- a/libstdc++-v3/doc/html/manual/source_organization.html +++ b/libstdc++-v3/doc/html/manual/source_organization.html @@ -1,105 +1,97 @@ -Directory Layout and Source Conventions
    Directory Layout and Source Conventions
    Prev Appendix A.  + + +Directory Layout and Source Conventions
    Directory Layout and Source Conventions
    Prev Appendix A.  Contributing - Next

    Directory Layout and Source Conventions

    +

    		 Next

    Directory Layout and Source Conventions

    The unpacked source directory of libstdc++ contains the files needed to create the GNU C++ Library. -


    -It has subdirectories:
    -
    -  doc
    -    Files in HTML and text format that document usage, quirks of the
    -    implementation, and contributor checklists.
    -
    -  include
    -    All header files for the C++ library are within this directory,
    -    modulo specific runtime-related files that are in the libsupc++
    -    directory.
    -
    -    include/std
    -      Files meant to be found by #include <name> directives in
    -      standard-conforming user programs.
    -
    -    include/c
    -      Headers intended to directly include standard C headers.
    -      [NB: this can be enabled via --enable-cheaders=c]
    -
    -    include/c_global
    -      Headers intended to include standard C headers in
    -      the global namespace, and put select names into the std::
    -      namespace.  [NB: this is the default, and is the same as
    -      --enable-cheaders=c_global]
    -
    -    include/c_std
    -      Headers intended to include standard C headers
    -      already in namespace std, and put select names into the std::
    -      namespace.  [NB: this is the same as --enable-cheaders=c_std]
    -
    -    include/bits
    -      Files included by standard headers and by other files in
    -      the bits directory.
    -
    -    include/backward
    -      Headers provided for backward compatibility, such as <iostream.h>.
    -      They are not used in this library.
    -
    -    include/ext
    -      Headers that define extensions to the standard library.  No
    -      standard header refers to any of them.
    -
    -  scripts
    -    Scripts that are used during the configure, build, make, or test
    -    process.
    -
    -  src
    -    Files that are used in constructing the library, but are not
    -    installed.
    -
    -  testsuites/[backward, demangle, ext, performance, thread, 17_* to 30_*]
    -    Test programs are here, and may be used to begin to exercise the
    -    library.  Support for "make check" and "make check-install" is
    -    complete, and runs through all the subdirectories here when this
    -    command is issued from the build directory.  Please note that
    -    "make check" requires DejaGNU 1.4 or later to be installed.  Please
    -    note that "make check-script" calls the script mkcheck, which
    -    requires bash, and which may need the paths to bash adjusted to
    -    work properly, as /bin/bash is assumed.
    -
    -Other subdirectories contain variant versions of certain files
    -that are meant to be copied or linked by the configure script.
    -Currently these are:
    -
    -  config/abi
    -  config/cpu
    -  config/io
    -  config/locale
    -  config/os
    -
    -In addition, a subdirectory holds the convenience library libsupc++.
    -
    -  libsupc++
    -    Contains the runtime library for C++, including exception
    -    handling and memory allocation and deallocation, RTTI, terminate
    -    handlers, etc.
    -
    -Note that glibc also has a bits/ subdirectory.  We will either
    -need to be careful not to collide with names in its bits/
    -directory; or rename bits to (e.g.) cppbits/.
    -
    -In files throughout the system, lines marked with an "XXX" indicate
    -a bug or incompletely-implemented feature.  Lines marked "XXX MT"
    -indicate a place that may require attention for multi-thread safety.
    -  

    Prev Up Next
    Appendix A.  +


    +It has subdirectories:
    +
    +  doc
    +    Files in HTML and text format that document usage, quirks of the
    +    implementation, and contributor checklists.
    +
    +  include
    +    All header files for the C++ library are within this directory,
    +    modulo specific runtime-related files that are in the libsupc++
    +    directory.
    +
    +    include/std
    +      Files meant to be found by #include <name> directives in
    +      standard-conforming user programs.
    +
    +    include/c
    +      Headers intended to directly include standard C headers.
    +      [NB: this can be enabled via --enable-cheaders=c]
    +
    +    include/c_global
    +      Headers intended to include standard C headers in
    +      the global namespace, and put select names into the std::
    +      namespace.  [NB: this is the default, and is the same as
    +      --enable-cheaders=c_global]
    +
    +    include/c_std
    +      Headers intended to include standard C headers
    +      already in namespace std, and put select names into the std::
    +      namespace.  [NB: this is the same as --enable-cheaders=c_std]
    +
    +    include/bits
    +      Files included by standard headers and by other files in
    +      the bits directory.
    +
    +    include/backward
    +      Headers provided for backward compatibility, such as <iostream.h>.
    +      They are not used in this library.
    +
    +    include/ext
    +      Headers that define extensions to the standard library.  No
    +      standard header refers to any of them.
    +
    +  scripts
    +    Scripts that are used during the configure, build, make, or test
    +    process.
    +
    +  src
    +    Files that are used in constructing the library, but are not
    +    installed.
    +
    +  testsuites/[backward, demangle, ext, performance, thread, 17_* to 30_*]
    +    Test programs are here, and may be used to begin to exercise the
    +    library.  Support for "make check" and "make check-install" is
    +    complete, and runs through all the subdirectories here when this
    +    command is issued from the build directory.  Please note that
    +    "make check" requires DejaGNU 1.4 or later to be installed.  Please
    +    note that "make check-script" calls the script mkcheck, which
    +    requires bash, and which may need the paths to bash adjusted to
    +    work properly, as /bin/bash is assumed.
    +
    +Other subdirectories contain variant versions of certain files
    +that are meant to be copied or linked by the configure script.
    +Currently these are:
    +
    +  config/abi
    +  config/cpu
    +  config/io
    +  config/locale
    +  config/os
    +
    +In addition, a subdirectory holds the convenience library libsupc++.
    +
    +  libsupc++
    +    Contains the runtime library for C++, including exception
    +    handling and memory allocation and deallocation, RTTI, terminate
    +    handlers, etc.
    +
    +Note that glibc also has a bits/ subdirectory.  We will either
    +need to be careful not to collide with names in its bits/
    +directory; or rename bits to (e.g.) cppbits/.
    +
    +In files throughout the system, lines marked with an "XXX" indicate
    +a bug or incompletely-implemented feature.  Lines marked "XXX MT"
    +indicate a place that may require attention for multi-thread safety.
    +  

    Prev Up Next
    Appendix A.  Contributing  Home Coding Style
    diff --git a/libstdc++-v3/doc/html/manual/status.html b/libstdc++-v3/doc/html/manual/status.html index 9b061fff5c3..4115ef41738 100644 --- a/libstdc++-v3/doc/html/manual/status.html +++ b/libstdc++-v3/doc/html/manual/status.html @@ -1,22 +1,14 @@ -Chapter 1. Status
    Chapter 1. Status
    Prev Part I.  + + +Chapter 1. Status
    Chapter 1. Status
    Prev Part I.  Introduction - Next

    Chapter 1. Status

    Table of Contents

    Implementation Status
    C++ 1998/2003
    Implementation Status
    Implementation Specific Behavior
    C++ 2011
    Implementation Specific Behavior
    C++ TR1
    Implementation Specific Behavior
    C++ TR 24733
    License
    The Code: GPL
    The Documentation: GPL, FDL
    Bugs
    Implementation Bugs
    Standard Bugs

    Implementation Status

    C++ 1998/2003

    Implementation Status

    +

    		 Next

    Chapter 1. Status

    Table of Contents

    Implementation Status
    C++ 1998/2003
    Implementation Status
    Implementation Specific Behavior
    C++ 2011
    Implementation Specific Behavior
    C++ TR1
    Implementation Specific Behavior
    C++ TR 24733
    License
    The Code: GPL
    The Documentation: GPL, FDL
    Bugs
    Implementation Bugs
    Standard Bugs

    Implementation Status

    C++ 1998/2003

    Implementation Status

    This status table is based on the table of contents of ISO/IEC 14882:2003.

    This page describes the C++ support in mainline GCC SVN, not in any particular release. -

    Table 1.1. C++ 1998/2003 Implementation Status

    SectionDescriptionStatusComments
    +

    Table 1.1. C++ 1998/2003 Implementation Status

    SectionDescriptionStatusComments
    18 Language support @@ -60,7 +52,7 @@ particular release. Appendix D Compatibility features -
    D.1Increment operator with bool operand  
    D.2static keyword  
    D.3Access declarations  
    D.4Implicit conversion from const strings  
    D.5C standard library headers  
    D.6Old iostreams members  
    D.7char* streams  

    Implementation Specific Behavior

    +

    D.1Increment operator with bool operand  
    D.2static keyword  
    D.3Access declarations  
    D.4Implicit conversion from const strings  
    D.5C standard library headers  
    D.6Old iostreams members  
    D.7char* streams  

    Implementation Specific Behavior

    The ISO standard defines the following phrase:

    [1.3.5] implementation-defined behavior @@ -150,8 +142,8 @@ particular release. in this chapter.

    [27.8.1.4]/16 Calling fstream::sync when a get area exists will... whatever fflush() does, I think. -

    C++ 2011

    - +

    C++ 2011

    + This table is based on the table of contents of ISO/IEC JTC1 SC22 WG21 Doc No: N3290 Date: 2011-04-11 Final Draft International Standard, Standard for Programming Language C++ @@ -166,7 +158,7 @@ presence of the required flag.

    This page describes the C++11 support in mainline GCC SVN, not in any particular release. -

    Table 1.2. C++ 2011 Implementation Status

    SectionDescriptionStatusComments
    +

    Table 1.2. C++ 2011 Implementation Status

    SectionDescriptionStatusComments
    18 Language support @@ -249,7 +241,7 @@ particular release. Appendix D Compatibility features -
    D.1Increment operator with bool operand  
    D.2register keyword  
    D.3Implicit declaration of copy functions  
    D.4Dynamic exception specifications  
    D.5C standard library headers  
    D.6Old iostreams members  
    D.7char* streams  
    D.8Function objects  
    D.9Binders  
    D.10auto_ptr  
    D.11Violating exception-specifications  

    Implementation Specific Behavior

    For behaviour which is also specified by the 1998 and 2003 standards, +

    D.1Increment operator with bool operand  
    D.2register keyword  
    D.3Implicit declaration of copy functions  
    D.4Dynamic exception specifications  
    D.5C standard library headers  
    D.6Old iostreams members  
    D.7char* streams  
    D.8Function objects  
    D.9Binders  
    D.10auto_ptr  
    D.11Violating exception-specifications  

    Implementation Specific Behavior

    For behaviour which is also specified by the 1998 and 2003 standards, see C++ 1998/2003 Implementation Specific Behavior. This section only documents behaviour which is new in the 2011 standard. @@ -287,7 +279,7 @@ particular release. launch is a scoped enumeration type with overloaded operators to support bitmask operations. There are no additional bitmask elements defined. -

    C++ TR1

    +

    C++ TR1

    This table is based on the table of contents of ISO/IEC DTR 19768 Doc No: N1836=05-0096 Date: 2005-06-24 Draft Technical Report on C++ Library Extensions @@ -298,12 +290,12 @@ In this implementation the header names are prefixed by

    This page describes the TR1 support in mainline GCC SVN, not in any particular release. -

    Table 1.3. C++ TR1 Implementation Status

    SectionDescriptionStatusComments
    2General Utilities
    2.1Reference wrappers  
    2.1.1Additions to header <functional> synopsisY 
    2.1.2Class template reference_wrapper  
    2.1.2.1reference_wrapper construct/copy/destroyY 
    2.1.2.2reference_wrapper assignmentY 
    2.1.2.3reference_wrapper accessY 
    2.1.2.4reference_wrapper invocationY 
    2.1.2.5reference_wrapper helper functionsY 
    2.2Smart pointers  
    2.2.1Additions to header <memory> synopsisY 
    2.2.2Class bad_weak_ptrY 
    2.2.3Class template shared_ptr  +

    Table 1.3. C++ TR1 Implementation Status

    SectionDescriptionStatusComments
    2General Utilities
    2.1Reference wrappers  
    2.1.1Additions to header <functional> synopsisY 
    2.1.2Class template reference_wrapper  
    2.1.2.1reference_wrapper construct/copy/destroyY 
    2.1.2.2reference_wrapper assignmentY 
    2.1.2.3reference_wrapper accessY 
    2.1.2.4reference_wrapper invocationY 
    2.1.2.5reference_wrapper helper functionsY 
    2.2Smart pointers  
    2.2.1Additions to header <memory> synopsisY 
    2.2.2Class bad_weak_ptrY 
    2.2.3Class template shared_ptr 

    Uses code from boost::shared_ptr.

    -
    2.2.3.1shared_ptr constructorsY 
    2.2.3.2shared_ptr destructorY 
    2.2.3.3shared_ptr assignmentY 
    2.2.3.4shared_ptr modifiersY 
    2.2.3.5shared_ptr observersY 
    2.2.3.6shared_ptr comparisonY 
    2.2.3.7shared_ptr I/OY 
    2.2.3.8shared_ptr specialized algorithmsY 
    2.2.3.9shared_ptr castsY 
    2.2.3.10get_deleterY 
    2.2.4Class template weak_ptr  
    2.2.4.1weak_ptr constructorsY 
    2.2.4.2weak_ptr destructorY 
    2.2.4.3weak_ptr assignmentY 
    2.2.4.4weak_ptr modifiersY 
    2.2.4.5weak_ptr observersY 
    2.2.4.6weak_ptr comparisonY 
    2.2.4.7weak_ptr specialized algorithmsY 
    2.2.5Class template enable_shared_from_thisY 
    3Function Objects
    3.1DefinitionsY 
    3.2Additions to <functional> synopsisY 
    3.3RequirementsY 
    3.4Function return typesY 
    3.5Function template mem_fnY 
    3.6Function object binders  
    3.6.1Class template is_bind_expressionY 
    3.6.2Class template is_placeholderY 
    3.6.3Function template bindY 
    3.6.4PlaceholdersY 
    3.7Polymorphic function wrappers  
    3.7.1Class bad_function_callY 
    3.7.1.1bad_function_call constructorY 
    3.7.2Class template function  
    3.7.2.1function construct/copy/destroyY 
    3.7.2.2function modifiersY 
    3.7.2.3function capacityY 
    3.7.2.4function invocationY 
    3.7.2.5function target accessY 
    3.7.2.6undefined operatorsY 
    3.7.2.7null pointer comparison operatorsY 
    3.7.2.8specialized algorithmsY 
    4Metaprogramming and type traits
    4.1RequirementsY 
    4.2Header <type_traits> synopsisY 
    4.3Helper classesY 
    4.4General RequirementsY 
    4.5Unary Type Traits  
    4.5.1Primary Type CategoriesY 
    4.5.2Composite type traitsY 
    4.5.3Type propertiesY 
    4.6Relationships between typesY 
    4.7Transformations between types  
    4.7.1Const-volatile modificationsY 
    4.7.2Reference modificationsY 
    4.7.3Array modificationsY 
    4.7.4Pointer modificationsY 
    4.8Other transformationsY 
    4.9Implementation requirementsY 
    5Numerical Facilities
    5.1Random number generation  
    5.1.1RequirementsY 
    5.1.2Header <random> synopsisY 
    5.1.3Class template variate_generatorY 
    5.1.4Random number engine class templatesY 
    5.1.4.1Class template linear_congruentialY 
    5.1.4.2Class template mersenne_twisterY 
    5.1.4.3Class template subtract_with_carryY 
    5.1.4.4Class template subtract_with_carry_01Y 
    5.1.4.5Class template discard_blockY 
    5.1.4.6Class template xor_combineYoperator()() per N2079
    5.1.5Engines with predefined parametersY 
    5.1.6Class random_deviceY 
    5.1.7Random distribution class templatesY 
    5.1.7.1Class template uniform_intY 
    5.1.7.2Class bernoulli_distributionY 
    5.1.7.3Class template geometric_distributionY 
    5.1.7.4Class template poisson_distributionY 
    5.1.7.5Class template binomial_distributionY 
    5.1.7.6Class template uniform_realY 
    5.1.7.7Class template exponential_distributionY 
    5.1.7.8Class template normal_distributionY 
    5.1.7.9Class template gamma_distributionY 
    5.2Mathematical special functionsY 
    5.2.1Additions to header <cmath> synopsisY 
    5.2.1.1associated Laguerre polynomialsY 
    5.2.1.2associated Legendre functionsY 
    5.2.1.3beta functionY 
    5.2.1.4(complete) elliptic integral of the first kindY 
    5.2.1.5(complete) elliptic integral of the second kindY 
    5.2.1.6(complete) elliptic integral of the third kindY 
    5.2.1.7confluent hypergeometric functionsY 
    5.2.1.8regular modified cylindrical Bessel functionsY 
    5.2.1.9cylindrical Bessel functions (of the first kind)Y 
    5.2.1.10irregular modified cylindrical Bessel functionsY 
    5.2.1.11cylindrical Neumann functionsY 
    5.2.1.12(incomplete) elliptic integral of the first kindY 
    5.2.1.13(incomplete) elliptic integral of the second kindY 
    5.2.1.14(incomplete) elliptic integral of the third kindY 
    5.2.1.15exponential integralY 
    5.2.1.16Hermite polynomialsY 
    5.2.1.17hypergeometric functionsY 
    5.2.1.18Laguerre polynomialsY 
    5.2.1.19Legendre polynomialsY 
    5.2.1.20Riemann zeta functionY 
    5.2.1.21spherical Bessel functions (of the first kind)Y 
    5.2.1.22spherical associated Legendre functionsY 
    5.2.1.23spherical Neumann functionsY 
    5.2.2Additions to header <math.h> synopsisY 
    6Containers
    6.1Tuple typesY 
    6.1.1Header <tuple> synopsisY 
    6.1.2Additions to header <utility> synopsisY 
    6.1.3Class template tupleY 
    6.1.3.1ConstructionY 
    6.1.3.2Tuple creation functionsY 
    6.1.3.3Tuple helper classesY 
    6.1.3.4Element accessY 
    6.1.3.5Relational operatorsY 
    6.1.4PairsY 
    6.2Fixed size arrayY 
    6.2.1Header <array> synopsisY 
    6.2.2Class template arrayY 
    6.2.2.1array constructors, copy, and assignmentY 
    6.2.2.2array specialized algorithmsY 
    6.2.2.3array sizeY 
    6.2.2.4Zero sized arraysY 
    6.2.2.5Tuple interface to class template arrayY 
    6.3Unordered associative containersY 
    6.3.1Unordered associative container requirementsY 
    6.3.1.1Exception safety guaranteesY 
    6.3.2Additions to header <functional> synopsisY 
    6.3.3Class template hashY 
    6.3.4Unordered associative container classesY 
    6.3.4.1Header <unordered_set> synopsisY 
    6.3.4.2Header <unordered_map> synopsisY 
    6.3.4.3Class template unordered_setY 
    6.3.4.3.1unordered_set constructorsY 
    6.3.4.3.2unordered_set swapY 
    6.3.4.4Class template unordered_mapY 
    6.3.4.4.1unordered_map constructorsY 
    6.3.4.4.2unordered_map element accessY 
    6.3.4.4.3unordered_map swapY 
    6.3.4.5Class template unordered_multisetY 
    6.3.4.5.1unordered_multiset constructorsY 
    6.3.4.5.2unordered_multiset swapY 
    6.3.4.6Class template unordered_multimapY 
    6.3.4.6.1unordered_multimap constructorsY 
    6.3.4.6.2unordered_multimap swapY 
    7Regular Expressions
    7.1DefinitionsN 
    7.2RequirementsN 
    7.3Regular expressions summaryN 
    7.4Header <regex> synopsisN 
    7.5Namespace tr1::regex_constantsN 
    7.5.1Bitmask Type syntax_option_typeN 
    7.5.2Bitmask Type regex_constants::match_flag_typeN 
    7.5.3Implementation defined error_typeN 
    7.6Class regex_errorN 
    7.7Class template regex_traitsN 
    7.8Class template basic_regexN 
    7.8.1basic_regex constantsN 
    7.8.2basic_regex constructorsN 
    7.8.3basic_regex assignN 
    7.8.4basic_regex constant operationsN 
    7.8.5basic_regex localeN 
    7.8.6basic_regex swapN 
    7.8.7basic_regex non-member functionsN 
    7.8.7.1basic_regex non-member swapN 
    7.9Class template sub_matchN 
    7.9.1sub_match membersN 
    7.9.2sub_match non-member operatorsN 
    7.10Class template match_resultsN 
    7.10.1match_results constructorsN 
    7.10.2match_results sizeN 
    7.10.3match_results element accessN 
    7.10.4match_results formattingN 
    7.10.5match_results allocatorN 
    7.10.6match_results swapN 
    7.11Regular expression algorithmsN 
    7.11.1exceptionsN 
    7.11.2regex_matchN 
    7.11.3regex_searchN 
    7.11.4regex_replaceN 
    7.12Regular expression IteratorsN 
    7.12.1Class template regex_iteratorN 
    7.12.1.1regex_iterator constructorsN 
    7.12.1.2regex_iterator comparisonsN 
    7.12.1.3regex_iterator dereferenceN 
    7.12.1.4regex_iterator incrementN 
    7.12.2Class template regex_token_iteratorN 
    7.12.2.1regex_token_iterator constructorsN 
    7.12.2.2regex_token_iterator comparisonsN 
    7.12.2.3regex_token_iterator dereferenceN 
    7.12.2.4regex_token_iterator incrementN 
    7.13Modified ECMAScript regular expression grammarN 
    8C Compatibility
    8.1Additions to header <complex>Y 
    8.1.1SynopsisY 
    8.1.2Function acosY 
    8.1.3Function asinY 
    8.1.4Function atanY 
    8.1.5Function acoshY 
    8.1.6Function asinhY 
    8.1.7Function atanhY 
    8.1.8Function fabsY 
    8.1.9Additional OverloadsY 
    8.2Header <ccomplex>NDR 551
    8.3Header <complex.h>NDR 551
    8.4Additions to header <cctype>Y 
    8.4.1SynopsisY 
    8.4.2Function isblankY 
    8.5Additions to header <ctype.h>Y 
    8.6Header <cfenv>Y 
    8.6.1SynopsisY 
    8.6.2DefinitionsY 
    8.7Header <fenv.h>Y 
    8.8Additions to header <cfloat>Y 
    8.9Additions to header <float.h>Y 
    8.10Additions to header <ios>N 
    8.10.1SynopsisN 
    8.10.2Function hexfloatN 
    8.11Header <cinttypes>Y 
    8.11.1SynopsisYDR 557
    8.11.2DefinitionsY 
    8.12Header <inttypes.h>Y 
    8.13Additions to header <climits>Y 
    8.14Additions to header <limits.h>Y 
    8.15Additions to header <locale>N 
    8.16Additions to header <cmath>Y 
    8.16.1SynopsisY 
    8.16.2DefinitionsY 
    8.16.3Function template definitionsY 
    8.16.4Additional overloadsYDR 568; DR 550
    8.17Additions to header <math.h>Y 
    8.18Additions to header <cstdarg>Y 
    8.19Additions to header <stdarg.h>Y 
    8.20The header <cstdbool>Y 
    8.21The header <stdbool.h>Y 
    8.22The header <cstdint>Y 
    8.22.1SynopsisY 
    8.22.2DefinitionsY 
    8.23The header <stdint.h>Y 
    8.24Additions to header <cstdio>Y 
    8.24.1SynopsisY 
    8.24.2DefinitionsY 
    8.24.3Additional format specifiersYC library dependency
    8.24.4Additions to header <stdio.h>Y 
    8.25Additions to header <cstdlib>Y 
    8.25.1SynopsisY 
    8.25.2DefinitionsY 
    8.25.3Function absY 
    8.25.4Function divY 
    8.26Additions to header <stdlib.h>Y 
    8.27Header <ctgmath>YDR 551
    8.28Header <tgmath.h>YDR 551
    8.29Additions to header <ctime>YC library dependency
    8.30Additions to header <cwchar>Y 
    8.30.1SynopsisY 
    8.30.2DefinitionsY 
    8.30.3Additional wide format specifiersYC library dependency
    8.31Additions to header <wchar.h>Y 
    8.32Additions to header <cwctype>Y 
    8.32.1SynopsisY 
    8.32.2Function iswblankY 
    8.33Additions to header <wctype.h>Y 

    Implementation Specific Behavior

    For behaviour which is specified by the 1998 and 2003 standards, +

    2.2.3.1shared_ptr constructorsY 
    2.2.3.2shared_ptr destructorY 
    2.2.3.3shared_ptr assignmentY 
    2.2.3.4shared_ptr modifiersY 
    2.2.3.5shared_ptr observersY 
    2.2.3.6shared_ptr comparisonY 
    2.2.3.7shared_ptr I/OY 
    2.2.3.8shared_ptr specialized algorithmsY 
    2.2.3.9shared_ptr castsY 
    2.2.3.10get_deleterY 
    2.2.4Class template weak_ptr  
    2.2.4.1weak_ptr constructorsY 
    2.2.4.2weak_ptr destructorY 
    2.2.4.3weak_ptr assignmentY 
    2.2.4.4weak_ptr modifiersY 
    2.2.4.5weak_ptr observersY 
    2.2.4.6weak_ptr comparisonY 
    2.2.4.7weak_ptr specialized algorithmsY 
    2.2.5Class template enable_shared_from_thisY 
    3Function Objects
    3.1DefinitionsY 
    3.2Additions to <functional> synopsisY 
    3.3RequirementsY 
    3.4Function return typesY 
    3.5Function template mem_fnY 
    3.6Function object binders  
    3.6.1Class template is_bind_expressionY 
    3.6.2Class template is_placeholderY 
    3.6.3Function template bindY 
    3.6.4PlaceholdersY 
    3.7Polymorphic function wrappers  
    3.7.1Class bad_function_callY 
    3.7.1.1bad_function_call constructorY 
    3.7.2Class template function  
    3.7.2.1function construct/copy/destroyY 
    3.7.2.2function modifiersY 
    3.7.2.3function capacityY 
    3.7.2.4function invocationY 
    3.7.2.5function target accessY 
    3.7.2.6undefined operatorsY 
    3.7.2.7null pointer comparison operatorsY 
    3.7.2.8specialized algorithmsY 
    4Metaprogramming and type traits
    4.1RequirementsY 
    4.2Header <type_traits> synopsisY 
    4.3Helper classesY 
    4.4General RequirementsY 
    4.5Unary Type Traits  
    4.5.1Primary Type CategoriesY 
    4.5.2Composite type traitsY 
    4.5.3Type propertiesY 
    4.6Relationships between typesY 
    4.7Transformations between types  
    4.7.1Const-volatile modificationsY 
    4.7.2Reference modificationsY 
    4.7.3Array modificationsY 
    4.7.4Pointer modificationsY 
    4.8Other transformationsY 
    4.9Implementation requirementsY 
    5Numerical Facilities
    5.1Random number generation  
    5.1.1RequirementsY 
    5.1.2Header <random> synopsisY 
    5.1.3Class template variate_generatorY 
    5.1.4Random number engine class templatesY 
    5.1.4.1Class template linear_congruentialY 
    5.1.4.2Class template mersenne_twisterY 
    5.1.4.3Class template subtract_with_carryY 
    5.1.4.4Class template subtract_with_carry_01Y 
    5.1.4.5Class template discard_blockY 
    5.1.4.6Class template xor_combineYoperator()() per N2079
    5.1.5Engines with predefined parametersY 
    5.1.6Class random_deviceY 
    5.1.7Random distribution class templatesY 
    5.1.7.1Class template uniform_intY 
    5.1.7.2Class bernoulli_distributionY 
    5.1.7.3Class template geometric_distributionY 
    5.1.7.4Class template poisson_distributionY 
    5.1.7.5Class template binomial_distributionY 
    5.1.7.6Class template uniform_realY 
    5.1.7.7Class template exponential_distributionY 
    5.1.7.8Class template normal_distributionY 
    5.1.7.9Class template gamma_distributionY 
    5.2Mathematical special functionsY 
    5.2.1Additions to header <cmath> synopsisY 
    5.2.1.1associated Laguerre polynomialsY 
    5.2.1.2associated Legendre functionsY 
    5.2.1.3beta functionY 
    5.2.1.4(complete) elliptic integral of the first kindY 
    5.2.1.5(complete) elliptic integral of the second kindY 
    5.2.1.6(complete) elliptic integral of the third kindY 
    5.2.1.7confluent hypergeometric functionsY 
    5.2.1.8regular modified cylindrical Bessel functionsY 
    5.2.1.9cylindrical Bessel functions (of the first kind)Y 
    5.2.1.10irregular modified cylindrical Bessel functionsY 
    5.2.1.11cylindrical Neumann functionsY 
    5.2.1.12(incomplete) elliptic integral of the first kindY 
    5.2.1.13(incomplete) elliptic integral of the second kindY 
    5.2.1.14(incomplete) elliptic integral of the third kindY 
    5.2.1.15exponential integralY 
    5.2.1.16Hermite polynomialsY 
    5.2.1.17hypergeometric functionsY 
    5.2.1.18Laguerre polynomialsY 
    5.2.1.19Legendre polynomialsY 
    5.2.1.20Riemann zeta functionY 
    5.2.1.21spherical Bessel functions (of the first kind)Y 
    5.2.1.22spherical associated Legendre functionsY 
    5.2.1.23spherical Neumann functionsY 
    5.2.2Additions to header <math.h> synopsisY 
    6Containers
    6.1Tuple typesY 
    6.1.1Header <tuple> synopsisY 
    6.1.2Additions to header <utility> synopsisY 
    6.1.3Class template tupleY 
    6.1.3.1ConstructionY 
    6.1.3.2Tuple creation functionsY 
    6.1.3.3Tuple helper classesY 
    6.1.3.4Element accessY 
    6.1.3.5Relational operatorsY 
    6.1.4PairsY 
    6.2Fixed size arrayY 
    6.2.1Header <array> synopsisY 
    6.2.2Class template arrayY 
    6.2.2.1array constructors, copy, and assignmentY 
    6.2.2.2array specialized algorithmsY 
    6.2.2.3array sizeY 
    6.2.2.4Zero sized arraysY 
    6.2.2.5Tuple interface to class template arrayY 
    6.3Unordered associative containersY 
    6.3.1Unordered associative container requirementsY 
    6.3.1.1Exception safety guaranteesY 
    6.3.2Additions to header <functional> synopsisY 
    6.3.3Class template hashY 
    6.3.4Unordered associative container classesY 
    6.3.4.1Header <unordered_set> synopsisY 
    6.3.4.2Header <unordered_map> synopsisY 
    6.3.4.3Class template unordered_setY 
    6.3.4.3.1unordered_set constructorsY 
    6.3.4.3.2unordered_set swapY 
    6.3.4.4Class template unordered_mapY 
    6.3.4.4.1unordered_map constructorsY 
    6.3.4.4.2unordered_map element accessY 
    6.3.4.4.3unordered_map swapY 
    6.3.4.5Class template unordered_multisetY 
    6.3.4.5.1unordered_multiset constructorsY 
    6.3.4.5.2unordered_multiset swapY 
    6.3.4.6Class template unordered_multimapY 
    6.3.4.6.1unordered_multimap constructorsY 
    6.3.4.6.2unordered_multimap swapY 
    7Regular Expressions
    7.1DefinitionsN 
    7.2RequirementsN 
    7.3Regular expressions summaryN 
    7.4Header <regex> synopsisN 
    7.5Namespace tr1::regex_constantsN 
    7.5.1Bitmask Type syntax_option_typeN 
    7.5.2Bitmask Type regex_constants::match_flag_typeN 
    7.5.3Implementation defined error_typeN 
    7.6Class regex_errorN 
    7.7Class template regex_traitsN 
    7.8Class template basic_regexN 
    7.8.1basic_regex constantsN 
    7.8.2basic_regex constructorsN 
    7.8.3basic_regex assignN 
    7.8.4basic_regex constant operationsN 
    7.8.5basic_regex localeN 
    7.8.6basic_regex swapN 
    7.8.7basic_regex non-member functionsN 
    7.8.7.1basic_regex non-member swapN 
    7.9Class template sub_matchN 
    7.9.1sub_match membersN 
    7.9.2sub_match non-member operatorsN 
    7.10Class template match_resultsN 
    7.10.1match_results constructorsN 
    7.10.2match_results sizeN 
    7.10.3match_results element accessN 
    7.10.4match_results formattingN 
    7.10.5match_results allocatorN 
    7.10.6match_results swapN 
    7.11Regular expression algorithmsN 
    7.11.1exceptionsN 
    7.11.2regex_matchN 
    7.11.3regex_searchN 
    7.11.4regex_replaceN 
    7.12Regular expression IteratorsN 
    7.12.1Class template regex_iteratorN 
    7.12.1.1regex_iterator constructorsN 
    7.12.1.2regex_iterator comparisonsN 
    7.12.1.3regex_iterator dereferenceN 
    7.12.1.4regex_iterator incrementN 
    7.12.2Class template regex_token_iteratorN 
    7.12.2.1regex_token_iterator constructorsN 
    7.12.2.2regex_token_iterator comparisonsN 
    7.12.2.3regex_token_iterator dereferenceN 
    7.12.2.4regex_token_iterator incrementN 
    7.13Modified ECMAScript regular expression grammarN 
    8C Compatibility
    8.1Additions to header <complex>Y 
    8.1.1SynopsisY 
    8.1.2Function acosY 
    8.1.3Function asinY 
    8.1.4Function atanY 
    8.1.5Function acoshY 
    8.1.6Function asinhY 
    8.1.7Function atanhY 
    8.1.8Function fabsY 
    8.1.9Additional OverloadsY 
    8.2Header <ccomplex>NDR 551
    8.3Header <complex.h>NDR 551
    8.4Additions to header <cctype>Y 
    8.4.1SynopsisY 
    8.4.2Function isblankY 
    8.5Additions to header <ctype.h>Y 
    8.6Header <cfenv>Y 
    8.6.1SynopsisY 
    8.6.2DefinitionsY 
    8.7Header <fenv.h>Y 
    8.8Additions to header <cfloat>Y 
    8.9Additions to header <float.h>Y 
    8.10Additions to header <ios>N 
    8.10.1SynopsisN 
    8.10.2Function hexfloatN 
    8.11Header <cinttypes>Y 
    8.11.1SynopsisYDR 557
    8.11.2DefinitionsY 
    8.12Header <inttypes.h>Y 
    8.13Additions to header <climits>Y 
    8.14Additions to header <limits.h>Y 
    8.15Additions to header <locale>N 
    8.16Additions to header <cmath>Y 
    8.16.1SynopsisY 
    8.16.2DefinitionsY 
    8.16.3Function template definitionsY 
    8.16.4Additional overloadsYDR 568; DR 550
    8.17Additions to header <math.h>Y 
    8.18Additions to header <cstdarg>Y 
    8.19Additions to header <stdarg.h>Y 
    8.20The header <cstdbool>Y 
    8.21The header <stdbool.h>Y 
    8.22The header <cstdint>Y 
    8.22.1SynopsisY 
    8.22.2DefinitionsY 
    8.23The header <stdint.h>Y 
    8.24Additions to header <cstdio>Y 
    8.24.1SynopsisY 
    8.24.2DefinitionsY 
    8.24.3Additional format specifiersYC library dependency
    8.24.4Additions to header <stdio.h>Y 
    8.25Additions to header <cstdlib>Y 
    8.25.1SynopsisY 
    8.25.2DefinitionsY 
    8.25.3Function absY 
    8.25.4Function divY 
    8.26Additions to header <stdlib.h>Y 
    8.27Header <ctgmath>YDR 551
    8.28Header <tgmath.h>YDR 551
    8.29Additions to header <ctime>YC library dependency
    8.30Additions to header <cwchar>Y 
    8.30.1SynopsisY 
    8.30.2DefinitionsY 
    8.30.3Additional wide format specifiersYC library dependency
    8.31Additions to header <wchar.h>Y 
    8.32Additions to header <cwctype>Y 
    8.32.1SynopsisY 
    8.32.2Function iswblankY 
    8.33Additions to header <wctype.h>Y 

    Implementation Specific Behavior

    For behaviour which is specified by the 1998 and 2003 standards, see C++ 1998/2003 Implementation Specific Behavior. This section documents behaviour which is required by TR1. @@ -311,7 +303,7 @@ release. 3.6.4 [tr.func.bind.place]/1 There are 29 placeholders defined and the placeholder types are Assignable. -

    C++ TR 24733

    +

    C++ TR 24733

    This table is based on the table of contents of ISO/IEC TR 24733 Date: 2009-08-28 Extension for the programming language C++ to support @@ -319,7 +311,7 @@ decimal floating-point arithmetic

    This page describes the TR 24733 support in mainline GCC SVN, not in any particular release. -

    Table 1.4. C++ TR 24733 Implementation Status

    SectionDescriptionStatusComments
    +

    Table 1.4. C++ TR 24733 Implementation Status

    SectionDescriptionStatusComments
    0 Introduction @@ -339,7 +331,7 @@ particular release. 4 Notes on C compatibility -

    Prev Up Next
    Part I.  +

    Prev Up Next
    Part I.  Introduction  Home License
    diff --git a/libstdc++-v3/doc/html/manual/streambufs.html b/libstdc++-v3/doc/html/manual/streambufs.html index a5364771613..4030501dadd 100644 --- a/libstdc++-v3/doc/html/manual/streambufs.html +++ b/libstdc++-v3/doc/html/manual/streambufs.html @@ -1,17 +1,9 @@ -Stream Buffers
    Stream Buffers
    Prev Chapter 13.  + + +Stream Buffers
    Stream Buffers
    Prev Chapter 13.  Input and Output - Next

    Stream Buffers

    Derived streambuf Classes

    +

    		 Next

    Stream Buffers

    Derived streambuf Classes

    Creating your own stream buffers for I/O can be remarkably easy. If you are interested in doing so, we highly recommend two very excellent books: @@ -65,7 +57,7 @@ include/ext/*_filebuf.h, and in this article by James Kanze: Filtering Streambufs. -

    Buffering

    First, are you sure that you understand buffering? Particularly +

    Buffering

    First, are you sure that you understand buffering? Particularly the fact that C++ may not, in fact, have anything to do with it?

    The rules for buffering can be a little odd, but they aren't any different from those of C. (Maybe that's why they can be a bit @@ -139,7 +131,7 @@ just those at the language/library level. Kernel buffers, disk buffers, and the like will also have an effect. Inspecting and changing those are system-dependent. -

    Prev Up Next
    Chapter 13.  +

    Prev Up Next
    Chapter 13.  Input and Output  Home Memory Based Streams
    diff --git a/libstdc++-v3/doc/html/manual/strings.html b/libstdc++-v3/doc/html/manual/strings.html index 3732169acf0..6e41f270b5d 100644 --- a/libstdc++-v3/doc/html/manual/strings.html +++ b/libstdc++-v3/doc/html/manual/strings.html @@ -1,22 +1,14 @@ -Chapter 7.  Strings
    Chapter 7.  + + +Chapter 7.  Strings
    Chapter 7.  Strings
    Prev Part II.  Standard Contents -  Next

    Chapter 7.  +

    		 Next

    Chapter 7.  Strings - -

    Table of Contents

    String Classes
    Simple Transformations
    Case Sensitivity
    Arbitrary Character Types
    Tokenizing
    Shrink to Fit
    CString (MFC)

    String Classes

    Simple Transformations

    + +

    Table of Contents

    String Classes
    Simple Transformations
    Case Sensitivity
    Arbitrary Character Types
    Tokenizing
    Shrink to Fit
    CString (MFC)

    String Classes

    Simple Transformations

    Here are Standard, simple, and portable ways to perform common transformations on a string instance, such as "convert to all upper case." The word transformations @@ -97,7 +89,7 @@ str.erase(notwhite+1);

    Obviously, the calls to find could be inserted directly into the calls to erase, in case your compiler does not optimize named temporaries out of existence. -

    Case Sensitivity

    +

    Case Sensitivity

    The well-known-and-if-it-isn't-well-known-it-ought-to-be Guru of the Week discussions held on Usenet covered this topic in January of 1998. @@ -134,7 +126,7 @@ Unicode Technical Report discussing case handling, which provides some very good information. -

    Arbitrary Character Types

    +

    Arbitrary Character Types

    The std::basic_string is tantalizingly general, in that it is parameterized on the type of the characters which it holds. In theory, you could whip up a Unicode character class and instantiate @@ -188,7 +180,7 @@ nice-looking first attempt turned out to not be conforming C++, due to the rule that CharT must be a POD. (See how tricky this is?) -

    Tokenizing

    +

    Tokenizing

    The Standard C (and C++) function strtok() leaves a lot to be desired in terms of user-friendliness. It's unintuitive, it destroys the character string on which it operates, and it requires @@ -264,7 +256,7 @@ stringtok(Container &container, string const &in, tokenizing as well. Build an istringstream from the input text, and then use std::getline with varying delimiters (the three-argument signature) to extract tokens into a string. -

    Shrink to Fit

    +

    Shrink to Fit

    From GCC 3.4 calling s.reserve(res) on a string s with res < s.capacity() will reduce the string's capacity to std::max(s.size(), res). @@ -280,7 +272,7 @@ stringtok(Container &container, string const &in,

    In C++11 mode you can call s.shrink_to_fit() to achieve the same effect as s.reserve(s.size()). -

    CString (MFC)

    +

    CString (MFC)

    A common lament seen in various newsgroups deals with the Standard string class as opposed to the Microsoft Foundation Class called CString. Often programmers realize that a standard portable @@ -368,7 +360,7 @@ stringtok(Container &container, string const &in, libstdc++ string, the SGI string, and the SGI rope, and this is all before any allocator or traits customizations! (More choices than you can shake a stick at -- want fries with that?) -

    Prev Up Next
    Traits Home Chapter 8.  +

    Prev Up Next
    Traits Home Chapter 8.  Localization
    diff --git a/libstdc++-v3/doc/html/manual/stringstreams.html b/libstdc++-v3/doc/html/manual/stringstreams.html index ffe0e400cad..e501e19444a 100644 --- a/libstdc++-v3/doc/html/manual/stringstreams.html +++ b/libstdc++-v3/doc/html/manual/stringstreams.html @@ -1,17 +1,9 @@ -Memory Based Streams
    Memory Based Streams
    Prev Chapter 13.  + + +Memory Based Streams
    Memory Based Streams
    Prev Chapter 13.  Input and Output - Next

    Memory Based Streams

    Compatibility With strstream

    +

    		 Next

    Memory Based Streams

    Compatibility With strstream

    Stringstreams (defined in the header <sstream>) are in this author's opinion one of the coolest things since sliced time. An example of their use is in the Received Wisdom @@ -42,4 +34,4 @@ memory yourself. The strstreams have been officially deprecated, which means that 1) future revisions of the C++ Standard won't support them, and 2) if you use them, people will laugh at you. -

    Prev Up Next
    Stream Buffers Home File Based Streams
    +

    Prev Up Next
    Stream Buffers Home File Based Streams
    diff --git a/libstdc++-v3/doc/html/manual/support.html b/libstdc++-v3/doc/html/manual/support.html index 768ee0036ec..16f78d1374a 100644 --- a/libstdc++-v3/doc/html/manual/support.html +++ b/libstdc++-v3/doc/html/manual/support.html @@ -1,22 +1,14 @@ -Chapter 4.  Support
    Chapter 4.  + + +Chapter 4.  Support
    Chapter 4.  Support
    Prev Part II.  Standard Contents -  Next

    Chapter 4.  +

    		 Next

    Chapter 4.  Support - -

    Table of Contents

    Types
    Fundamental Types
    Numeric Properties
    NULL
    Dynamic Memory
    Termination
    Termination Handlers
    Verbose Terminate Handler

    + +

    Table of Contents

    Types
    Fundamental Types
    Numeric Properties
    NULL
    Dynamic Memory
    Termination
    Termination Handlers
    Verbose Terminate Handler

    This part deals with the functions called and objects created automatically during the course of a program's existence.

    @@ -24,7 +16,7 @@ need to get your own copy from your nation's member body; see our homepage for help), we can mention a couple of changes in what kind of support a C++ program gets from the Standard Library. -

    Types

    Fundamental Types

    +

    Types

    Fundamental Types

    C++ has the following builtin types:

    • char @@ -61,7 +53,7 @@

      Specializing parts of the library on these types is prohibited: instead, use a POD. -

    Numeric Properties

    +

    Numeric Properties

    The header limits defines traits classes to give access to various implementation defined-aspects of the fundamental types. The traits classes -- @@ -107,7 +99,7 @@ static const bool tinyness_before; static const float_round_style round_style; }; -

    NULL

    +

    NULL

    The only change that might affect people is the type of NULL: while it is required to be a macro, the definition of that macro is not allowed @@ -133,6 +125,6 @@

    See the Effective C++ CD example -

    Prev Up Next
    Part II.  +

    Prev Up Next
    Part II.  Standard Contents  Home Dynamic Memory
    diff --git a/libstdc++-v3/doc/html/manual/termination.html b/libstdc++-v3/doc/html/manual/termination.html index bfc8484a2a9..fc7389f100a 100644 --- a/libstdc++-v3/doc/html/manual/termination.html +++ b/libstdc++-v3/doc/html/manual/termination.html @@ -1,17 +1,9 @@ -Termination
    Termination
    Prev Chapter 4.  + + +Termination
    Termination
    Prev Chapter 4.  Support - Next

    Termination

    Termination Handlers

    +

    		 Next

    Termination

    Termination Handlers

    Not many changes here to cstdlib. You should note that the abort() function does not call the destructors of automatic nor static objects, so if you're @@ -53,7 +45,7 @@ functions, and the compiler/library might already be using some of those slots. If you think you may run out, we recommend using the xatexit/xexit combination from libiberty, which has no such limit. -

    Verbose Terminate Handler

    +

    Verbose Terminate Handler

    If you are having difficulty with uncaught exceptions and want a little bit of help debugging the causes of the core dumps, you can make use of a GNU extension, the verbose terminate handler. @@ -126,7 +118,7 @@ int main(int argc) inappropriate location, __verbose_terminate_handler will behave in an unspecified manner. -

    Prev Up Next
    Dynamic Memory Home Chapter 5.  +

    Prev Up Next
    Dynamic Memory Home Chapter 5.  Diagnostics
    diff --git a/libstdc++-v3/doc/html/manual/test.html b/libstdc++-v3/doc/html/manual/test.html index 386fbb8f246..16a03ca0241 100644 --- a/libstdc++-v3/doc/html/manual/test.html +++ b/libstdc++-v3/doc/html/manual/test.html @@ -1,34 +1,12 @@ -Test
    Test
    Prev Appendix B.  + + +Test
    Test
    Prev Appendix B.  Porting and Maintenance - Next

    Test

    +

    		 Next

    Test

    The libstdc++ testsuite includes testing for standard conformance, regressions, ABI, and performance. -

    Organization

    Directory Layout

    +

    Organization

    Directory Layout

    The directory libsrcdir/testsuite contains the individual test cases organized in sub-directories corresponding to chapters of the C++ standard (detailed below), the dejagnu test @@ -99,7 +77,7 @@ util Files for libtestc++, utilities and testing routines.

    All new tests should be written with the policy of one test case, one file in mind. -

    Naming Conventions

    +

    Naming Conventions

    In addition, there are some special names and suffixes that are used within the testsuite to designate particular kinds of tests. @@ -153,7 +131,7 @@ cat 27_io/objects/char/3_xin.in | a.out analyze runtime performance, for performance regression testing, or for other optimization related analysis. At the moment, these test cases are not run by default. -

    Running the Testsuite

    Basic

    +

    Running the Testsuite

    Basic

    You can check the status of the build without installing it using the dejagnu harness, much like the rest of the gcc tools.

     make check

    in the libbuilddir directory.

    or

     make check-target-libstdc++-v3

    in the gccbuilddir directory. @@ -173,7 +151,7 @@ cat 27_io/objects/char/3_xin.in | a.out archived on a daily basis on the gcc-testresults mailing list. Please check either of these places for a similar combination of source version, operating system, and host CPU. -

    Variations

    +

    Variations

    There are several options for running tests, including testing the regression tests, testing a subset of the regression tests, testing the performance tests, testing just compilation, testing @@ -299,7 +277,7 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite We are interested in any strange failures of the testsuite; please email the main libstdc++ mailing list if you see something odd or have questions. -

    Permutations

    +

    Permutations

    To run the libstdc++ test suite under the debug mode, edit libstdc++-v3/scripts/testsuite_flags to add the compile-time flag -D_GLIBCXX_DEBUG to the @@ -319,7 +297,7 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite Or, just run the testsuites with CXXFLAGS set to -D_GLIBCXX_DEBUG or -D_GLIBCXX_PARALLEL. -

    Writing a new test case

    +

    Writing a new test case

    The first step in making a new test case is to choose the correct directory and file name, given the organization as previously described. @@ -430,7 +408,7 @@ up in the normal.exp file. // { dg-options "-O0" { target *-*-* } }

    More examples can be found in the libstdc++-v3/testsuite/*/*.cc files. -

    Test Harness and Utilities

    Dejagnu Harness Details

    +

    Test Harness and Utilities

    Dejagnu Harness Details

    Underlying details of testing for conformance and regressions are abstracted via the GNU Dejagnu package. This is similar to the rest of GCC. @@ -457,7 +435,7 @@ callbacks loaded from the support library.

    The config directory is searched for any particular "target board" information unique to this library. This is currently unused and sets only default variables. -

    Utilities

    +

    Utilities

    The testsuite directory also contains some files that implement functionality that is intended to make writing test cases easier, @@ -513,10 +491,10 @@ only default variables.

    A number of class abstractions for performance counters, and reporting functions including: -

    • time_counter

    • resource_counter

    • report_performance

    Special Topics

    +

    • time_counter

    • resource_counter

    • report_performance

    Special Topics

    Qualifying Exception Safety Guarantees - -

    Overview

    + +

    Overview

    Testing is composed of running a particular test sequence, and looking at what happens to the surrounding code when exceptions are thrown. Each test is composed of measuring @@ -546,7 +524,7 @@ only default variables. completes without an exception being thrown, assume all potential error paths have been exercised in a sequential manner. -

    +

    Existing tests

    • Ad Hoc @@ -585,7 +563,7 @@ as the allocator type. instrumentation to iterator and const_iterator types that throw conditionally on iterator operations. -

    +

    C++11 Requirements Test Sequence Descriptions

    • Basic @@ -658,4 +636,4 @@ C++11 Requirements Test Sequence Descriptions The general form demonstrated in testsuite/23_containers/list/requirements/exception/propagation_coherent.cc . The instantiating test object is __gnu_test::propagation_coherent and is detailed in testsuite/util/exception/safety.h. -

    Prev Up Next
    Porting to New Hardware or Operating Systems Home ABI Policy and Guidelines
    +

    Prev Up Next
    Porting to New Hardware or Operating Systems Home ABI Policy and Guidelines
    diff --git a/libstdc++-v3/doc/html/manual/traits.html b/libstdc++-v3/doc/html/manual/traits.html index 20c072940cf..9c3c83f6b3c 100644 --- a/libstdc++-v3/doc/html/manual/traits.html +++ b/libstdc++-v3/doc/html/manual/traits.html @@ -1,18 +1,10 @@ -Traits
    Traits
    Prev Chapter 6.  + + +Traits
    Traits
    Prev Chapter 6.  Utilities - Next

    Traits

    -

    Prev Up Next
    Memory Home Chapter 7.  + Next

    Traits

    +

    Prev Up Next
    Memory Home Chapter 7.  Strings
    diff --git a/libstdc++-v3/doc/html/manual/using.html b/libstdc++-v3/doc/html/manual/using.html index cf12a765419..39faa6b7a36 100644 --- a/libstdc++-v3/doc/html/manual/using.html +++ b/libstdc++-v3/doc/html/manual/using.html @@ -1,17 +1,9 @@ -Chapter 3. Using
    Chapter 3. Using
    Prev Part I.  + + +Chapter 3. Using
    Chapter 3. Using
    Prev Part I.  Introduction - Next

    Chapter 3. Using

    Table of Contents

    Command Options
    Headers
    Header Files
    Mixing Headers
    The C Headers and namespace std
    Precompiled Headers
    Macros
    Namespaces
    Available Namespaces
    namespace std
    Using Namespace Composition
    Linking
    Almost Nothing
    Finding Dynamic or Shared Libraries
    Concurrency
    Prerequisites
    Thread Safety
    Atomics
    IO
    Structure
    Defaults
    Future
    Alternatives
    Containers
    Exceptions
    Exception Safety
    Exception Neutrality
    Doing without
    Compatibility
    With C
    With POSIX thread cancellation
    Debugging Support
    Using g++
    Debug Versions of Library Binary Files
    Memory Leak Hunting
    Data Race Hunting
    Using gdb
    Tracking uncaught exceptions
    Debug Mode
    Compile Time Checking
    Profile-based Performance Analysis

    Command Options

    +

    		 Next

    Chapter 3. Using

    Table of Contents

    Command Options
    Headers
    Header Files
    Mixing Headers
    The C Headers and namespace std
    Precompiled Headers
    Macros
    Namespaces
    Available Namespaces
    namespace std
    Using Namespace Composition
    Linking
    Almost Nothing
    Finding Dynamic or Shared Libraries
    Concurrency
    Prerequisites
    Thread Safety
    Atomics
    IO
    Structure
    Defaults
    Future
    Alternatives
    Containers
    Exceptions
    Exception Safety
    Exception Neutrality
    Doing without
    Compatibility
    With C
    With POSIX thread cancellation
    Debugging Support
    Using g++
    Debug Versions of Library Binary Files
    Memory Leak Hunting
    Data Race Hunting
    Using gdb
    Tracking uncaught exceptions
    Debug Mode
    Compile Time Checking
    Profile-based Performance Analysis

    Command Options

    The set of features available in the GNU C++ library is shaped by several GCC @@ -19,5 +11,5 @@ enumerated and detailed in the table below.

    By default, g++ is equivalent to g++ -std=gnu++98. The standard library also defaults to this dialect. -

    Table 3.1. C++ Command Options

    Option FlagsDescription
    -std=c++98Use the 1998 ISO C++ standard plus amendments.
    -std=gnu++98As directly above, with GNU extensions.
    -std=c++11Use the 2011 ISO C++ standard.
    -std=gnu++11As directly above, with GNU extensions.
    -fexceptionsSee exception-free dialect
    -frttiAs above, but RTTI-free dialect.
    -pthread or -pthreadsFor ISO C++11 <thread>, <future>, - <mutex>, or <condition_variable>.
    -fopenmpFor parallel mode.

    Prev Up Next
    Make Home Headers
    +

    Table 3.1. C++ Command Options

    Option FlagsDescription
    -std=c++98Use the 1998 ISO C++ standard plus amendments.
    -std=gnu++98As directly above, with GNU extensions.
    -std=c++11Use the 2011 ISO C++ standard.
    -std=gnu++11As directly above, with GNU extensions.
    -fexceptionsSee exception-free dialect
    -frttiAs above, but RTTI-free dialect.
    -pthread or -pthreadsFor ISO C++11 <thread>, <future>, + <mutex>, or <condition_variable>.
    -fopenmpFor parallel mode.

    Prev Up Next
    Make Home Headers
    diff --git a/libstdc++-v3/doc/html/manual/using_concurrency.html b/libstdc++-v3/doc/html/manual/using_concurrency.html index d25b662cd82..ba47c950291 100644 --- a/libstdc++-v3/doc/html/manual/using_concurrency.html +++ b/libstdc++-v3/doc/html/manual/using_concurrency.html @@ -1,18 +1,10 @@ -Concurrency
    Concurrency
    Prev Chapter 3. Using Next

    Concurrency

    This section discusses issues surrounding the proper compilation + + +Concurrency

    Concurrency
    Prev Chapter 3. Using Next

    Concurrency

    This section discusses issues surrounding the proper compilation of multithreaded applications which use the Standard C++ library. This information is GCC-specific since the C++ standard does not address matters of multithreaded applications. -

    Prerequisites

    All normal disclaimers aside, multithreaded C++ application are +

    Prerequisites

    All normal disclaimers aside, multithreaded C++ application are only supported when libstdc++ and all user code was built with compilers which report (via gcc/g++ -v ) the same thread model and that model is not single. As long as your @@ -40,7 +32,7 @@ -pthread is honored. Some other ports use other switches. AFAIK, none of this is properly documented anywhere other than in ``gcc -dumpspecs'' (look at lib and cpp entries). -

    Thread Safety

    +

    Thread Safety

    In the terms of the 2011 C++ standard a thread-safe program is one which does not perform any conflicting non-atomic operations on memory locations and so does not contain any data races. @@ -163,9 +155,9 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) Threads and memory model for C++ pages, particularly the introduction and FAQ. -

    Atomics

    -

    IO

    This gets a bit tricky. Please read carefully, and bear with me. -

    Structure

    A wrapper +

    Atomics

    +

    IO

    This gets a bit tricky. Please read carefully, and bear with me. +

    Structure

    A wrapper type called __basic_file provides our abstraction layer for the std::filebuf classes. Nearly all decisions dealing with actual input and output must be made in __basic_file. @@ -173,7 +165,7 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) but is not used in the current code. Providing locking at any higher level is akin to providing locking within containers, and is not done for the same reasons (see the links above). -

    Defaults

    The __basic_file type is simply a collection of small wrappers around +

    Defaults

    The __basic_file type is simply a collection of small wrappers around the C stdio layer (again, see the link under Structure). We do no locking ourselves, but simply pass through to calls to fopen, fwrite, and so forth. @@ -195,7 +187,7 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) contained in the stream formatting classes (e.g., setting up callbacks inside an std::ofstream), you need to guard such accesses like any other critical shared resource. -

    Future

    A +

    Future

    A second choice may be available for I/O implementations: libio. This is disabled by default, and in fact will not currently work due to other issues. It will be revisited, however. @@ -220,10 +212,10 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) version will see calls from libstdc++ directly into the glibc already installed. For other platforms, a copy of the libio subsection will be built and included in libstdc++. -

    Alternatives

    Don't forget that other cstdio implementations are possible. You could +

    Alternatives

    Don't forget that other cstdio implementations are possible. You could easily write one to perform your own forms of locking, to solve your "interesting" problems. -

    Containers

    This section discusses issues surrounding the design of +

    Containers

    This section discusses issues surrounding the design of multithreaded applications which use Standard C++ containers. All information in this section is current as of the gcc 3.0 release and all later point releases. Although earlier gcc @@ -276,4 +268,4 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) useful are details on allocator options and capabilities. -

    Prev Up Next
    Linking Home Exceptions
    +

    Prev Up Next
    Linking Home Exceptions
    diff --git a/libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html b/libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html index 0d33f4b2749..c4277785e4e 100644 --- a/libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html +++ b/libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html @@ -1,14 +1,6 @@ -Linking
    Linking
    Prev Chapter 3. Using Next

    Linking

    Almost Nothing

    + + +Linking

    Linking
    Prev Chapter 3. Using Next

    Linking

    Almost Nothing

    Or as close as it gets: freestanding. This is a minimal configuration, with only partial support for the standard library. Assume only the following header files can be used: @@ -48,7 +40,7 @@ No attempt is made to verify that only the minimal subset identified above is actually used at compile time. Violations are diagnosed as undefined symbols at link time. -

    Finding Dynamic or Shared Libraries

    +

    Finding Dynamic or Shared Libraries

    If the only library built is the static library (libstdc++.a), or if specifying static linking, this section is can be skipped. But @@ -111,4 +103,4 @@ A quick read of the relevant part of the GCC also installed, for use with Libtool. If you use Libtool to create your executables, these details are taken care of for you. -

    Prev Up Next
    Namespaces Home Concurrency
    +

    Prev Up Next
    Namespaces Home Concurrency
    diff --git a/libstdc++-v3/doc/html/manual/using_exceptions.html b/libstdc++-v3/doc/html/manual/using_exceptions.html index 26527bfa842..24014c9893e 100644 --- a/libstdc++-v3/doc/html/manual/using_exceptions.html +++ b/libstdc++-v3/doc/html/manual/using_exceptions.html @@ -1,28 +1,6 @@ -Exceptions
    Exceptions
    Prev Chapter 3. Using Next

    Exceptions

    + + +Exceptions

    Exceptions
    Prev Chapter 3. Using Next

    Exceptions

    The C++ language provides language support for stack unwinding with try and catch blocks and the throw keyword. @@ -34,7 +12,7 @@ exceptional circumstances.

    Two general topics of discussion follow: exception neutrality and exception safety. -

    Exception Safety

    +

    Exception Safety

    What is exception-safe code?

    Will define this as reasonable and well-defined behavior by classes @@ -73,7 +51,7 @@ exception neutrality and exception safety. Member functions insert of a single element, push_back, push_front, and rehash. -

    Exception Neutrality

    +

    Exception Neutrality

    Simply put, once thrown an exception object should continue in flight unless handled explicitly. In practice, this means propagating exceptions should not be swallowed in @@ -123,7 +101,7 @@ exception neutrality and exception safety. The constructors of thread that take a callable function argument swallow all exceptions resulting from executing the function argument. -

    Doing without

    +

    Doing without

    C++ is a language that strives to be as efficient as is possible in delivering features. As such, considerable care is used by both language implementer and designers to make sure unused features @@ -242,7 +220,7 @@ exception neutrality and exception safety. substitution of the C language keyword const with the uglified doppelganger __const. -

    Compatibility

    With C

    +

    Compatibility

    With C

    C language code that is expecting to interoperate with C++ should be compiled with -fexceptions. This will make debugging a C language function called as part of C++-induced stack @@ -257,7 +235,7 @@ is called. getting these details right. For GNU systems, all appropriate parts of the GNU C library are already compiled with -fexceptions. -

    With POSIX thread cancellation

    +

    With POSIX thread cancellation

    GNU systems re-use some of the exception handling mechanisms to track control flow for POSIX thread cancellation.

    @@ -288,49 +266,49 @@ is called. } catch(...) { this->_M_setstate(ios_base::badbit); } -

    Bibliography

    +

    Bibliography

    System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008) - . + . 2.9.5 Thread Cancellation . Copyright © 2008 The Open Group/The Institute of Electrical and Electronics Engineers, Inc. - .

    + .

    Error and Exception Handling - . David Abrahams . + . David Abrahams . Boost - .

    + .

    Exception-Safety in Generic Components - . David Abrahams. + . David Abrahams. Boost - .

    + .

    Standard Library Exception Policy - . Matt Austern. + . Matt Austern. WG21 N1077 - .

    + .

    ia64 c++ abi exception handling - . Richard Henderson. + . Richard Henderson. GNU - .

    + .

    Appendix E: Standard-Library Exception Safety - . Bjarne Stroustrup.

    + . Bjarne Stroustrup.

    Exceptional C++ . Exception-Safety Issues and Techniques - . Herb Sutter.

    + . Herb Sutter.

    GCC Bug 25191: exception_defines.h #defines try/catch - .

    Prev Up Next
    Concurrency Home Debugging Support
    + .

    Prev Up Next
    Concurrency Home Debugging Support
    diff --git a/libstdc++-v3/doc/html/manual/using_headers.html b/libstdc++-v3/doc/html/manual/using_headers.html index 9114baac929..85b133b66ca 100644 --- a/libstdc++-v3/doc/html/manual/using_headers.html +++ b/libstdc++-v3/doc/html/manual/using_headers.html @@ -1,14 +1,6 @@ -Headers
    Headers
    Prev Chapter 3. Using Next

    Headers

    Header Files

    + + +Headers

    Headers
    Prev Chapter 3. Using Next

    Headers

    Header Files

    The C++ standard specifies the entire set of header files that must be available to all hosted implementations. Actually, the word "files" is a misnomer, since the contents of the @@ -27,19 +19,19 @@ the 1998 standard as updated for 2003, and the current 2011 standard.

    C++98/03 include files. These are available in the default compilation mode, i.e. -std=c++98 or -std=gnu++98. -

    Table 3.2. C++ 1998 Library Headers

    algorithmbitsetcomplexdequeexception
    fstreamfunctionaliomanipiosiosfwd
    iostreamistreamiteratorlimitslist
    localemapmemorynewnumeric
    ostreamqueuesetsstreamstack
    stdexceptstreambufstringutilitytypeinfo
    valarrayvector   

    Table 3.3. C++ 1998 Library Headers for C Library Facilities

    cassertcerrnocctypecfloatciso646
    climitsclocalecmathcsetjmpcsignal
    cstdargcstddefcstdiocstdlibcstring
    ctimecwcharcwctype  

    +

    Table 3.2. C++ 1998 Library Headers

    algorithmbitsetcomplexdequeexception
    fstreamfunctionaliomanipiosiosfwd
    iostreamistreamiteratorlimitslist
    localemapmemorynewnumeric
    ostreamqueuesetsstreamstack
    stdexceptstreambufstringutilitytypeinfo
    valarrayvector   

    Table 3.3. C++ 1998 Library Headers for C Library Facilities

    cassertcerrnocctypecfloatciso646
    climitsclocalecmathcsetjmpcsignal
    cstdargcstddefcstdiocstdlibcstring
    ctimecwcharcwctype  

    C++11 include files. These are only available in C++11 compilation mode, i.e. -std=c++11 or -std=gnu++11. -

    Table 3.4. C++ 2011 Library Headers

    algorithmarraybitsetchronocomplex
    condition_variabledequeexceptionforward_listfstream
    functionalfutureinitalizer_listiomanipios
    iosfwdiostreamistreamiteratorlimits
    listlocalemapmemorymutex
    newnumericostreamqueuerandom
    ratioregexsetsstreamstack
    stdexceptstreambufstringsystem_errorthread
    tupletype_traitstypeinfounordered_mapunordered_set
    utilityvalarrayvector  

    Table 3.5. C++ 2011 Library Headers for C Library Facilities

    cassertccomplexcctypecerrnocfenv
    cfloatcinttypesciso646climitsclocale
    cmathcsetjmpcsignalcstdargcstdbool
    cstddefcstdintcstdlibcstdiocstring
    ctgmathctimecucharcwcharcwctype

    +

    Table 3.4. C++ 2011 Library Headers

    algorithmarraybitsetchronocomplex
    condition_variabledequeexceptionforward_listfstream
    functionalfutureinitalizer_listiomanipios
    iosfwdiostreamistreamiteratorlimits
    listlocalemapmemorymutex
    newnumericostreamqueuerandom
    ratioregexsetsstreamstack
    stdexceptstreambufstringsystem_errorthread
    tupletype_traitstypeinfounordered_mapunordered_set
    utilityvalarrayvector  

    Table 3.5. C++ 2011 Library Headers for C Library Facilities

    cassertccomplexcctypecerrnocfenv
    cfloatcinttypesciso646climitsclocale
    cmathcsetjmpcsignalcstdargcstdbool
    cstddefcstdintcstdlibcstdiocstring
    ctgmathctimecucharcwcharcwctype

    In addition, TR1 includes as: -

    Table 3.6. C++ TR 1 Library Headers

    tr1/arraytr1/complextr1/memorytr1/functionaltr1/random
    tr1/regextr1/tupletr1/type_traitstr1/unordered_maptr1/unordered_set
    tr1/utility    

    Table 3.7. C++ TR 1 Library Headers for C Library Facilities

    tr1/ccomplextr1/cfenvtr1/cfloattr1/cmathtr1/cinttypes
    tr1/climitstr1/cstdargtr1/cstdbooltr1/cstdinttr1/cstdio
    tr1/cstdlibtr1/ctgmathtr1/ctimetr1/cwchartr1/cwctype

    Decimal floating-point arithmetic is available if the C++ +

    Table 3.6. C++ TR 1 Library Headers

    tr1/arraytr1/complextr1/memorytr1/functionaltr1/random
    tr1/regextr1/tupletr1/type_traitstr1/unordered_maptr1/unordered_set
    tr1/utility    

    Table 3.7. C++ TR 1 Library Headers for C Library Facilities

    tr1/ccomplextr1/cfenvtr1/cfloattr1/cmathtr1/cinttypes
    tr1/climitstr1/cstdargtr1/cstdbooltr1/cstdinttr1/cstdio
    tr1/cstdlibtr1/ctgmathtr1/ctimetr1/cwchartr1/cwctype

    Decimal floating-point arithmetic is available if the C++ compiler supports scalar decimal floating-point types defined via __attribute__((mode(SD|DD|LD))). -

    Table 3.8. C++ TR 24733 Decimal Floating-Point Header

    decimal/decimal

    +

    Table 3.8. C++ TR 24733 Decimal Floating-Point Header

    decimal/decimal

    Also included are files for the C++ ABI interface: -

    Table 3.9. C++ ABI Headers

    cxxabi.hcxxabi_forced.h

    +

    Table 3.9. C++ ABI Headers

    cxxabi.hcxxabi_forced.h

    And a large variety of extensions. -

    Table 3.10. Extension Headers

    ext/algorithmext/atomicity.hext/array_allocator.hext/bitmap_allocator.hext/cast.h
    ext/codecvt_specializations.hext/concurrence.hext/debug_allocator.hext/enc_filebuf.hext/extptr_allocator.h
    ext/functionalext/iteratorext/malloc_allocator.hext/memoryext/mt_allocator.h
    ext/new_allocator.hext/numericext/numeric_traits.hext/pb_ds/assoc_container.hext/pb_ds/priority_queue.h
    ext/pod_char_traits.hext/pool_allocator.hext/rb_treeext/ropeext/slist
    ext/stdio_filebuf.hext/stdio_sync_filebuf.hext/throw_allocator.hext/typelist.hext/type_traits.h
    ext/vstring.h    

    Table 3.11. Extension Debug Headers

    debug/bitsetdebug/dequedebug/listdebug/mapdebug/set
    debug/stringdebug/unordered_mapdebug/unordered_setdebug/vector 

    Table 3.12. Extension Profile Headers

    profile/bitsetprofile/dequeprofile/listprofile/map
    profile/setprofile/unordered_mapprofile/unordered_setprofile/vector

    Table 3.13. Extension Parallel Headers

    parallel/algorithmparallel/numeric

    Mixing Headers

    A few simple rules. +

    Table 3.10. Extension Headers

    ext/algorithmext/atomicity.hext/array_allocator.hext/bitmap_allocator.hext/cast.h
    ext/codecvt_specializations.hext/concurrence.hext/debug_allocator.hext/enc_filebuf.hext/extptr_allocator.h
    ext/functionalext/iteratorext/malloc_allocator.hext/memoryext/mt_allocator.h
    ext/new_allocator.hext/numericext/numeric_traits.hext/pb_ds/assoc_container.hext/pb_ds/priority_queue.h
    ext/pod_char_traits.hext/pool_allocator.hext/rb_treeext/ropeext/slist
    ext/stdio_filebuf.hext/stdio_sync_filebuf.hext/throw_allocator.hext/typelist.hext/type_traits.h
    ext/vstring.h    

    Table 3.11. Extension Debug Headers

    debug/bitsetdebug/dequedebug/listdebug/mapdebug/set
    debug/stringdebug/unordered_mapdebug/unordered_setdebug/vector 

    Table 3.12. Extension Profile Headers

    profile/bitsetprofile/dequeprofile/listprofile/map
    profile/setprofile/unordered_mapprofile/unordered_setprofile/vector

    Table 3.13. Extension Parallel Headers

    parallel/algorithmparallel/numeric

    Mixing Headers

    A few simple rules.

    First, mixing different dialects of the standard headers is not possible. It's an all-or-nothing affair. Thus, code like 

    @@ -62,7 +54,7 @@ same translation unit:
 #include <tr1/type_traits>
 #include <type_traits>

    Several parts of C++11 diverge quite substantially from TR1 predecessors. -

    The C Headers and namespace std

    +

    The C Headers and namespace std

    The standard specifies that if one includes the C-style header (<math.h> in this case), the symbols will be available in the global namespace and perhaps in @@ -81,7 +73,7 @@ floating-point types. This means that std::sin can be used uniformly, instead of a combination of std::sinf, std::sin, and std::sinl. -

    Precompiled Headers

    There are three base header files that are provided. They can be +

    Precompiled Headers

    There are three base header files that are provided. They can be used to precompile the standard headers and extensions into binary files that may the be used to speed compiles that use these headers.

    • stdc++.h

      Includes all standard headers. Actual content varies depending on @@ -108,4 +100,4 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe . /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/iostream . /mnt/share/bld/H-x86-gcc.20071201include/c++/4.3.0/string

      The exclamation point to the left of the stdc++.h.gch listing means that the generated PCH file was used, and thus the

      Detailed information about creating precompiled header files can be found in the GCC documentation. -

    Prev Up Next
    Chapter 3. Using Home Macros
    +

    Prev Up Next
    Chapter 3. Using Home Macros
    diff --git a/libstdc++-v3/doc/html/manual/using_macros.html b/libstdc++-v3/doc/html/manual/using_macros.html index add71d16ec1..cd4408a9516 100644 --- a/libstdc++-v3/doc/html/manual/using_macros.html +++ b/libstdc++-v3/doc/html/manual/using_macros.html @@ -1,14 +1,6 @@ -Macros
    Macros
    Prev Chapter 3. Using Next

    Macros

    + + +Macros

    Macros
    Prev Chapter 3. Using Next

    Macros

    All library macros begin with _GLIBCXX_.

    Furthermore, all pre-processor macros, switches, and @@ -77,4 +69,4 @@

    _GLIBCXX_PROFILE

    Undefined by default. When defined, compiles user code using the profile mode. -

    Prev Up Next
    Headers Home Namespaces
    +

    Prev Up Next
    Headers Home Namespaces
    diff --git a/libstdc++-v3/doc/html/manual/using_namespaces.html b/libstdc++-v3/doc/html/manual/using_namespaces.html index a2dce76b309..e85b99c1459 100644 --- a/libstdc++-v3/doc/html/manual/using_namespaces.html +++ b/libstdc++-v3/doc/html/manual/using_namespaces.html @@ -1,14 +1,6 @@ -Namespaces
    Namespaces
    Prev Chapter 3. Using Next

    Namespaces

    Available Namespaces

    There are three main namespaces. + + +Namespaces

    Namespaces
    Prev Chapter 3. Using Next

    Namespaces

    Available Namespaces

    There are three main namespaces.

    • std

      The ISO C++ standards specify that "all library entities are defined within namespace std." This includes namespaces nested within namespace std, such as namespace @@ -20,7 +12,7 @@ but necessary for interoperability. include __gnu_cxx, __gnu_debug, __gnu_parallel, and __gnu_pbds.

    A complete list of implementation namespaces (including namespace contents) is available in the generated source documentation. -

    namespace std

    +

    namespace std

    One standard requirement is that the library components are defined in namespace std::. Thus, in order to use these types or functions, one must do one of two things: @@ -33,7 +25,7 @@ qualified name for each library symbol (i.e. std::string, std::cout) Always can be used, and usually enhanced, by strategic use of typedefs. (In the cases where the qualified verbiage becomes unwieldy.) -

    Using Namespace Composition

    +

    Using Namespace Composition

    Best practice in programming suggests sequestering new data or functionality in a sanely-named, unique namespace whenever possible. This is considered an advantage over dumping everything in @@ -66,4 +58,4 @@ namespace gtk std::string; (depending on whether the system has libstdc++ in std:: or not). (ideas from Llewelly and Karl Nelson) -

    Prev Up Next
    Macros Home Linking
    +

    Prev Up Next
    Macros Home Linking
    diff --git a/libstdc++-v3/doc/html/manual/utilities.html b/libstdc++-v3/doc/html/manual/utilities.html index 7bd79e2144b..e026584b34e 100644 --- a/libstdc++-v3/doc/html/manual/utilities.html +++ b/libstdc++-v3/doc/html/manual/utilities.html @@ -1,25 +1,17 @@ -Chapter 6.  Utilities
    Chapter 6.  + + +Chapter 6.  Utilities
    Chapter 6.  Utilities
    Prev Part II.  Standard Contents -  Next

    Chapter 6.  +

    		 Next

    Chapter 6.  Utilities - -

    Table of Contents

    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits

    Functors

    If you don't know what functors are, you're not alone. Many people + +

    Table of Contents

    Functors
    Pairs
    Memory
    Allocators
    Requirements
    Design Issues
    Implementation
    Interface Design
    Selecting Default Allocation Policy
    Disabling Memory Caching
    Using a Specific Allocator
    Custom Allocators
    Extension Allocators
    auto_ptr
    Limitations
    Use in Containers
    shared_ptr
    Requirements
    Design Issues
    Implementation
    Class Hierarchy
    Thread Safety
    Selecting Lock Policy
    Related functions and classes
    Use
    Examples
    Unresolved Issues
    Acknowledgments
    Traits

    Functors

    If you don't know what functors are, you're not alone. Many people get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in their http://www.sgi.com/tech/stl/functors.html. -

    Prev Up Next
    Concept Checking Home Pairs
    +

    Prev Up Next
    Concept Checking Home Pairs