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