c6a21af2ff
2010-07-22 Benjamin Kosnik <bkoz@redhat.com> DocBook 4.5 to 5.0 transition. * doc/xml/authors.xml: Update markup to DocBook 5.0. * doc/xml/faq.xml: Same. * doc/xml/api.xml: Same. * doc/xml/class.txml * doc/xml/gnu/gpl-3.0.xml: Same. * doc/xml/gnu/fdl-1.2.xml: Same. * doc/xml/gnu/fdl-1.3.xml: Same. * doc/xml/gnu/gpl-2.0.xml: Same. * doc/xml/chapter.txml: Same. * doc/xml/manual/mt_allocator.xml: Same. * doc/xml/manual/allocator.xml: Same. * doc/xml/manual/ctype.xml: Same. * doc/xml/manual/numerics.xml: Same. * doc/xml/manual/codecvt.xml: Same. * doc/xml/manual/backwards_compatibility.xml: Same. * doc/xml/manual/concurrency.xml: Same. * doc/xml/manual/intro.xml: Same. * doc/xml/manual/abi.xml: Same. * doc/xml/manual/shared_ptr.xml: Same. * doc/xml/manual/status_cxxtr1.xml: Same. * doc/xml/manual/auto_ptr.xml: Same. * doc/xml/manual/internals.xml: Same. * doc/xml/manual/atomics.xml: Same. * doc/xml/manual/parallel_mode.xml: Same. * doc/xml/manual/status_cxx1998.xml: Same. * doc/xml/manual/profile_mode.xml: Same. * doc/xml/manual/containers.xml: Same. * doc/xml/manual/io.xml: Same. * doc/xml/manual/concurrency_extensions.xml: Same. * doc/xml/manual/appendix_porting.xml: Same. * doc/xml/manual/utilities.xml: Same. * doc/xml/manual/support.xml: Same. * doc/xml/manual/bitmap_allocator.xml: Same. * doc/xml/manual/configure.xml: Same. * doc/xml/manual/build_hacking.xml: Same. * doc/xml/manual/evolution.xml: Same. * doc/xml/manual/using.xml: Same. * doc/xml/manual/using_exceptions.xml: Same. * doc/xml/manual/debug.xml: Same. * doc/xml/manual/localization.xml: Same. * doc/xml/manual/strings.xml: Same. * doc/xml/manual/debug_mode.xml: Same. * doc/xml/manual/locale.xml: Same. * doc/xml/manual/extensions.xml: Same. * doc/xml/manual/appendix_contributing.xml: Same. * doc/xml/manual/prerequisites.xml: Same. * doc/xml/manual/messages.xml: Same. * doc/xml/manual/diagnostics.xml: Same. * doc/xml/manual/algorithms.xml: Same. * doc/xml/manual/appendix_free.xml: Same. * doc/xml/manual/iterators.xml: Same. * doc/xml/manual/spine.xml: Same. * doc/xml/manual/status_cxxtr24733.xml: Same. * doc/xml/manual/status_cxx200x.xml: Same. * doc/xml/manual/test.xml: Same. * doc/xml/book.txml: Same. * doc/xml/spine.xml: Same. * doc/Makefile.am: Same. * doc/Makefile.in: Regenerate. From-SVN: r162433
102 lines
3.5 KiB
XML
102 lines
3.5 KiB
XML
<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 sect1 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 sect1</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 sect1</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>
|