| <chapter xmlns="http://docbook.org/ns/docbook" version="5.0" | |
| xml:id="std.algorithms" xreflabel="Algorithms"> | |
| <?dbhtml filename="algorithms.html"?> | |
| <info><title> | |
| Algorithms | |
| <indexterm><primary>Algorithms</primary></indexterm> | |
| </title> | |
| <keywordset> | |
| <keyword>ISO C++</keyword> | |
| <keyword>library</keyword> | |
| <keyword>algorithm</keyword> | |
| </keywordset> | |
| </info> | |
| <para> | |
| The neatest accomplishment of the algorithms section is that all the | |
| work is done via iterators, not containers directly. This means two | |
| important things: | |
| </para> | |
| <orderedlist inheritnum="ignore" continuation="restarts"> | |
| <listitem> | |
| <para> | |
| Anything that behaves like an iterator can be used in one of | |
| these algorithms. Raw pointers make great candidates, thus | |
| built-in arrays are fine containers, as well as your own | |
| iterators. | |
| </para> | |
| </listitem> | |
| <listitem> | |
| <para> | |
| The algorithms do not (and cannot) affect the container as a | |
| whole; only the things between the two iterator endpoints. If | |
| you pass a range of iterators only enclosing the middle third of | |
| a container, then anything outside that range is inviolate. | |
| </para> | |
| </listitem> | |
| </orderedlist> | |
| <para> | |
| Even strings can be fed through the algorithms here, although the | |
| string class has specialized versions of many of these functions | |
| (for example, <code>string::find()</code>). Most of the examples | |
| on this page will use simple arrays of integers as a playground | |
| for algorithms, just to keep things simple. The use of | |
| <emphasis>N</emphasis> as a size in the examples is to keep things | |
| easy to read but probably won't be valid code. You can use wrappers | |
| such as those described in | |
| the <link linkend="std.containers">containers section</link> to keep | |
| real code readable. | |
| </para> | |
| <para> | |
| The single thing that trips people up the most is the definition | |
| of <emphasis>range</emphasis> used with iterators; the famous | |
| "past-the-end" rule that everybody loves to hate. The | |
| <link linkend="std.iterators">iterators section</link> of this | |
| document has a complete explanation of this simple rule that seems | |
| to cause so much confusion. Once you | |
| get <emphasis>range</emphasis> into your head (it's not that hard, | |
| honest!), then the algorithms are a cakewalk. | |
| </para> | |
| <!-- Sect1 01 : Non Modifying --> | |
| <!-- Sect1 02 : Mutating --> | |
| <section xml:id="std.algorithms.mutating" xreflabel="Mutating"><info><title>Mutating</title></info> | |
| <section xml:id="algorithms.mutating.swap" xreflabel="swap"><info><title><function>swap</function></title></info> | |
| <section xml:id="algorithms.swap.specializations" xreflabel="Specializations"><info><title>Specializations</title></info> | |
| <para>If you call <code> std::swap(x,y); </code> where x and y are standard | |
| containers, then the call will automatically be replaced by a call to | |
| <code> x.swap(y); </code> instead. | |
| </para> | |
| <para>This allows member functions of each container class to take over, and | |
| containers' swap functions should have O(1) complexity according to | |
| the standard. (And while "should" allows implementations to | |
| behave otherwise and remain compliant, this implementation does in | |
| fact use constant-time swaps.) This should not be surprising, since | |
| for two containers of the same type to swap contents, only some | |
| internal pointers to storage need to be exchanged. | |
| </para> | |
| </section> | |
| </section> | |
| </section> | |
| <!-- Sect1 03 : Sorting --> | |
| </chapter> |