1<chapter xmlns="http://docbook.org/ns/docbook" version="5.0"
2	 xml:id="std.algorithms" xreflabel="Algorithms">
3<?dbhtml filename="algorithms.html"?>
4
5<info><title>
6  Algorithms
7  <indexterm><primary>Algorithms</primary></indexterm>
8</title>
9  <keywordset>
10    <keyword>ISO C++</keyword>
11    <keyword>library</keyword>
12    <keyword>algorithm</keyword>
13  </keywordset>
14</info>
15
16
17
18<para>
19  The neatest accomplishment of the algorithms section is that all the
20  work is done via iterators, not containers directly.  This means two
21  important things:
22</para>
23<orderedlist inheritnum="ignore" continuation="restarts">
24  <listitem>
25    <para>
26      Anything that behaves like an iterator can be used in one of
27      these algorithms.  Raw pointers make great candidates, thus
28      built-in arrays are fine containers, as well as your own
29      iterators.
30    </para>
31  </listitem>
32  <listitem>
33    <para>
34      The algorithms do not (and cannot) affect the container as a
35      whole; only the things between the two iterator endpoints.  If
36      you pass a range of iterators only enclosing the middle third of
37      a container, then anything outside that range is inviolate.
38    </para>
39  </listitem>
40</orderedlist>
41<para>
42  Even strings can be fed through the algorithms here, although the
43  string class has specialized versions of many of these functions
44  (for example, <code>string::find()</code>).  Most of the examples
45  on this page will use simple arrays of integers as a playground
46  for algorithms, just to keep things simple.  The use of
47  <emphasis>N</emphasis> as a size in the examples is to keep things
48  easy to read but probably won't be valid code.  You can use wrappers
49  such as those described in
50  the <link linkend="std.containers">containers section</link> to keep
51  real code readable.
52</para>
53<para>
54  The single thing that trips people up the most is the definition
55  of <emphasis>range</emphasis> used with iterators; the famous
56  "past-the-end" rule that everybody loves to hate.  The
57  <link linkend="std.iterators">iterators section</link> of this
58    document has a complete explanation of this simple rule that seems
59    to cause so much confusion.  Once you
60    get <emphasis>range</emphasis> into your head (it's not that hard,
61    honest!), then the algorithms are a cakewalk.
62</para>
63
64<!-- Sect1 01 : Non Modifying -->
65
66<!-- Sect1 02 : Mutating -->
67<section xml:id="std.algorithms.mutating" xreflabel="Mutating"><info><title>Mutating</title></info>
68
69
70  <section xml:id="algorithms.mutating.swap" xreflabel="swap"><info><title><function>swap</function></title></info>
71
72
73    <section xml:id="algorithms.swap.specializations" xreflabel="Specializations"><info><title>Specializations</title></info>
74
75
76   <para>If you call <code> std::swap(x,y); </code> where x and y are standard
77      containers, then the call will automatically be replaced by a call to
78      <code> x.swap(y); </code> instead.
79   </para>
80   <para>This allows member functions of each container class to take over, and
81      containers' swap functions should have O(1) complexity according to
82      the standard.  (And while "should" allows implementations to
83      behave otherwise and remain compliant, this implementation does in
84      fact use constant-time swaps.)  This should not be surprising, since
85      for two containers of the same type to swap contents, only some
86      internal pointers to storage need to be exchanged.
87   </para>
88
89    </section>
90  </section>
91</section>
92
93<!-- Sect1 03 : Sorting -->
94
95</chapter>
96