containers.xml (associative.bitset.size_variable): Fix bad s/part/chapter/ substitutions.

	* doc/xml/manual/containers.xml (associative.bitset.size_variable):
	Fix bad s/part/chapter/ substitutions.
	* doc/xml/manual/io.xml (std.io): Likewise.
	* doc/xml/manual/numerics.xml (std.numerics.generalized_ops): Likewise.
	* doc/xml/manual/strings.xml (strings.string.Cstring): Likewise.

From-SVN: r208874

libstdc++-v3/ChangeLog

@@ -9,6 +9,12 @@
 	Likewise.
 	* doc/xml/manual/test.xml (test.organization.layout): Likewise.
 
+	* doc/xml/manual/containers.xml (associative.bitset.size_variable):
+	Fix bad s/part/chapter/ substitutions.
+	* doc/xml/manual/io.xml (std.io): Likewise.
+	* doc/xml/manual/numerics.xml (std.numerics.generalized_ops): Likewise.
+	* doc/xml/manual/strings.xml (strings.string.Cstring): Likewise.
+
 2014-03-27  Jonathan Wakely  <jwakely@redhat.com>
 
 	PR libstdc++/60612

libstdc++-v3/doc/xml/manual/containers.xml

@@ -232,7 +232,7 @@
    <para>
      There are a couple of ways to handle this kind of thing.  Please
      consider all of them before passing judgement.  They include, in
-     no chaptericular order:
+     no particular order:
    </para>
       <itemizedlist>
 	<listitem><para>A very large N in <code>bitset&lt;N&gt;</code>.</para></listitem>

libstdc++-v3/doc/xml/manual/io.xml

@@ -424,7 +424,7 @@
    <para>Seriously, go do it.  Get surprised, then come back.  It's worth it.
    </para>
    <para>The thing to remember is that the <code>basic_[io]stream</code> classes
-      handle formatting, nothing else.  In chaptericular, they break up on
+      handle formatting, nothing else.  In particular, they break up on
       whitespace.  The actual reading, writing, and storing of data is
       handled by the <code>basic_streambuf</code> family.  Fortunately, the
       <code>operator&lt;&lt;</code> is overloaded to take an ostream and
@@ -442,7 +442,7 @@
    <programlisting>
    OUT &lt;&lt; IN.rdbuf();</programlisting>
    <para>So what <emphasis>was</emphasis> happening with OUT&lt;&lt;IN?  Undefined
-      behavior, since that chaptericular &lt;&lt; isn't defined by the Standard.
+      behavior, since that particular &lt;&lt; isn't defined by the Standard.
       I have seen instances where it is implemented, but the character
       extraction process removes all the whitespace, leaving you with no
       blank lines and only "Thequickbrownfox...".  With
@@ -659,7 +659,7 @@
    <para>Note, by the way, that the synchronization requirement only applies to
       the standard streams (<code>cin</code>, <code>cout</code>,
       <code>cerr</code>,
-      <code>clog</code>, and their wide-character counterchapters).  File stream
+      <code>clog</code>, and their wide-character counterparts).  File stream
       objects that you declare yourself have no such requirement and are fully
       buffered.
    </para>

libstdc++-v3/doc/xml/manual/numerics.xml

@@ -65,7 +65,7 @@
    <itemizedlist>
       <listitem><para><code>accumulate</code></para></listitem>
       <listitem><para><code>inner_product</code></para></listitem>
-      <listitem><para><code>chapterial_sum</code></para></listitem>
+      <listitem><para><code>partial_sum</code></para></listitem>
       <listitem><para><code>adjacent_difference</code></para></listitem>
    </itemizedlist>
    <para>Here is a simple example of the two forms of <code>accumulate</code>.

libstdc++-v3/doc/xml/manual/strings.xml

@@ -462,7 +462,7 @@ stringtok(Container &container, string const &in,
 	     <emphasis>if the implementors do it correctly</emphasis>.  The libstdc++
 	     implementors did it correctly.  Other vendors might not.
 	 </para></listitem>
-	 <listitem><para>While chapters of the SGI STL are used in libstdc++, their
+	 <listitem><para>While parts of the SGI STL are used in libstdc++, their
 	     string class is not.  The SGI <code>string</code> is essentially
 	     <code>vector&lt;char&gt;</code> and does not do any reference
 	     counting like libstdc++'s does.  (It is O(n), though.)