+2010-02-22 Benjamin Kosnik <bkoz@redhat.com>
+
+ * doc/xml/class.txml: Adjust biblio markup.
+ * doc/xml/manual/allocator.xml: Same.
+ * doc/xml/manual/ctype.xml: Same.
+ * doc/xml/manual/codecvt.xml: Same.
+ * doc/xml/manual/backwards_compatibility.xml: Same.
+ * doc/xml/manual/abi.xml: Same.
+ * doc/xml/manual/shared_ptr.xml: Same.
+ * doc/xml/manual/profile_mode.xml: Same.
+ * doc/xml/manual/using_exceptions.xml: Same.
+ * doc/xml/manual/locale.xml: Same.
+ * doc/xml/manual/appendix_contributing.xml: Same.
+ * doc/xml/manual/messages.xml: Same.
+ * doc/Makefile.am (DBLATEX_FLAGS): Adjust.
+ * doc/Makefile.in: Regenerate.
+
2010-02-22 François Dumont <francois.cppdevs@free.fr>
* doc/xml/manual/profile_mode.xml: Minor updates and fixes.
# PDF 5
# dblatex
-DBLATEX_FLAGS = --verbose --pdf -o pdf/spine.pdf
+DBLATEX_FLAGS = --dump --verbose --pdf -o pdf/manual.pdf
doc-pdf-dblatex: $(xml_sources) ${glibcxx_builddir}/doc/pdf
@echo "Generating pdf dblatex files..."
dblatex $(DBLATEX_FLAGS) ${top_srcdir}/doc/xml/spine.xml
# PDF 5
# dblatex
-DBLATEX_FLAGS = --verbose --pdf -o pdf/spine.pdf
+DBLATEX_FLAGS = --dump --verbose --pdf -o pdf/manual.pdf
# By adding these files here, automake will remove them for 'make clean'
CLEANFILES = *.log
<abbrev>
</abbrev>
- <title>
- </title>
+ <biblioid class="uri">
+ <ulink url="http://about:blank">
+ <citetitle>
+ The Title
+ </citetitle>
+ </ulink>
+ </biblioid>
<editor>
<firstname></firstname>
</publishername>
</publisher>
- <biblioid>
- <ulink url="">
- </ulink>
- </biblioid>
-
</biblioentry>
-->
<sect1 id="appendix.porting.abi" xreflabel="abi">
<?dbhtml filename="abi.html"?>
-
+
<sect1info>
<keywordset>
<keyword>
perhaps also dependent on features in the C++ Standard Library.
</para>
-<para>
+<para>
The C++ Standard Library has many include files, types defined in
those include files, specific named functions, and other
behavior. The text of these behaviors, as written in source include
files, is called the Application Programing Interface, or API.
</para>
-<para>
+<para>
Furthermore, C++ source that is compiled into object files is
transformed by the compiler: it arranges objects with specific
alignment and in a particular layout, mangling names according to a
for Code Generation Conventions</ulink>.
</para>
-<para>
+<para>
The configure options used when building a specific libstdc++
version may also impact the resulting library ABI. The available
configure options, and their impact on the library ABI, are
C++ toolchain. With each release, various details have been changed so
as to give distinct versions to the C++ interface.
</para>
-
+
<sect3 id="abi.versioning.goals">
<title>Goals</title>
hppa-linux this is either libgcc_s.so.1 (when configuring
<code>--with-sjlj-exceptions</code>) or libgcc_s.so.2. For all
others, this is libgcc_s.so.1. </para>
- </listitem>
+ </listitem>
</itemizedlist>
-
+
</listitem>
<listitem><para>Symbol versioning on the libgcc_s.so binary.</para>
<listitem><para>gcc-4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4</para></listitem>
</itemizedlist>
</listitem>
-
+
<listitem>
<para>Incremental bumping of a compiler pre-defined macro,
__GXX_ABI_VERSION. This macro is defined as the version of the
be automatically defined whenever g++ is used (the curious can
test this by invoking g++ with the '-v' flag.)
</para>
-
+
<para>
This macro was defined in the file "lang-specs.h" in the gcc/cp directory.
Later versions defined it in "c-common.c" in the gcc directory, and from
%g++ hello.cc -o hello.out
%ldd hello.out
- libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000)
- libm.so.6 => /lib/tls/libm.so.6 (0x004a8000)
- libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
- libc.so.6 => /lib/tls/libc.so.6 (0x0036d000)
- /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
+ libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000)
+ libm.so.6 => /lib/tls/libm.so.6 (0x004a8000)
+ libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
+ libc.so.6 => /lib/tls/libc.so.6 (0x0036d000)
+ /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
%nm hello.out
</programlisting>
the way the compiler deals with this class in by-value return
statements or parameters: instead of being passing instances of this
class in registers, the compiler will be forced to use memory. See <ulink url="http://www.codesourcery.com/cxx-abi/abi.html#calls"> this part</ulink>
- of the C++ ABI documentation for further details.
+ of the C++ ABI documentation for further details.
</para></listitem>
</orderedlist>
<variablelist>
<varlistentry>
<term>Include files have declarations, source files have defines</term>
-
+
<listitem>
<para>
For non-templatized types, such as much of <code>class
</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>Extern template on required types</term>
</variablelist>
- <para>
+ <para>
In addition, these techniques have the additional benefit that they
reduce binary size, which can increase runtime performance.
</para>
</para>
<para>
- One. Intel ABI checker.
+ One. Intel ABI checker.
</para>
<para>
</para>
<para>
-One.
-(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
+One.
+(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
one with a new compiler and an old library, and the other with an old
compiler and a new library, and look for testsuite regressions)
</para>
</para>
<para>
-Two.
-Use the 'make check-abi' rule in the libstdc++ Makefile.
+Two.
+Use the 'make check-abi' rule in the libstdc++ Makefile.
</para>
<para>
<para>
This dataset is insufficient, yet a start. Also needed is a
comprehensive check for all user-visible types part of the standard
-library for sizeof() and alignof() changes.
+library for sizeof() and alignof() changes.
</para>
<para>
%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc
-%ar cru libone.a a.o
+%ar cru libone.a a.o
</programlisting>
<para> And, libtwo is constructed as follows: </para>
%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc
-%ar cru libtwo.a b.o
+%ar cru libtwo.a b.o
</programlisting>
<para> ...with the resulting libraries looking like </para>
<screen>
<computeroutput>
%ldd libone.so.1.0.0
- libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40016000)
- libm.so.6 => /lib/tls/libm.so.6 (0x400fa000)
- libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
- libc.so.6 => /lib/tls/libc.so.6 (0x40125000)
- /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
+ libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40016000)
+ libm.so.6 => /lib/tls/libm.so.6 (0x400fa000)
+ libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
+ libc.so.6 => /lib/tls/libc.so.6 (0x40125000)
+ /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
%ldd libtwo.so.1.0.0
- libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000)
- libm.so.6 => /lib/tls/libm.so.6 (0x400e1000)
- libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
- libc.so.6 => /lib/tls/libc.so.6 (0x4010c000)
- /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
+ libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000)
+ libm.so.6 => /lib/tls/libm.so.6 (0x400e1000)
+ libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
+ libc.so.6 => /lib/tls/libc.so.6 (0x4010c000)
+ /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
</computeroutput>
</screen>
-<para>
+<para>
Then, the "C" compiler is used to compile a source file that uses
functions from each library.
</para>
<screen>
<computeroutput>
%ldd a.out
- libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000)
- libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000)
- libc.so.6 => /lib/tls/libc.so.6 (0x0036d000)
- libm.so.6 => /lib/tls/libm.so.6 (0x004a8000)
- libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
- /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
+ libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000)
+ libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000)
+ libc.so.6 => /lib/tls/libc.so.6 (0x0036d000)
+ libm.so.6 => /lib/tls/libm.so.6 (0x004a8000)
+ libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
+ /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000)
</computeroutput>
</screen>
<sect2 id="abi.issues">
<title>Outstanding Issues</title>
-<para>
+<para>
Some features in the C++ language make versioning especially
difficult. In particular, compiler generated constructs such as
implicit instantiations for templates, typeinfo information, and
<title>Bibliography</title>
<biblioentry>
- <title>
- ABIcheck, a vague idea of checking ABI compatibility
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://abicheck.sourceforge.net/">
+ <citetitle>
+ ABIcheck, a vague idea of checking ABI compatibility
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- C++ ABI Reference
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://www.codesourcery.com/public/cxx-abi/">
+ <citetitle>
+ C++ ABI Reference
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Intel® Compilers for Linux* -Compatibility with the GNU Compilers
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://www.intel.com/cd/software/products/asmo-na/eng/284736.htm">
+ <citetitle>
+ Intel Compilers for Linux Compatibility with the GNU Compilers
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386)
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://docs.sun.com/app/docs/doc/817-1984">
+ <citetitle>
+ Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386)
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Sun Solaris 2.9 : C++ Migration Guide (document 816-2459)
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://docs.sun.com/app/docs/doc/819-5266">
+ <citetitle>
+ Sun Solaris 2.9 : C++ Migration Guide (document 816-2459)
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- How to Write Shared Libraries
- </title>
+ <biblioid class="uri">
+ <ulink url="http://people.redhat.com/drepper/dsohowto.pdf">
+ <citetitle>
+ How to Write Shared Libraries
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Ulrich</firstname>
<surname>Drepper</surname>
</author>
-
- <biblioid>
- <ulink url="http://people.redhat.com/drepper/dsohowto.pdf">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- C++ ABI for the ARM Architecture
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://www.arm.com/miscPDFs/8033.pdf">
+ <citetitle>
+ C++ ABI for the ARM Architecture
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Dynamic Shared Objects: Survey and Issues
- </title>
+ <biblioid class="uri">
+ <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html">
+ <citetitle>
+ Dynamic Shared Objects: Survey and Issues
+ </citetitle>
+ </ulink>
+ </biblioid>
<subtitle>
ISO C++ J16/06-0046
</subtitle>
-
<author>
<firstname>Benjamin</firstname>
<surname>Kosnik</surname>
</author>
-
- <biblioid>
- <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Versioning With Namespaces
- </title>
+ <biblioid class="uri">
+ <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html">
+ <citetitle>
+ Versioning With Namespaces
+ </citetitle>
+ </ulink>
+ </biblioid>
<subtitle>
ISO C++ J16/06-0083
</subtitle>
-
<author>
<firstname>Benjamin</firstname>
<surname>Kosnik</surname>
</author>
-
- <biblioid>
- <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Binary Compatibility of Shared Libraries Implemented in C++ on GNU/Linux Systems
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://syrcose.ispras.ru/2009/files/SYRCoSE2009-CfP.pdf">
+ <citetitle>
+ Binary Compatibility of Shared Libraries Implemented in C++
+ on GNU/Linux Systems
+ </citetitle>
+ </ulink>
+ </biblioid>
<subtitle>
-SYRCoSE 2009
+ SYRCoSE 2009
</subtitle>
-
<author>
<firstname>Pavel</firstname>
<surname>Shved</surname>
</author>
-
<author>
<firstname>Denis</firstname>
<surname>Silakov</surname>
</author>
-
- <biblioid>
- <ulink url="http://syrcose.ispras.ru/2009/files/SYRCoSE2009-CfP.pdf">
- </ulink>
- </biblioid>
- </biblioentry>
-
+ </biblioentry>
</bibliography>
</sect1>
<sect1 id="manual.util.memory.allocator" xreflabel="Allocator">
<?dbhtml filename="allocator.html"?>
-
+
<sect1info>
<keywordset>
<keyword>
<listitem>
<para>
The interface of the <classname>allocator<T></classname> class is
- extremely simple. It has about 20 public declarations (nested
- typedefs, member functions, etc), but the two which concern us most
- are:
+ extremely simple. It has about 20 public declarations (nested
+ typedefs, member functions, etc), but the two which concern us most
+ are:
</para>
<programlisting>
T* allocate (size_type n, const void* hint = 0);
functions is a <emphasis>count</emphasis> of the number of
<type>T</type>'s to allocate space for, <emphasis>not their
total size</emphasis>.
- (This is a simplification; the real signatures use nested typedefs.)
+ (This is a simplification; the real signatures use nested typedefs.)
</para>
</listitem>
<listitem>
<para>
The storage is obtained by calling <function>::operator
new</function>, but it is unspecified when or how
- often this function is called. The use of the
+ often this function is called. The use of the
<varname>hint</varname> is unspecified, but intended as an
aid to locality if an implementation so
desires. <constant>[20.4.1.1]/6</constant>
</listitem>
</itemizedlist>
- <para>
+ <para>
Complete details can be found in the C++ standard, look in
<constant>[20.4 Memory]</constant>.
</para>
<function>std::malloc</function> and <function>free</function>.
</para>
- <para>
+ <para>
Another approach is to use intelligence within the allocator
class to cache allocations. This extra machinery can take a variety
of forms: a bitmap index, an index into an exponentially increasing
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
- been modified to support this change.
+ been modified to support this change.
</para>
- <para>
+ <para>
The class <classname>allocator</classname> just has typedef,
constructor, and rebind members. It inherits from one of the
high-speed extension allocators, covered below. Thus, all
allocation and deallocation depends on the base class.
</para>
- <para>
+ <para>
The base class that <classname>allocator</classname> is derived from
may not be user-configurable.
</para>
<sect3>
<title>Selecting Default Allocation Policy</title>
- <para>
+ <para>
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
for speed.
</para>
- <para>
+ <para>
Three synthetic benchmarks have been created that provide data
that is used to compare different C++ allocators. These tests are:
</para>
<orderedlist>
<listitem>
<para>
- Insertion.
+ Insertion.
</para>
<para>
Over multiple iterations, various STL container
objects have elements inserted to some maximum amount. A variety
- of allocators are tested.
+ of allocators are tested.
Test source for <ulink url="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert/sequence.cc?view=markup">sequence</ulink>
and <ulink url="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert/associative.cc?view=markup">associative</ulink>
containers.
<para>
This test shows the ability of the allocator to reclaim memory
on a per-thread basis, as well as measuring thread contention
- for memory resources.
- Test source
+ for memory resources.
+ Test source
<ulink url="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert_erase/associative.cc?view=markup">here</ulink>.
</para>
</listitem>
<para>
Test source for
<ulink url="http://gcc.gnu.org/viewcvs/trunk/libstdc++-v3/testsuite/performance/23_containers/producer_consumer/sequence.cc?view=markup">sequence</ulink>
- and
+ and
<ulink url="http://gcc.gnu.org/viewcvs/trunk/libstdc++-v3/testsuite/performance/23_containers/producer_consumer/associative.cc?view=markup">associative</ulink>
containers.
</para>
<sect3>
<title>Disabling Memory Caching</title>
- <para>
+ <para>
In use, <classname>allocator</classname> may allocate and
deallocate using implementation-specified strategies and
heuristics. Because of this, every call to an allocator object's
function.
</para>
- <para>
- This can be confusing.
+ <para>
+ This can be confusing.
</para>
- <para>
+ <para>
In particular, this can make debugging memory errors more
difficult, especially when using third party tools like valgrind or
debug versions of <function>new</function>.
</para>
- <para>
+ <para>
There are various ways to solve this problem. One would be to use
a custom allocator that just called operators
<function>new</function> and <function>delete</function>
<sect2 id="allocator.custom">
<title>Custom Allocators</title>
- <para>
+ <para>
Writing a portable C++ allocator would dictate that the interface
would look much like the one specified for
<classname>allocator</classname>. Additional member functions, but
not subtractions, would be permissible.
</para>
- <para>
+ <para>
Probably the best place to start would be to copy one of the
- extension allocators: say a simple one like
+ extension allocators: say a simple one like
<classname>new_allocator</classname>.
</para>
<sect2 id="allocator.ext">
<title>Extension Allocators</title>
- <para>
+ <para>
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
<para>
<classname>debug_allocator</classname>
</para>
- <para>
+ <para>
A wrapper around an arbitrary allocator A. It passes on
slightly increased size requests to A, and uses the extra
memory to store size information. When a pointer is passed
<para>
<classname>throw_allocator</classname>
</para>
- <para>
+ <para>
Includes memory tracking and marking abilities as well as hooks for
throwing exceptions at configurable intervals (including random,
- all, none).
+ all, none).
</para>
</listitem>
<listitem>
<para>
<classname>__pool_alloc</classname>
</para>
- <para>
+ <para>
A high-performance, single pool allocator. The reusable
memory is shared among identical instantiations of this type.
It calls through <function>::operator new</function> to
directly.
</para>
- <para>
+ <para>
Older versions of this class take a boolean template
parameter, called <varname>thr</varname>, and an integer template
parameter, called <varname>inst</varname>.
<para>
A high-performance allocator that uses a bit-map to keep track
of the used and unused memory locations. It has its own
- documentation, found <link
+ documentation, found <link
linkend="manual.ext.allocator.bitmap">here</link>.
</para>
</listitem>
<biblioentry>
<title>
- ISO/IEC 14882:1998 Programming languages - C++
+ ISO/IEC 14882:1998 Programming languages - C++
</title>
-
<abbrev>
isoc++_1998
</abbrev>
<pagenums>20.4 Memory</pagenums>
- </biblioentry>
-
- <biblioentry>
- <title>The Standard Librarian: What Are Allocators Good
- </title>
-
- <abbrev>
- austernm
- </abbrev>
+ </biblioentry>
+ <biblioentry>
+ <biblioid class="uri">
+ <ulink url="http://www.drdobbs.com/cpp/184403759">
+ <citetitle>
+ The Standard Librarian: What Are Allocators Good For?
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Matt</firstname>
<surname>Austern</surname>
</author>
-
<publisher>
<publishername>
- C/C++ Users Journal
+ C/C++ Users Journal
</publishername>
</publisher>
+ </biblioentry>
- <biblioid>
- <ulink url="http://www.cuj.com/documents/s=8000/cujcexp1812austern/">
+ <biblioentry>
+ <biblioid class="uri">
+ <ulink url="http://www.cs.umass.edu/~emery/hoard/">
+ <citetitle>
+ The Hoard Memory Allocator
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
-
- <biblioentry>
- <title>The Hoard Memory Allocator</title>
-
- <abbrev>
- emeryb
- </abbrev>
-
<author>
<firstname>Emery</firstname>
<surname>Berger</surname>
</author>
+ </biblioentry>
- <biblioid>
- <ulink url="http://www.cs.umass.edu/~emery/hoard/">
+ <biblioentry>
+ <biblioid class="uri">
+ <ulink url="http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf">
+ <citetitle>
+ Reconsidering Custom Memory Allocation
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
-
- <biblioentry>
- <title>Reconsidering Custom Memory Allocation</title>
-
- <abbrev>
- bergerzorn
- </abbrev>
-
<author>
<firstname>Emery</firstname>
<surname>Berger</surname>
<firstname>Kathryn</firstname>
<surname>McKinley</surname>
</author>
-
<copyright>
<year>2002</year>
<holder>OOPSLA</holder>
</copyright>
+ </biblioentry>
- <biblioid>
- <ulink url="http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf">
- </ulink>
- </biblioid>
- </biblioentry>
-
<biblioentry>
- <title>Allocator Types</title>
-
- <abbrev>
- kreftlanger
- </abbrev>
-
+ <biblioid class="uri">
+ <ulink url="http://www.angelikalanger.com/Articles/C++Report/Allocators/Allocators.html">
+ <citetitle>
+ Allocator Types
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Klaus</firstname>
<surname>Kreft</surname>
<firstname>Angelika</firstname>
<surname>Langer</surname>
</author>
-
<publisher>
<publishername>
- C/C++ Users Journal
+ C/C++ Users Journal
</publishername>
</publisher>
+ </biblioentry>
- <biblioid>
- <ulink url="http://www.angelikalanger.com/Articles/C++Report/Allocators/Allocators.html">
- </ulink>
- </biblioid>
- </biblioentry>
-
<biblioentry>
<title>The C++ Programming Language</title>
-
- <abbrev>
- tcpl
- </abbrev>
-
<author>
<firstname>Bjarne</firstname>
<surname>Stroustrup</surname>
<holder></holder>
</copyright>
<pagenums>19.4 Allocators</pagenums>
-
<publisher>
<publishername>
Addison Wesley
</publishername>
</publisher>
- </biblioentry>
-
+ </biblioentry>
+
<biblioentry>
<title>Yalloc: A Recycling C++ Allocator</title>
-
- <abbrev>
- yenf
- </abbrev>
-
<author>
<firstname>Felix</firstname>
<surname>Yen</surname>
</author>
- <copyright>
- <year></year>
- <holder></holder>
- </copyright>
-
- </biblioentry>
+ </biblioentry>
</bibliography>
</sect1>
</para>
<table frame='all'>
-<title>HTML to Doxygen markup comparison</title>
+<title>HTML to Doxygen Markup Comparison</title>
<tgroup cols='2' align='left' colsep='1' rowsep='1'>
<colspec colname='c1'></colspec>
<colspec colname='c2'></colspec>
<sect3 id="docbook.markup">
<title>Markup By Example</title>
-<para>
-Complete details on Docbook markup can be found in the DocBook Element
-Reference, <ulink url="http://www.docbook.org/tdg/en/html/part2.html">online</ulink>. An
-incomplete reference for HTML to Docbook conversion is detailed in the
-table below.
-</para>
+ <para>
+ Complete details on Docbook markup can be found in the DocBook
+ Element Reference,
+ <ulink url="http://www.docbook.org/tdg/en/html/part2.html">online</ulink>.
+ An incomplete reference for HTML to Docbook conversion is
+ detailed in the table below.
+ </para>
<table frame='all'>
-<title>HTML to Docbook XML markup comparison</title>
+<title>HTML to Docbook XML Markup Comparison</title>
<tgroup cols='2' align='left' colsep='1' rowsep='1'>
<colspec colname='c1'></colspec>
<colspec colname='c2'></colspec>
<sect1 id="manual.appendix.porting.backwards" xreflabel="backwards">
<?dbhtml filename="backwards.html"?>
-
+
<sect1info>
<keywordset>
<keyword>
<quote>obvious</quote> classes didn't get included.
</para>
-<para>Known Issues include many of the limitations of its immediate ancestor.</para>
+<para>Known Issues include many of the limitations of its immediate ancestor.</para>
<para>Portability notes and known implementation limitations are as follows.</para>
<sect2 id="backwards.second">
<title>Second</title>
-<para>
+<para>
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
releases: egcs 1.x, gcc 2.95, and gcc 2.96.
</para>
-<para>
+<para>
The STL portions of this library are based on SGI/HP STL release 3.11.
</para>
The following sections list some possible solutions to support compilers
that cannot ignore <code>std::</code>-qualified names.
</para>
-
- <para>
+
+ <para>
First, see if the compiler has a flag for this. Namespace
back-portability-issues are generally not a problem for g++
compilers that do not have libstdc++ in <code>std::</code>, as the
Second, experiment with a variety of pre-processor tricks.
</para>
- <para>
+ <para>
By defining <code>std</code> as a macro, fully-qualified namespace
calls become global. Volia.
</para>
-
+
<programlisting>
#ifdef WICKEDLY_OLD_COMPILER
# define std
ac_cv_cxx_have_std_namespace,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([#include <iostream>
- std::istream& is = std::cin;],,
+ AC_TRY_COMPILE([#include <iostream>
+ std::istream& is = std::cin;],,
ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no)
AC_LANG_RESTORE
])
use, and then correct use.
</para>
-<itemizedlist>
+<itemizedlist>
<listitem>
<para>
you cannot do <code>ostream::operator<<(iterator)</code>
<listitem>
<para>
<code>if (iterator)</code> won't work any more => use
- <code>if (iterator != iterator_type())</code>
+ <code>if (iterator != iterator_type())</code>
</para>
</listitem>
</itemizedlist>
<title><code>isspace</code> from <filename class="headerfile">cctype</filename> is a macro
</title>
- <para>
+ <para>
Glibc 2.0.x and 2.1.x define <filename
class="headerfile">ctype.h</filename> functionality as macros
(isspace, isalpha etc.).
names. For example:
</para>
-<programlisting>
-#include <cctype>
-int main() { std::isspace('X'); }
+<programlisting>
+#include <cctype>
+int main() { std::isspace('X'); }
</programlisting>
<para>
Results in something like this:
</para>
-<programlisting>
-std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;
+<programlisting>
+std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;
</programlisting>
-<para>
+<para>
A solution is to modify a header-file so that the compiler tells
<filename class="headerfile">ctype.h</filename> to define functions
instead of macros:
</para>
<programlisting>
-// This keeps isalnum, et al from being propagated as macros.
+// This keeps isalnum, et al from being propagated as macros.
#if __linux__
# define __NO_CTYPE 1
#endif
#include <vector>
#include <deque>
#include <string>
-
+
using namespace std;
],
[
<para>
Use some kind of autoconf test, plus this:
-</para>
+</para>
<programlisting>
#ifdef HAVE_CHAR_TRAITS
<code>clear</code> and <code>erase</code> (the latter returns the
string).
</para>
-
+
<programlisting>
-void
+void
clear() { _M_mutate(0, this->size(), 0); }
</programlisting>
<programlisting>
-basic_string&
+basic_string&
erase(size_type __pos = 0, size_type __n = npos)
-{
+{
return this->replace(_M_check(__pos), _M_fold(__pos, __n),
- _M_data(), _M_data());
+ _M_data(), _M_data());
}
</programlisting>
extensions
</title>
-<para>
+<para>
These are no longer supported. Please use stringstreams instead.
</para>
</sect3>
<itemizedlist>
<listitem>
- <para>
+ <para>
<code>strstream</code> is considered to be deprecated
</para>
</listitem>
<listitem>
- <para>
+ <para>
<code>strstream</code> is limited to <code>char</code>
</para>
</listitem>
<listitem>
- <para>
+ <para>
with <code>ostringstream</code> you don't have to take care of
- terminating the string or freeing its memory
+ terminating the string or freeing its memory
</para>
</listitem>
<listitem>
- <para>
+ <para>
<code>istringstream</code> can be re-filled (clear();
- str(input);)
+ str(input);)
</para>
</listitem>
</itemizedlist>
<para>
You can then use output-stringstreams like this:
</para>
-
+
<programlisting>
#ifdef HAVE_SSTREAM
# include <sstream>
<para>
Input-stringstreams can be used similarly:
</para>
-
+
<programlisting>
std::string input;
...
#endif
int i;
-iss >> i;
+iss >> i;
</programlisting>
<para> One (the only?) restriction is that an istrstream cannot be re-filled:
</para>
-
+
<programlisting>
std::istringstream iss(numerator);
iss >> m_num;
iss.str(denominator);
iss >> m_den;
</programlisting>
-
+
<para>
If you don't care about speed, you can put these conversions in
a template-function:
-</para>
+</para>
<programlisting>
template <class X>
void fromString(const string& input, X& any)
}
</programlisting>
-<para>
+<para>
Another example of using stringstreams is in <link
linkend="strings.string.shrink">this howto</link>.
</para>
</para>
<itemizedlist>
- <listitem>
+ <listitem>
<para>
Our threading expert Loren gives a breakdown of <ulink
url="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html">the
release series.
</para>
</listitem>
- <listitem>
+ <listitem>
<para>
<ulink url="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
- This message</ulink> inspired a recent updating of issues with
- threading and the SGI STL library. It also contains some
- example POSIX-multithreaded STL code.
+ This message</ulink> inspired a recent updating of issues with
+ threading and the SGI STL library. It also contains some
+ example POSIX-multithreaded STL code.
</para>
</listitem>
</itemizedlist>
- <para>
+ <para>
(A large selection of links to older messages has been removed;
many of the messages from 1999 were lost in a disk crash, and the
few people with access to the backup tapes have been too swamped
</para>
<para>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.
+ (chapters 23 through 25, mostly) is adapted from the final release
+ of the SGI STL (version 3.3), with extensive changes.
</para>
<para>A more formal description of the V3 goals can be found in the
- official <link linkend="contrib.design_notes">design document</link>.
+ official <link linkend="contrib.design_notes">design document</link>.
</para>
<para>Portability notes and known implementation limitations are as follows.</para>
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Wno-deprecated"
+ CXXFLAGS="$CXXFLAGS -Wno-deprecated"
# Omit defalloc.h, as compilation with newer compilers is problematic.
AC_TRY_COMPILE([
<title>Extension headers hash_map, hash_set moved to ext or backwards</title>
<para>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
- are suitable replacement for the non-standard hash_map and hash_set
- containers in the SGI STL.
+ replaced by standardized libraries.
+ In particular, the unordered_map and unordered_set containers of TR1
+ are suitable replacement for the non-standard hash_map and hash_set
+ containers in the SGI STL.
</para>
<para> Header files <filename class="headerfile">hash_map</filename> and <filename class="headerfile">hash_set</filename> moved
to <filename class="headerfile">ext/hash_map</filename> and <filename class="headerfile">ext/hash_set</filename>,
</para>
<para>The extensions are no longer in the global or <code>std</code>
- namespaces, instead they are declared in the <code>__gnu_cxx</code>
- namespace. For maximum portability, consider defining a namespace
- alias to use to talk about extensions, e.g.:
+ namespaces, instead they are declared in the <code>__gnu_cxx</code>
+ namespace. For maximum portability, consider defining a namespace
+ alias to use to talk about extensions, e.g.:
</para>
<programlisting>
#ifdef __GNUC__
#if __GNUC__ < 3
- #include <hash_map.h>
- namespace extension { using ::hash_map; }; // inherit globals
+ #include <hash_map.h>
+ namespace extension { using ::hash_map; }; // inherit globals
#else
- #include <backward/hash_map>
- #if __GNUC__ == 3 && __GNUC_MINOR__ == 0
- namespace extension = std; // GCC 3.0
- #else
- namespace extension = ::__gnu_cxx; // GCC 3.1 and later
- #endif
+ #include <backward/hash_map>
+ #if __GNUC__ == 3 && __GNUC_MINOR__ == 0
+ namespace extension = std; // GCC 3.0
+ #else
+ namespace extension = ::__gnu_cxx; // GCC 3.1 and later
+ #endif
#endif
#else // ... there are other compilers, right?
- namespace extension = std;
+ namespace extension = std;
#endif
- extension::hash_map<int,int> my_map;
+ extension::hash_map<int,int> my_map;
</programlisting>
<para>This is a bit cleaner than defining typedefs for all the
- instantiations you might need.
+ instantiations you might need.
</para>
-
+
<para>The following autoconf tests check for working HP/SGI hash containers.
</para>
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Werror"
+ CXXFLAGS="$CXXFLAGS -Werror"
AC_TRY_COMPILE([#include <ext/hash_map>], [using __gnu_cxx::hash_map;],
ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no)
CXXFLAGS="$ac_save_CXXFLAGS"
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Werror"
+ CXXFLAGS="$CXXFLAGS -Werror"
AC_TRY_COMPILE([#include <ext/hash_set>], [using __gnu_cxx::hash_set;],
ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no)
CXXFLAGS="$ac_save_CXXFLAGS"
Phil Edwards writes: It was considered and rejected for the ISO
standard. Not all environments use file descriptors. Of those
that do, not all of them use integers to represent them.
- </para>
+ </para>
<para>
For a portable solution (among systems which use
<code>std::streambuf</code> (or
<code>std::basic_streambuf<..></code>) which opens a file
given a descriptor, and then pass an instance of this to the
- stream-constructor.
+ stream-constructor.
</para>
<para>
<para>
For another example of this, refer to
- <ulink url="http://www.josuttis.com/cppcode/fdstream.html">fdstream example</ulink>
+ <ulink url="http://www.josuttis.com/cppcode/fdstream.html">fdstream example</ulink>
by Nicolai Josuttis.
</para>
</sect3>
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
template <typename T>
- struct check
+ struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=c++0x"
+ CXXFLAGS="$CXXFLAGS -std=c++0x"
AC_TRY_COMPILE([
template <typename T>
- struct check
+ struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
template <typename T>
- struct check
+ struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
AC_LANG_RESTORE
])
- if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
- test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
+ if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
+ test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
fi
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
#include <cassert>
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([#include <unordered_map>], [using std::unordered_map;],
ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([#include <unordered_set>], [using std::unordered_set;],
ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no)
CXXFLAGS="$ac_save_CXXFLAGS"
<title>Bibliography</title>
<biblioentry>
- <abbrev>
- kegel41
- </abbrev>
-
- <title>
- Migrating to GCC 4.1
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://www.kegel.com/gcc/gcc4.html">
+ <citetitle>
+ Migrating to GCC 4.1
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Dan</firstname>
<surname>Kegel</surname>
</author>
+ </biblioentry>
- <biblioid>
- <ulink url="http://www.kegel.com/gcc/gcc4.html">
+ <biblioentry>
+ <biblioid class="uri">
+ <ulink url="http://lists.debian.org/debian-gcc/2006/03/msg00405.html">
+ <citetitle>
+ Building the Whole Debian Archive with GCC 4.1: A Summary
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
-
-
- <biblioentry>
- <abbrev>
- kegel41
- </abbrev>
-
- <title>
- Building the Whole Debian Archive with GCC 4.1: A Summary
- </title>
-
<author>
<firstname>Martin</firstname>
<surname>Michlmayr</surname>
</author>
-
- <biblioid>
- <ulink url="http://lists.debian.org/debian-gcc/2006/03/msg00405.html">
- </ulink>
- </biblioid>
- </biblioentry>
-
+ </biblioentry>
<biblioentry>
- <abbrev>
- lbl32
- </abbrev>
-
- <title>
- Migration guide for GCC-3.2
- </title>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html">
+ <citetitle>
+ Migration guide for GCC-3.2
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
</bibliography>
<sect1 id="manual.localization.facet.codecvt" xreflabel="codecvt">
<?dbhtml filename="codecvt.html"?>
-
+
<sect1info>
<keywordset>
<keyword>
-1- The class codecvt<internT,externT,stateT> is for use when
converting from one codeset to another, such as from wide characters
to multibyte characters, between wide character encodings such as
-Unicode and EUC.
+Unicode and EUC.
</emphasis>
</para>
</blockquote>
-<para>
+<para>
Hmm. So, in some unspecified way, Unicode encodings and
translations between other character sets should be handled by this
-class.
+class.
</para>
<blockquote>
<para>
<emphasis>
--2- The stateT argument selects the pair of codesets being mapped between.
+-2- The stateT argument selects the pair of codesets being mapped between.
</emphasis>
</para>
</blockquote>
</para>
<para>
-Three problems arise, one big, one of medium importance, and one small.
+Three problems arise, one big, one of medium importance, and one small.
</para>
<para>
</para>
<para>
-<code>
+<code>
encoding_state() : __in_desc(0), __out_desc(0)
</code>
</para>
</para>
<para>
-<code>
+<code>
encoding_state(const char* __int, const char* __ext)
</code>
</para>
encodings. It is up to the user to make sure that these strings are
valid on the target system.
</para>
-
+
<para>
-<code>
+<code>
void
_M_init()
</code>
</para>
<para>
-<code>
+<code>
bool
_M_good()
</code>
</para>
<para>
-<code>
+<code>
encoding_state(const encoding_state&)
</code>
</para>
const ext_type* e_lit = "black pearl jasmine tea";
int size = strlen(e_lit);
- int_type i_lit_base[24] =
- { 25088, 27648, 24832, 25344, 27392, 8192, 28672, 25856, 24832, 29184,
+ int_type i_lit_base[24] =
+ { 25088, 27648, 24832, 25344, 27392, 8192, 28672, 25856, 24832, 29184,
27648, 8192, 27136, 24832, 29440, 27904, 26880, 28160, 25856, 8192, 29696,
25856, 24832, 2560
};
locale loc(locale::classic(), new unicode_codecvt);
// sanity check the constructed locale has the specialized facet.
VERIFY( has_facet<unicode_codecvt>(loc) );
- const unicode_codecvt& cvt = use_facet<unicode_codecvt>(loc);
+ const unicode_codecvt& cvt = use_facet<unicode_codecvt>(loc);
// convert between const char* and unicode strings
unicode_codecvt::state_type state01("UNICODE", "ISO_8859-1");
initialize_state(state01);
- result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next,
- i_arr, i_arr + size, ito_next);
+ result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next,
+ i_arr, i_arr + size, ito_next);
VERIFY( r1 == codecvt_base::ok );
- VERIFY( !int_traits::compare(i_arr, i_lit, size) );
+ VERIFY( !int_traits::compare(i_arr, i_lit, size) );
VERIFY( efrom_next == e_lit + size );
VERIFY( ito_next == i_arr + size );
</programlisting>
what is equal? A byte by byte comparison or an
encoding then byte comparison?
</para></listitem>
-
+
<listitem><para>
conversions between narrow, wide, and unicode strings
</para></listitem>
standards-conformant manner?
</para></listitem>
- <listitem><para>
+ <listitem><para>
how to synchronize the "C" and "C++"
conversion information?
</para></listitem>
- <listitem><para>
+ <listitem><para>
wchar_t/char internal buffers and conversions between
internal/external buffers?
</para></listitem>
<title>
The GNU C Library
</title>
-
<author>
<surname>McGrath</surname>
<firstname>Roland</firstname>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2007</year>
<holder>FSF</holder>
</copyright>
- <pagenums>Chapters 6 Character Set Handling and 7 Locales and Internationalization</pagenums>
-
- </biblioentry>
+ <pagenums>
+ Chapters 6 Character Set Handling and 7 Locales and Internationalization
+ </pagenums>
+ </biblioentry>
<biblioentry>
<title>
Correspondence
</title>
-
<author>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2002</year>
<holder></holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 14882:1998 Programming languages - C++
</title>
-
<copyright>
<year>1998</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 9899:1999 Programming languages - C
</title>
-
<copyright>
<year>1999</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://www.opengroup.org/austin">
+ <citetitle>
+ System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008)
+ </citetitle>
+ </ulink>
+ </biblioid>
<copyright>
- <year>1999</year>
+ <year>2008</year>
<holder>
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.</holder>
+ The Open Group/The Institute of Electrical and Electronics
+ Engineers, Inc.
+ </holder>
</copyright>
-
- <biblioid>
- <ulink url="http://www.unix.org/version3/ieee_std.html">
- </ulink>
- </biblioid>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
The C++ Programming Language, Special Edition
</title>
-
<author>
<surname>Stroustrup</surname>
<firstname>Bjarne</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley, Inc.</holder>
</copyright>
<pagenums>Appendix D</pagenums>
-
<publisher>
<publishername>
Addison Wesley
</publishername>
</publisher>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<subtitle>
Advanced Programmer's Guide and Reference
</subtitle>
-
<author>
<surname>Langer</surname>
<firstname>Angelika</firstname>
</author>
-
<author>
<surname>Kreft</surname>
<firstname>Klaus</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley Longman, Inc.</holder>
</copyright>
-
<publisher>
<publishername>
Addison Wesley Longman
</publishername>
</publisher>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- A brief description of Normative Addendum 1
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://www.lysator.liu.se/c/na1.html">
+ <citetitle>
+ A brief description of Normative Addendum 1
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<surname>Feather</surname>
<firstname>Clive</firstname>
</author>
-
<pagenums>Extended Character Sets</pagenums>
- <biblioid>
- <ulink url="http://www.lysator.liu.se/c/na1.html">
- </ulink>
- </biblioid>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- The Unicode HOWTO
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://tldp.org/HOWTO/Unicode-HOWTO.html">
+ <citetitle>
+ The Unicode HOWTO
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<surname>Haible</surname>
<firstname>Bruno</firstname>
</author>
+ </biblioentry>
- <biblioid>
- <ulink url="http://tldp.org/HOWTO/Unicode-HOWTO.html">
+ <biblioentry>
+ <biblioid class="uri">
+ <ulink url="http://www.cl.cam.ac.uk/~mgk25/unicode.html">
+ <citetitle>
+ UTF-8 and Unicode FAQ for Unix/Linux
+ </citetitle>
</ulink>
</biblioid>
-
- </biblioentry>
-
- <biblioentry>
- <title>
- UTF-8 and Unicode FAQ for Unix/Linux
- </title>
-
<author>
<surname>Khun</surname>
<firstname>Markus</firstname>
</author>
-
- <biblioid>
- <ulink url="http://www.cl.cam.ac.uk/~mgk25/unicode.html">
- </ulink>
- </biblioid>
-
- </biblioentry>
-
+ </biblioentry>
</bibliography>
<sect1 id="manual.localization.facet.ctype" xreflabel="ctype">
<?dbhtml filename="ctype.html"?>
-
+
<sect1info>
<keywordset>
<keyword>
<itemizedlist>
<listitem>
<para>
- How to deal with the global locale issue?
+ How to deal with the global locale issue?
</para></listitem>
<listitem>
- <para>
+ <para>
How to deal with different types than char, wchar_t? </para></listitem>
<listitem><para>
- Overlap between codecvt/ctype: narrow/widen
+ Overlap between codecvt/ctype: narrow/widen
</para></listitem>
<listitem>
- <para>
+ <para>
Mask typedef in codecvt_base, argument types in codecvt. what
- is know about this type?
+ is know about this type?
</para></listitem>
<listitem>
- <para>
+ <para>
Why mask* argument in codecvt?
</para></listitem>
-
+
<listitem>
<para>
Can this be made (more) generic? is there a simple way to
straighten out the configure-time mess that is a by-product of
- this class?
+ this class?
</para></listitem>
<listitem>
- <para>
+ <para>
Get the ctype<wchar_t>::mask stuff under control. Need to
make some kind of static table, and not do lookup every time
somebody hits the do_is... functions. Too bad we can't just
- redefine mask for ctype<wchar_t>
+ redefine mask for ctype<wchar_t>
</para></listitem>
-
+
<listitem>
- <para>
+ <para>
Rename abstract base class. See if just smash-overriding is a
better approach. Clarify, add sanity to naming.
</para>
<title>
The GNU C Library
</title>
-
<author>
<surname>McGrath</surname>
<firstname>Roland</firstname>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2007</year>
<holder>FSF</holder>
</copyright>
<pagenums>Chapters 6 Character Set Handling and 7 Locales and Internationalization</pagenums>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
Correspondence
</title>
-
<author>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2002</year>
<holder></holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 14882:1998 Programming languages - C++
</title>
-
<copyright>
<year>1998</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 9899:1999 Programming languages - C
</title>
-
<copyright>
<year>1999</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://www.unix.org/version3/ieee_std.html">
+ <citetitle>
+ The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
+ </citetitle>
+ </ulink>
+ </biblioid>
<copyright>
<year>1999</year>
<holder>
The Open Group/The Institute of Electrical and Electronics Engineers, Inc.</holder>
</copyright>
-
- <biblioid>
- <ulink url="http://www.unix.org/version3/ieee_std.html">
- </ulink>
- </biblioid>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
The C++ Programming Language, Special Edition
</title>
-
<author>
<surname>Stroustrup</surname>
<firstname>Bjarne</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley, Inc.</holder>
</copyright>
<pagenums>Appendix D</pagenums>
-
<publisher>
<publishername>
Addison Wesley
</publishername>
</publisher>
-
- </biblioentry>
-
+ </biblioentry>
<biblioentry>
<title>
<subtitle>
Advanced Programmer's Guide and Reference
</subtitle>
-
<author>
<surname>Langer</surname>
<firstname>Angelika</firstname>
</author>
-
<author>
<surname>Kreft</surname>
<firstname>Klaus</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley Longman, Inc.</holder>
</copyright>
-
<publisher>
<publishername>
Addison Wesley Longman
</publishername>
</publisher>
-
- </biblioentry>
+ </biblioentry>
</bibliography>
<sect1 id="manual.localization.locales.locale" xreflabel="Locale">
-
+
<sect1info>
<keywordset>
<keyword>
<itemizedlist>
<listitem>
- <para>
- <code>`locale -a`</code> displays available locales.
+ <para>
+ <code>`locale -a`</code> displays available locales.
</para>
<blockquote>
<programlisting>
</programlisting>
</blockquote>
</listitem>
-
+
<listitem>
- <para>
+ <para>
<code>`locale`</code> displays environmental variables that
impact how locale("") will be deduced.
</para>
<para>
Locale initialization: at what point does _S_classic, _S_global
get initialized? Can named locales assume this initialization
- has already taken place?
+ has already taken place?
</para>
</listitem>
<listitem>
- <para>
+ <para>
Document how named locales error check when filling data
members. I.e., a fr_FR locale that doesn't have
numpunct::truename(): does it use "true"? Or is it a blank
- string? What's the convention?
+ string? What's the convention?
</para>
</listitem>
<listitem>
- <para>
+ <para>
Explain how locale aliasing happens. When does "de_DE" use "de"
information? What is the rule for locales composed of just an
ISO language code (say, "de") and locales with both an ISO
- language code and ISO country code (say, "de_DE").
+ language code and ISO country code (say, "de_DE").
</para>
</listitem>
<listitem>
- <para>
+ <para>
What should non-required facet instantiations do? If the
generic implementation is provided, then how to end-users
- provide specializations?
+ provide specializations?
</para>
</listitem>
</itemizedlist>
<title>
The GNU C Library
</title>
-
<author>
<surname>McGrath</surname>
<firstname>Roland</firstname>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2007</year>
<holder>FSF</holder>
</copyright>
- <pagenums>Chapters 6 Character Set Handling and 7 Locales and Internationalization</pagenums>
-
- </biblioentry>
+ <pagenums>
+ Chapters 6 Character Set Handling and 7 Locales and
+ Internationalization
+ </pagenums>
+ </biblioentry>
<biblioentry>
<title>
Correspondence
</title>
-
<author>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2002</year>
<holder></holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 14882:1998 Programming languages - C++
</title>
-
<copyright>
<year>1998</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 9899:1999 Programming languages - C
</title>
-
<copyright>
<year>1999</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://www.opengroup.org/austin">
+ <citetitle>
+ System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008)
+ </citetitle>
+ </ulink>
+ </biblioid>
<copyright>
- <year>1999</year>
+ <year>2008</year>
<holder>
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.</holder>
+ The Open Group/The Institute of Electrical and Electronics
+ Engineers, Inc.
+ </holder>
</copyright>
-
- <biblioid>
- <ulink url="http://www.unix.org/version3/ieee_std.html">
- </ulink>
- </biblioid>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
The C++ Programming Language, Special Edition
</title>
-
<author>
<surname>Stroustrup</surname>
<firstname>Bjarne</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley, Inc.</holder>
</copyright>
<pagenums>Appendix D</pagenums>
-
<publisher>
<publishername>
Addison Wesley
</publishername>
</publisher>
-
- </biblioentry>
-
+ </biblioentry>
<biblioentry>
<title>
<subtitle>
Advanced Programmer's Guide and Reference
</subtitle>
-
<author>
<surname>Langer</surname>
<firstname>Angelika</firstname>
</author>
-
<author>
<surname>Kreft</surname>
<firstname>Klaus</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley Longman, Inc.</holder>
</copyright>
-
<publisher>
<publishername>
Addison Wesley Longman
</publishername>
</publisher>
-
- </biblioentry>
+ </biblioentry>
</bibliography>
<sect1 id="manual.localization.facet.messages" xreflabel="Messages">
<?dbhtml filename="messages.html"?>
-
+
<sect1info>
<keywordset>
<keyword>
<para>
This class has three public member functions, which directly
-correspond to three protected virtual member functions.
+correspond to three protected virtual member functions.
</para>
<para>
<blockquote>
<para>
<emphasis>
--3- Requires: A catalog cat obtained from open() and not yet closed.
+-3- Requires: A catalog cat obtained from open() and not yet closed.
-4- Returns: A message identified by arguments set, msgid, and dfault,
according to an implementation-defined mapping. If no such message can
be found, returns dfault.
<blockquote>
<para>
<emphasis>
--5- Requires: A catalog cat obtained from open() and not yet closed.
--6- Effects: Releases unspecified resources associated with cat.
--7- Notes: The limit on such resources, if any, is implementation-defined.
+-5- Requires: A catalog cat obtained from open() and not yet closed.
+-6- Effects: Releases unspecified resources associated with cat.
+-7- Notes: The limit on such resources, if any, is implementation-defined.
</emphasis>
</para>
</blockquote>
<title>Design</title>
<para>
-A couple of notes on the standard.
+A couple of notes on the standard.
</para>
<para>
First, why is <code>messages_base::catalog</code> specified as a typedef
to int? This makes sense for implementations that use
<code>catopen</code>, but not for others. Fortunately, it's not heavily
-used and so only a minor irritant.
+used and so only a minor irritant.
</para>
<para>
Lastly, it seems odd that messages, which explicitly require code
conversion, don't use the codecvt facet. Because the messages facet
has only one template parameter, it is assumed that ctype, and not
-codecvt, is to be used to convert between character sets.
+codecvt, is to be used to convert between character sets.
</para>
<para>
generic
</para>
<para>
- This model does very little, and is what is used by default.
+ This model does very little, and is what is used by default.
</para>
</listitem>
<listitem>
- <para>
+ <para>
gnu
</para>
<para>
</listitem>
<listitem>
- <para>
+ <para>
ieee_1003.1-200x
</para>
<para>
</listitem>
<listitem>
- <para>
+ <para>
Make initial catalog (see "4 Making the PO Template File" from
the gettext docs).</para>
<para>
<code> xgettext --c++ --debug string_literals.cc -o libstdc++.pot </code>
</para>
</listitem>
-
+
<listitem>
<para>Make language and country-specific locale catalogs.</para>
<para>
<code>emacs fr_FR.po</code>
</para>
</listitem>
-
+
<listitem>
<para>Make the binary mo files.</para>
<para>
{
typedef messages<char>::catalog catalog;
const char* dir =
- "/mnt/egcs/build/i686-pc-linux-gnu/libstdc++/po/share/locale";
+ "/mnt/egcs/build/i686-pc-linux-gnu/libstdc++/po/share/locale";
const locale loc_de("de_DE");
- const messages<char>& mssg_de = use_facet<messages<char> >(loc_de);
+ const messages<char>& mssg_de = use_facet<messages<char> >(loc_de);
catalog cat_de = mssg_de.open("libstdc++", loc_de, dir);
string s01 = mssg_de.get(cat_de, 0, 0, "please");
</listitem>
<listitem>
- <para>
+ <para>
There are issues with gettext needing the global locale set
to extract a message. This dependence on the global locale
makes the current "gnu" model non MT-safe. Future versions
</listitem>
<listitem>
- <para>
+ <para>
Development versions of the GNU "C" library, glibc 2.3 will allow
a more efficient, MT implementation of std::messages, and will
allow the removal of the _M_name_messages data member. If this is
<para>
<code>
- catalog
- open(const basic_string<char>& __s, const locale& __loc) const
+ catalog
+ open(const basic_string<char>& __s, const locale& __loc) const
</code>
</para>
<para>
<code>
- catalog
+ catalog
open(const basic_string<char>&, const locale&, const char*) const;
</code>
</para>
<title>
The GNU C Library
</title>
-
<author>
<surname>McGrath</surname>
<firstname>Roland</firstname>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2007</year>
<holder>FSF</holder>
</copyright>
<pagenums>Chapters 6 Character Set Handling, and 7 Locales and Internationalization
</pagenums>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
Correspondence
</title>
-
<author>
<surname>Drepper</surname>
<firstname>Ulrich</firstname>
</author>
-
<copyright>
<year>2002</year>
<holder></holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
ISO/IEC 14882:1998 Programming languages - C++
</title>
-
<copyright>
<year>1998</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
<year>1999</year>
<holder>ISO</holder>
</copyright>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
- </title>
-
+ <biblioid class="uri">
+ <ulink url="http://www.opengroup.org/austin">
+ <citetitle>
+ System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008)
+ </citetitle>
+ </ulink>
+ </biblioid>
<copyright>
- <year>1999</year>
+ <year>2008</year>
<holder>
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.</holder>
+ The Open Group/The Institute of Electrical and Electronics
+ Engineers, Inc.
+ </holder>
</copyright>
-
- <biblioid>
- <ulink url="http://www.opengroup.org/austin/">
- </ulink>
- </biblioid>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
The C++ Programming Language, Special Edition
</title>
-
<author>
<surname>Stroustrup</surname>
<firstname>Bjarne</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley, Inc.</holder>
</copyright>
<pagenums>Appendix D</pagenums>
-
<publisher>
<publishername>
Addison Wesley
</publishername>
</publisher>
-
- </biblioentry>
-
+ </biblioentry>
<biblioentry>
<title>
<subtitle>
Advanced Programmer's Guide and Reference
</subtitle>
-
<author>
<surname>Langer</surname>
<firstname>Angelika</firstname>
</author>
-
<author>
<surname>Kreft</surname>
<firstname>Klaus</firstname>
</author>
-
<copyright>
<year>2000</year>
<holder>Addison Wesley Longman, Inc.</holder>
</copyright>
-
<publisher>
<publishername>
Addison Wesley Longman
</publishername>
</publisher>
-
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Java 2 Platform, Standard Edition, v 1.3.1 API Specification
- </title>
- <pagenums>java.util.Properties, java.text.MessageFormat,
-java.util.Locale, java.util.ResourceBundle</pagenums>
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://java.sun.com/reference/api/index.html">
+ <citetitle>
+ API Specifications, Java Platform
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ <pagenums>java.util.Properties, java.text.MessageFormat,
+java.util.Locale, java.util.ResourceBundle
+ </pagenums>
+ </biblioentry>
<biblioentry>
- <title>
- GNU gettext tools, version 0.10.38, Native Language Support
-Library and Tools.
- </title>
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://www.gnu.org/software/gettext/">
+ <citetitle>
+ GNU gettext tools, version 0.10.38, Native Language Support
+Library and Tools.
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
</bibliography>
<para>
</para>
<table frame='all'>
-<title>Code Location</title>
+<title>Profile Code Location</title>
<tgroup cols='2' align='left' colsep='1' rowsep='1'>
<colspec colname='c1'></colspec>
<colspec colname='c2'></colspec>
</para>
<table frame='all'>
-<title>Diagnostics</title>
+<title>Profile Diagnostics</title>
<tgroup cols='6' align='left' colsep='1' rowsep='1'>
<colspec colname='c1'></colspec>
<colspec colname='c2'></colspec>
<title>Bibliography</title>
<biblioentry>
- <abbrev>
- n2351
- </abbrev>
-
- <title>
- Improving shared_ptr for C++0x, Revision 2
- </title>
- <subtitle>
- N2351
- </subtitle>
-
- <biblioid>
+ <biblioid class="uri">
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">
+ <citetitle>
+ Improving shared_ptr for C++0x, Revision 2
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
-
-
- <biblioentry>
- <abbrev>
- n2456
- </abbrev>
-
- <title>
- C++ Standard Library Active Issues List (Revision R52)
- </title>
<subtitle>
- N2456
+ N2351
</subtitle>
+ </biblioentry>
- <biblioid>
+ <biblioentry>
+ <biblioid class="uri">
<ulink url="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html">
+ <citetitle>
+ C++ Standard Library Active Issues List
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
-
-
- <biblioentry>
- <abbrev>
- n2461
- </abbrev>
-
- <title>
- Working Draft, Standard for Programming Language C++
- </title>
<subtitle>
- N2461
+ N2456
</subtitle>
+ </biblioentry>
- <biblioid>
+ <biblioentry>
+ <biblioid class="uri">
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">
+ <citetitle>
+ Working Draft, Standard for Programming Language C++
+ </citetitle>
</ulink>
</biblioid>
- </biblioentry>
-
-
- <biblioentry>
- <abbrev>
- boostshared_ptr
- </abbrev>
-
- <title>
- Boost C++ Libraries documentation - shared_ptr class template
- </title>
<subtitle>
N2461
</subtitle>
+ </biblioentry>
- <biblioid>
+ <biblioentry>
+ <biblioid class="uri">
<ulink url="http://boost.org/libs/smart_ptr/shared_ptr.htm">shared_ptr
+ <citetitle>
+ Boost C++ Libraries documentation, shared_ptr
+ </citetitle>
</ulink>
</biblioid>
+ <subtitle>
+ N2461
+ </subtitle>
</biblioentry>
</bibliography>
These are very powerful constructs, and require some thought when
applied to the standard library in order to yield components that work
efficiently while cleaning up resources when unexpectedly killed via
-exceptional circumstances.
+exceptional circumstances.
</para>
<para>
<sect2 id="intro.using.exception.safety" xreflabel="Exception Safety">
<title>Exception Safety</title>
- <para>
- What is exception-safe code?
+ <para>
+ What is exception-safe code?
</para>
<para>
use <literal>-fno-exceptions</literal>. If you have some code that
uses <literal>try</literal> or <literal>catch</literal>, you
shouldn't use <literal>-fno-exceptions</literal>.
- </para>
+ </para>
- <para>
+ <para>
And what it to be gained, tinkering in the back alleys with a
language like this? Exception handling overhead can be measured
in the size of the executable binary, and varies with the
library has been transformed, user code may need modification. User
code that attempts or expects to do error checking on standard
library components compiled with exception handling disabled should
- be evaluated and potentially made conditional.
+ be evaluated and potentially made conditional.
</para>
<para>
<sect3 id="using.exception.compat.c">
<title>With <literal>C</literal></title>
-<para>
+<para>
C language code that is expecting to interoperate with C++ should be
compiled with <literal>-fexceptions</literal>. This will make
debugging a C language function called as part of C++-induced stack
<sect3 id="using.exception.compat.posix">
<title>With <literal>POSIX</literal> thread cancellation</title>
-<para>
+<para>
GNU systems re-use some of the exception handling mechanisms to
track control flow for <literal>POSIX</literal> thread cancellation.
</para>
<title>Bibliography</title>
<biblioentry>
- <title>
- System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008)
- </title>
+ <biblioid class="uri">
+ <ulink url="http://www.opengroup.org/austin">
+ <citetitle>
+ System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008)
+ </citetitle>
+ </ulink>
+ </biblioid>
<pagenums>
2.9.5 Thread Cancellation
</pagenums>
-
<copyright>
<year>2008</year>
<holder>
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.</holder>
+ The Open Group/The Institute of Electrical and Electronics
+ Engineers, Inc.
+ </holder>
</copyright>
+ </biblioentry>
- <biblioid>
- <ulink url="http://www.opengroup.org/austin/">
+ <biblioentry>
+ <biblioid class="uri">
+ <ulink url="http://www.boost.org/community/error_handling.html">
+ <citetitle>
+ Error and Exception Handling
+ </citetitle>
</ulink>
</biblioid>
-
- </biblioentry>
-
- <biblioentry>
- <title>
- Error and Exception Handling
- </title>
<author>
<firstname>David</firstname>
<surname>Abrahams </surname>
Boost
</publishername>
</publisher>
- <biblioid>
- <ulink url="http://www.boost.org/community/error_handling.html">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Exception-Safety in Generic Components
- </title>
+ <biblioid class="uri">
+ <ulink url="http://www.boost.org/community/exception_safety.html">
+ <citetitle>
+ Exception-Safety in Generic Components
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>David</firstname>
<surname>Abrahams</surname>
Boost
</publishername>
</publisher>
- <biblioid>
- <ulink url="http://www.boost.org/community/exception_safety.html">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Standard Library Exception Policy
- </title>
+ <biblioid class="uri">
+ <ulink url="www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1077.pdf">
+ <citetitle>
+ Standard Library Exception Policy
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Matt</firstname>
<surname>Austern</surname>
WG21 N1077
</publishername>
</publisher>
- <biblioid>
- <ulink url="www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1077.pdf">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- ia64 c++ abi exception handling
- </title>
+ <biblioid class="uri">
+ <ulink url="http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00661.html">
+ <citetitle>
+ ia64 c++ abi exception handling
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Richard</firstname>
<surname>Henderson</surname>
GNU
</publishername>
</publisher>
- <biblioid>
- <ulink url="http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00661.html">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- Appendix E: Standard-Library Exception Safety
- </title>
+ <biblioid class="uri">
+ <ulink url="http://www.research.att.com/~bs/3rd_safe.pdf">
+ <citetitle>
+ Appendix E: Standard-Library Exception Safety
+ </citetitle>
+ </ulink>
+ </biblioid>
<author>
<firstname>Bjarne</firstname>
<surname>Stroustrup</surname>
</author>
- <biblioid>
- <ulink url="http://www.research.att.com/~bs/3rd_safe.pdf">
- </ulink>
- </biblioid>
- </biblioentry>
+ </biblioentry>
<biblioentry>
<title>
<firstname>Herb</firstname>
<surname>Sutter</surname>
</author>
- </biblioentry>
+ </biblioentry>
<biblioentry>
- <title>
- exception_defines.h #defines try/catch
- </title>
- <subtitle>
- GCC Bug <ulink url="http://gcc.gnu.org/PR25191">25191</ulink>
- </subtitle>
- <biblioid>
+ <biblioid class="uri">
+ <ulink url="http://gcc.gnu.org/PR25191">
+ <citetitle>
+ GCC Bug 25191: exception_defines.h #defines try/catch
+ </citetitle>
+ </ulink>
</biblioid>
- </biblioentry>
+ </biblioentry>
</bibliography>