<?xml version='1.0'?>
-<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
- "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
+<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
[ ]>
<appendix id="appendix.contrib" xreflabel="Contributing">
</keywordset>
</appendixinfo>
-<title>Contributing</title>
+<title>
+ Contributing
+ <indexterm>
+ <primary>Appendix</primary>
+ <secondary>Contributing</secondary>
+ </indexterm>
+</title>
-<para>
+<para>
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
<sect1 id="contrib.list" xreflabel="Contributor Checklist">
<title>Contributor Checklist</title>
- <sect2 id="list.reading" xreflabel="list.reading">
+ <sect2 id="list.reading">
<title>Reading</title>
<itemizedlist>
<listitem>
- <para>
+ <para>
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
the standard from their respective national standards
organization. In the USA, this national standards
organization is ANSI and their web-site is right
- <ulink url="http://www.ansi.org">here.</ulink>
- (And if you've already registered with them, clicking this link will take you to directly to the place where you can
- <ulink url="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003">buy the standard on-line.)</ulink>
+ <ulink url="http://www.ansi.org">here.</ulink>
+ (And if you've already registered with them, clicking this link will take you to directly to the place where you can
+ <ulink url="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003">buy the standard on-line.)</ulink>
</para>
</listitem>
<listitem>
- <para>
+ <para>
The library working group bugs, and known defects, can
be obtained here:
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21 </ulink>
</listitem>
<listitem>
- <para>
+ <para>
The newsgroup dedicated to standardization issues is
comp.std.c++: this FAQ for this group is quite useful and
can be
- found <ulink url="http://www.jamesd.demon.co.uk/csc/faq.html">
+ found <ulink url="http://www.comeaucomputing.com/csc/faq.html">
here </ulink>.
</para>
</listitem>
<listitem>
- <para>
+ <para>
Peruse
- the <ulink url="http://www.gnu.org/prep/standards_toc.html">GNU
+ the <ulink url="http://www.gnu.org/prep/standards">GNU
Coding Standards</ulink>, and chuckle when you hit the part
about <quote>Using Languages Other Than C</quote>.
</para>
</listitem>
<listitem>
- <para>
+ <para>
Be familiar with the extensions that preceded these
general GNU rules. These style issues for libstdc++ can be
found <link linkend="contrib.coding_style">here</link>.
</listitem>
<listitem>
- <para>
+ <para>
And last but certainly not least, read the
library-specific information
found <link linkend="appendix.porting"> here</link>.
</itemizedlist>
</sect2>
- <sect2 id="list.copyright" xreflabel="list.copyright">
+ <sect2 id="list.copyright">
<title>Assignment</title>
<para>
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
- to fill out appropriate disclaimer forms as well.
+ to fill out appropriate disclaimer forms as well.
</para>
- <para>
+ <para>
Historically, the libstdc++ assignment form added the following
question:
</para>
</para>
<para>
- For more information about getting a copyright assignment, please see
+ For more information about getting a copyright assignment, please see
<ulink url="http://www.gnu.org/prep/maintain/html_node/Legal-Matters.html">Legal
Matters</ulink>.
</para>
</para>
</sect2>
- <sect2 id="list.getting" xreflabel="list.getting">
+ <sect2 id="list.getting">
<title>Getting Sources</title>
<para>
<ulink url="http://gcc.gnu.org/svnwrite.html">Getting write access
</para>
</sect2>
- <sect2 id="list.patches" xreflabel="list.patches">
+ <sect2 id="list.patches">
<title>Submitting Patches</title>
<para>
<itemizedlist>
<listitem>
- <para>
+ <para>
A description of the bug and how your patch fixes this
bug. For new features a description of the feature and your
- implementation.
+ implementation.
</para>
</listitem>
<listitem>
- <para>
+ <para>
A ChangeLog entry as plain text; see the various
- ChangeLog files for format and content. If using you are
+ ChangeLog files for format and content. If you are
using emacs as your editor, simply position the insertion
point at the beginning of your change and hit CX-4a to bring
up the appropriate ChangeLog entry. See--magic! Similar
- functionality also exists for vi.
+ functionality also exists for vi.
</para>
</listitem>
<listitem>
- <para>
+ <para>
A testsuite submission or sample program that will
easily and simply show the existing error or test new
- functionality.
+ functionality.
</para>
</listitem>
<listitem>
- <para>
+ <para>
The patch itself. If you are accessing the SVN
repository use <command>svn update; svn diff NEW</command>;
else, use <command>diff -cp OLD NEW</command> ... If your
</listitem>
<listitem>
- <para>
+ <para>
When you have all these pieces, bundle them up in a
mail message and send it to libstdc++@gcc.gnu.org. All
patches and related discussion should be sent to the
- libstdc++ mailing list.
+ libstdc++ mailing list.
</para>
- </listitem>
+ </listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="contrib.organization" xreflabel="Source Organization">
+ <?dbhtml filename="source_organization.html"?>
<title>Directory Layout and Source Conventions</title>
-
+
<para>
The unpacked source directory of libstdc++ contains the files
needed to create the GNU C++ Library.
include/std
Files meant to be found by #include <name> directives in
- standard-conforming user programs.
+ standard-conforming user programs.
include/c
- Headers intended to directly include standard C headers.
+ Headers intended to directly include standard C headers.
[NB: this can be enabled via --enable-cheaders=c]
- include/c_global
+ 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
+ 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.
+ the bits directory.
include/backward
Headers provided for backward compatibility, such as <iostream.h>.
installed.
testsuites/[backward, demangle, ext, performance, thread, 17_* to 27_*]
- Test programs are here, and may be used to begin to exercise the
+ 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
</sect1>
<sect1 id="contrib.coding_style" xreflabel="Coding Style">
+ <?dbhtml filename="source_code_style.html"?>
<title>Coding Style</title>
<para>
</para>
- <sect2 id="coding_style.bad_identifiers" xreflabel="coding_style.bad">
+ <sect2 id="coding_style.bad_identifiers">
<title>Bad Identifiers</title>
<para>
Identifiers that conflict and should be avoided.
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
+ gcc/cplus-dem.c) that are either old or new, but are definitely
recognized by the demangler, is:
__aa
</literallayout>
</sect2>
- <sect2 id="coding_style.example" xreflabel="coding_style.example">
+ <sect2 id="coding_style.example">
<title>By Example</title>
<literallayout>
This library is written to appropriate C++ coding standards. As such,
-NOT-
char *p = "flop"; // wrong
char &c = *p; // wrong
-
- Reason: In C++, definitions are mixed with executable code. Here,
+
+ 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.
operator==(type)
-NOT-
operator == (type) // wrong
-
+
Reason: The == is part of the function name. Separating
- it makes the declaration look like an expression.
+ it makes the declaration look like an expression.
03. Function names and parentheses
void mangle()
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
+ 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
+ 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
+ rather than "class".) T often could be int, which is
not a class. ("class", here, is an anachronism.)
05. Template class indentation
07. Member initialization lists
All one line, separate from class name.
- gribble::gribble()
+ gribble::gribble()
: _M_private_data(0), _M_more_stuff(0), _M_helper(0);
{ }
-NOT-
{ }
08. Try/Catch blocks
- try
+ try
{
//
- }
+ }
catch (...)
{
//
- }
+ }
-NOT-
try {
- //
- } catch(...) {
+ //
+ } catch(...) {
//
}
Keywords such as extern, static, export, explicit, inline, etc
go on the line above the function name. Thus
- virtual int
+ virtual int
foo()
-NOT-
virtual int foo()
-NOT-
public:
-
+
int foo;
13. Spacing WRT return statements.
Name patterns:
- For nonstandard names appearing in Standard headers, we are constrained
+ 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
+ Examples: __count __ix __s1
Type names and template formal-argument names: _[A-Z][^_].*
- Examples: _Helper _CharT _N
+ Examples: _Helper _CharT _N
Member data and function names: _M_.*
Examples: _S_max_elements _S_default_value
- Don't use names in the same scope that differ only in the prefix,
+ 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".)
--------------------------
[BY EXAMPLE]
-
+
#ifndef _HEADER_
#define _HEADER_ 1
gribble(const gribble&);
- explicit
+ explicit
gribble(int __howmany);
- gribble&
+ gribble&
operator=(const gribble&);
- virtual
+ virtual
~gribble() throw ();
// Start with a capital letter, end with a period.
- inline void
+ inline void
public_member(const char* __arg) const;
// In-class function definitions should be restricted to one-liners.
- int
+ int
one_line() { return 0 }
- int
- two_lines(const char* arg)
+ int
+ two_lines(const char* arg)
{ return strchr(arg, 'a'); }
- inline int
+ inline int
three_lines(); // inline, but defined below.
// Note indentation.
template<typename _Formal_argument>
- void
+ void
public_template() const throw();
template<typename _Iterator>
- void
+ void
other_template();
private:
_Helper* _M_helper;
int _M_private_function();
- enum _Enum
- {
- _S_one,
- _S_two
+ enum _Enum
+ {
+ _S_one,
+ _S_two
};
- static void
+ static void
_S_initialize_library();
};
#endif /* _HEADER_ */
- namespace std
+ namespace std
{
template<typename T> // notice: "typename", not "class", no space
- long_return_value_type<with_many, args>
+ long_return_value_type<with_many, args>
function_name(char* pointer, // "char *pointer" is wrong.
- char* argument,
+ char* argument,
const Reference& ref)
{
// int a_local; /* wrong; see below. */
- if (test)
- {
- nested code
+ if (test)
+ {
+ nested code
}
-
+
int a_local = 0; // declare variable at first use.
// char a, b, *p; /* wrong */
// ...
}
}
-
+
gribble::gribble()
: _M_private_data(0), _M_more_stuff(0), _M_helper(0);
{ }
- inline int
+ inline int
gribble::three_lines()
{
// doesn't fit in one line.
} // namespace std
</literallayout>
</sect2>
-</sect1>
+</sect1>
<sect1 id="contrib.doc_style" xreflabel="Documentation Style">
+ <?dbhtml filename="documentation_style.html"?>
<title>Documentation Style</title>
- <sect2 id="doc_style.doxygen" xreflabel="doc_style.doxygen">
+ <sect2 id="doc_style.doxygen">
<title>Doxygen</title>
- <sect3 id="doxygen.prereq" xreflabel="doxygen.prereq">
+ <sect3 id="doxygen.prereq">
<title>Prerequisites</title>
<para>
Prerequisite tools are Bash 2.x,
the <ulink url="http://www.gnu.org/software/coreutils/">GNU
coreutils</ulink>. (GNU versions of find, xargs, and possibly
sed and grep are used, just because the GNU versions make
- things very easy.)
+ things very easy.)
</para>
<para>
To generate the pretty pictures and hierarchy
graphs, the
- <ulink url="http://www.research.att.com/sw/tools/graphviz/download.html">Graphviz</ulink>
- package will need to be installed.
+ <ulink url="http://www.graphviz.org">Graphviz</ulink> package
+ will need to be installed. For PDF
+ output, <ulink url="http://www.tug.org/applications/pdftex/">
+ pdflatex</ulink> is required.
</para>
</sect3>
- <sect3 id="doxygen.rules" xreflabel="doxygen.rules">
+ <sect3 id="doxygen.rules">
<title>Generating the Doxygen Files</title>
<para>
- The Makefile rules
+ The following Makefile rules run Doxygen to generate HTML
+ docs, XML docs, PDF docs, and the man pages.
</para>
- <screen><userinput>make doc-html-doxygen</userinput></screen>
+
<para>
- and
+ <screen><userinput>make doc-html-doxygen</userinput></screen>
</para>
+
+ <para>
<screen><userinput>make doc-xml-doxygen</userinput></screen>
+ </para>
+
<para>
- and
+ <screen><userinput>make doc-pdf-doxygen</userinput></screen>
</para>
- <screen><userinput>make doc-man-doxygen</userinput></screen>
+
<para>
- in the libstdc++ build directory generate the HTML docs, the
- XML docs, and the man pages.
+ <screen><userinput>make doc-man-doxygen</userinput></screen>
</para>
<para>
</sect3>
- <sect3 id="doxygen.markup" xreflabel="doxygen.markup">
+ <sect3 id="doxygen.markup">
<title>Markup</title>
<para>
</para>
<para>
- These points accompany the first list in section 3.1 of the
- Doxygen manual:
+ Some commentary to accompany
+ the first list in the <ulink url="http://www.stack.nl/~dimitri/doxygen/docblocks.html">Special
+ Documentation Blocks</ulink> section of
+ the Doxygen manual:
</para>
<orderedlist>
- <listitem><para>Use the Javadoc style...</para></listitem>
+ <listitem>
+ <para>For longer comments, use the Javadoc style...</para>
+ </listitem>
+
<listitem>
<para>
...not the Qt style. The intermediate *'s are preferred.
</para>
</listitem>
- <listitem>
+
+ <listitem>
<para>
Use the triple-slash style only for one-line comments (the
- <quote>brief</quote> mode). Very recent versions of Doxygen permit
- full-mode comments in triple-slash blocks, but the
- formatting still comes out wonky.
+ <quote>brief</quote> mode).
</para>
</listitem>
+
<listitem>
<para>
This is disgusting. Don't do this.
</orderedlist>
<para>
+ Some specific guidelines:
+ </para>
+
+ <para>
Use the @-style of commands, not the !-style. Please be
careful about whitespace in your markup comments. Most of the
time it doesn't matter; doxygen absorbs most whitespace, and
(Examples of all these abound in the present code.)
</para>
+ <para>
+ Complicated math functions should use the multi-line
+ format. An example from <filename>random.h</filename>:
+ </para>
+
+ <para>
+<literallayout>
+ /**
+ * @brief A model of a linear congruential random number generator.
+ *
+ * @f[
+ * x_{i+1}\leftarrow(ax_{i} + c) \bmod m
+ * @f]
+ */
+</literallayout>
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+<table frame='all'>
+<title>HTML to Doxygen Markup Comparison</title>
+<tgroup cols='2' align='left' colsep='1' rowsep='1'>
+<colspec colname='c1'></colspec>
+<colspec colname='c2'></colspec>
+
+ <thead>
+ <row>
+ <entry>HTML</entry>
+ <entry>Doxygen</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>\</entry>
+ <entry>\\</entry>
+ </row>
+
+ <row>
+ <entry>"</entry>
+ <entry>\"</entry>
+ </row>
+
+ <row>
+ <entry>'</entry>
+ <entry>\'</entry>
+ </row>
+
+ <row>
+ <entry><i></entry>
+ <entry>@a word</entry>
+ </row>
+
+ <row>
+ <entry><b></entry>
+ <entry>@b word</entry>
+ </row>
+
+ <row>
+ <entry><code></entry>
+ <entry>@c word</entry>
+ </row>
+
+ <row>
+ <entry><em></entry>
+ <entry>@a word</entry>
+ </row>
+
+ <row>
+ <entry><em></entry>
+ <entry><em>two words or more</em></entry>
+ </row>
+ </tbody>
+
+</tgroup>
+</table>
+
+
</sect3>
</sect2>
- <sect2 id="doc_style.docbook" xreflabel="doc_style.docbook">
+ <sect2 id="doc_style.docbook">
<title>Docbook</title>
- <sect3 id="docbook.prereq" xreflabel="docbook.prereq">
+ <sect3 id="docbook.prereq">
<title>Prerequisites</title>
<para>
Editing the DocBook sources requires an XML editor. Many
<para>
Access to the DocBook stylesheets and DTD is required. The
stylesheets are usually packaged by vendor, in something
- like <filename>docbook-style-xsl</filename>. The installation
- directory for this package corresponds to
+ like <filename>docbook-style-xsl</filename>. To exactly match
+ generated output, please use a version of the stylesheets
+ equivalent
+ to <filename>docbook-style-xsl-1.74.0-5</filename>. The
+ installation directory for this package corresponds to
the <literal>XSL_STYLE_DIR</literal>
in <filename>doc/Makefile.am</filename> and defaults
to <filename class="directory">/usr/share/sgml/docbook/xsl-stylesheets</filename>.
For validating the XML document, you'll need
something like <command>xmllint</command> and access to the
DocBook DTD. These are provided
- by a vendor package like <filename>lixml2</filename>.
+ by a vendor package like <filename>libxml2</filename>.
</para>
<para>
For PDF output, something that transforms valid XML to PDF is
- required. Possible solutions include <command>xmlto</command>,
- <ulink url="http://xmlgraphics.apache.org/fop/">Apache
- FOP</ulink>, or <command>prince</command>. Other options are
- listed on the DocBook web <ulink
- url="http://wiki.docbook.org/topic/DocBookPublishingTools">pages</ulink>. Please
+ required. Possible solutions include
+ <ulink url="http://dblatex.sourceforge.net">dblatex</ulink>,
+ <command>xmlto</command>, or <command>prince</command>. Other
+ options are listed on the DocBook
+ web <ulink url="http://wiki.docbook.org/topic/DocBookPublishingTools">pages</ulink>. Please
consult the <email>libstdc++@gcc.gnu.org</email> list when
- preparing printed manuals for current best practice and suggestions.
+ preparing printed manuals for current best practice and
+ suggestions.
</para>
-
+
<para>
Make sure that the XML documentation and markup is valid for
any change. This can be done easily, with the validation rules
- in the <filename>Makefile</filename>, which is equivalent to doing:
+ in the <filename>Makefile</filename>, which is equivalent to doing:
</para>
<screen>
</screen>
</sect3>
- <sect3 id="docbook.rules" xreflabel="docbook.rules">
+ <sect3 id="docbook.rules">
<title>Generating the DocBook Files</title>
<para>
- The Makefile rules
+ The following Makefile rules generate (in order): an HTML
+ version of all the DocBook documentation, a PDF version of the same, a
+ single XML document, and the result of validating the entire XML
+ document.
</para>
- <screen><userinput>make doc-html</userinput></screen>
+
<para>
- and
+ <screen><userinput>make doc-html-docbook</userinput></screen>
</para>
- <screen><userinput>make doc-pdf</userinput></screen>
+
<para>
- and
+ <screen><userinput>make doc-pdf-docbook</userinput></screen>
</para>
- <screen><userinput>make doc-xml-single</userinput></screen>
+
<para>
- and
+ <screen><userinput>make doc-xml-single-docbook</userinput></screen>
</para>
- <screen><userinput>make doc-xml-validate</userinput></screen>
<para>
- in the libstdc++ build directory result respectively in the
- following: the generation of an HTML version of all the
- documentation, a PDF version of the same, a single XML
- document, and the results of validating the XML document.
+ <screen><userinput>make doc-xml-validate-docbook</userinput></screen>
</para>
+
</sect3>
- <sect3 id="docbook.examples" xreflabel="docbook.examples">
+ <sect3 id="docbook.examples">
<title>File Organization and Basics</title>
<literallayout>
libstdc++-v3/doc/xml
Inside this directory, the files of importance:
- spine.xml - index to documentation set
+ 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
+ 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.
</chapter>
</book>
- <book>
+ <book>
<part>
<chapter>
<section>
<chapter>
</chapter>
- </part>
+ </part>
</book>
</set>
</literallayout>
</sect3>
- <sect3 id="docbook.markup" xreflabel="docbook.markup">
+ <sect3 id="docbook.markup">
<title>Markup By Example</title>
- <literallayout>
- HTML to XML rough equivalents
-
- <p> <para>
-
- <pre> <computeroutput>
- <pre> <programlisting>
- <pre> <literallayout>
-
- <ul> <itemizedlist>
- <ol> <orderedlist>
- <il> <listitem>
-
- <dl> <variablelist>
-
- <varlistentry>
- <dt> <term>
- </dt> </term>
- <dd> <listitem>
- </dt> </listitem>
- </varlistentry>
-
- <a href <ulink url
- <code> <literal>
- <code> <programlisting>
-
- <strong> <emphasis>
- <em> <emphasis>
- " <quote>
-
- ctype.h <filename class="headerfile"></filename>
-
-
- build_dir <filename class="directory">path_to_build_dir</filename>
-
- Finer gradations of <code>
-
- <classname> <classname>string</classname>
- <classname>vector<></classname>
- <function>fs.clear()</function>
+ <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>
- <structname>
+<table frame='all'>
+<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>
+
+ <thead>
+ <row>
+ <entry>HTML</entry>
+ <entry>Docbook</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><p></entry>
+ <entry><para></entry>
+ </row>
+ <row>
+ <entry><pre></entry>
+ <entry><computeroutput>, <programlisting>,
+ <literallayout></entry>
+ </row>
+ <row>
+ <entry><ul></entry>
+ <entry><itemizedlist></entry>
+ </row>
+ <row>
+ <entry><ol></entry>
+ <entry><orderedlist></entry>
+ </row>
+ <row>
+ <entry><il></entry>
+ <entry><listitem></entry>
+ </row>
+ <row>
+ <entry><dl></entry>
+ <entry><variablelist></entry>
+ </row>
+ <row>
+ <entry><dt></entry>
+ <entry><term></entry>
+ </row>
+ <row>
+ <entry><dd></entry>
+ <entry><listitem></entry>
+ </row>
+
+ <row>
+ <entry><a href=""></entry>
+ <entry><ulink url=""></entry>
+ </row>
+ <row>
+ <entry><code></entry>
+ <entry><literal>, <programlisting></entry>
+ </row>
+ <row>
+ <entry><strong></entry>
+ <entry><emphasis></entry>
+ </row>
+ <row>
+ <entry><em></entry>
+ <entry><emphasis></entry>
+ </row>
+ <row>
+ <entry>"</entry>
+ <entry><quote></entry>
+ </row>
+ </tbody>
+</tgroup>
+</table>
+
+<para>
+ And examples of detailed markup for which there are no real HTML
+ equivalents are listed in the table below.
+</para>
- <function> <function>clear()</function>
+<table frame='all'>
+<title>Docbook XML Element Use</title>
+<tgroup cols='2' align='left' colsep='1' rowsep='1'>
+<colspec colname='c1'></colspec>
+<colspec colname='c2'></colspec>
+
+ <thead>
+ <row>
+ <entry>Element</entry>
+ <entry>Use</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><structname></entry>
+ <entry><structname>char_traits</structname></entry>
+ </row>
+ <row>
+ <entry><classname></entry>
+ <entry><classname>string</classname></entry>
+ </row>
+ <row>
+ <entry><function></entry>
+ <entry>
+ <para><function>clear()</function></para>
+ <para><function>fs.clear()</function></para>
+ </entry>
+ </row>
+ <row>
+ <entry><type></entry>
+ <entry><type>long long</type></entry>
+ </row>
+ <row>
+ <entry><varname></entry>
+ <entry><varname>fs</varname></entry>
+ </row>
+ <row>
+ <entry><literal></entry>
+ <entry>
+ <para><literal>-Weffc++</literal></para>
+ <para><literal>rel_ops</literal></para>
+ </entry>
+ </row>
+ <row>
+ <entry><constant></entry>
+ <entry>
+ <para><constant>_GNU_SOURCE</constant></para>
+ <para><constant>3.0</constant></para>
+ </entry>
+ </row>
+ <row>
+ <entry><command></entry>
+ <entry><command>g++</command></entry>
+ </row>
+ <row>
+ <entry><errortext></entry>
+ <entry><errortext>In instantiation of</errortext></entry>
+ </row>
+ <row>
+ <entry><filename></entry>
+ <entry>
+ <para><filename class="headerfile">ctype.h</filename></para>
+ <para><filename class="directory">/home/gcc/build</filename></para>
+ <para><filename class="libraryfile">libstdc++.so</filename></para>
+ </entry>
+ </row>
+ </tbody>
+</tgroup>
+</table>
- <type> <type>long long</type>
+ </sect3>
+ </sect2>
- <varname> <varname>fs</varname>
+ <sect2 id="doc_style.combines">
+ <title>Combines</title>
- <literal> <literal>-Weffc++</literal>
- <literal>rel_ops</literal>
+ <sect3 id="combines.rules">
+ <title>Generating Combines and Assemblages</title>
- <constant> <constant>_GNU_SOURCE</constant>
- <constant>3.0</constant>
+ <para>
+ The following Makefile rules are defaults, and are usually
+ aliased to variable rules.
+ </para>
- <filename>
+ <para>
+ <screen><userinput>make doc-html</userinput></screen>
+ </para>
- <command> <command>g++</command>
+ <para>
+ <screen><userinput>make doc-man</userinput></screen>
+ </para>
- <errortext> <errortext>foo Concept </errortext>
-</literallayout>
- </sect3>
+ <para>
+ <screen><userinput>make doc-pdf</userinput></screen>
+ </para>
+ </sect3>
</sect2>
-
-</sect1>
+</sect1>
<sect1 id="contrib.design_notes" xreflabel="Design Notes">
+ <?dbhtml filename="source_design_notes.html"?>
<title>Design Notes</title>
<para>
</para>
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.ch/ to find out the location
+ 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.
include them via "<backward/hash_map.h>" or "<ext/hash_map>" than
to search the subdirectory itself via a "-I" directive.
</literallayout>
-</sect1>
+</sect1>
</appendix>
OSDN Git Service
