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