4312e020f1
2008-01-18 Benjamin Kosnik <bkoz@redhat.com> * docs/*: To... * doc/*: ...here. * testsuite/Makefile.am: Move doc-performance to... * Makefile.am: Add doc to SUBDIRS, move doxygen-* rules to... * doc/Makefile.am: Consolidate documentation creation here. (doc-doxygen-html): New. (doc-doxygen-man): New. (doc-performance): New. * doc/Makefile.in: New. * acinclude.m4 (glibcxx_SUBDIRS): Add doc directory. * doc/doxygen/guide.html: Edit for unified html configuration. * doc/doxygen/mainpage.html: Same. * doc/doxygen/run_doxygen: Same, more namespace fixups for man generation. * doc/doxygen/user.cfg.in: Update for doxygen 1.5.4. * include/tr1_impl/random: Remove maint from doxygen markup. * include/tr1_impl/functional: Same. * include/std/tuple: Same. * include/std/streambuf: Same. * include/std/bitset: Same. * include/std/limits: Same. * include/std/fstream: Same. * include/std/istream: Same. * include/std/sstream: Same. * include/ext/pool_allocator.h: Same. * include/ext/rc_string_base.h: Same. * include/bits/basic_ios.h: Same. * include/bits/stl_list.h: Same. * include/bits/stl_map.h: Same. * include/bits/locale_classes.h: Same. * include/bits/stl_set.h: Same. * include/bits/stl_iterator_base_types.h: Same. * include/bits/basic_string.h: Same. * include/bits/stl_multimap.h: Same. * include/bits/stl_vector.h: Same. * include/bits/ios_base.h: Same. * include/bits/stl_deque.h: Same. * include/bits/postypes.h: Same. * include/bits/stl_multiset.h: Same. * include/bits/stl_algo.h: Same. * include/bits/stl_iterator.h: Same. * include/bits/stl_tempbuf.h: Same. * include/bits/stl_construct.h: Same. * include/bits/stl_relops.h: Same. * include/tr1/tuple: Same. * include/backward/auto_ptr.h: Same. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Fixups for line number changes. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Same. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Same. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Same. * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Same. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Same. * testsuite/23_containers/deque/requirements/dr438/ constructor_1_neg.cc: Same. * testsuite/23_containers/deque/requirements/dr438/ constructor_2_neg.cc: Same. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Same. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Same. * testsuite/23_containers/list/requirements/dr438/ constructor_1_neg.cc: Same. * testsuite/23_containers/list/requirements/dr438/ constructor_2_neg.cc: Same. * testsuite/20_util/auto_ptr/assign_neg.cc: Same. * aclocal.m4: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * libmath/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * scripts/make_graphs.py: Correct paths for new layout. 2008-01-17 Benjamin Kosnik <bkoz@redhat.com> * acinclude.m4 (AC_LC_MESSAGES): Remove serial. * linkage.m4 (AC_REPLACE_MATHFUNCS): Same. * configure: Regenerate. * aclocal.m4: Regenerate. From-SVN: r131625
120 lines
5.4 KiB
HTML
120 lines
5.4 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
|
|
|
|
<title>Introduction</title>
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=us-ascii" />
|
|
</head>
|
|
|
|
<body>
|
|
<div id="page">
|
|
<h1>Introduction</h1>
|
|
|
|
<p>This section describes what problems the library attempts to
|
|
solve. <a href="motivation.html">Motivation</a> describes the
|
|
reasons we think it solves these problems better than similar
|
|
libraries.</p>
|
|
|
|
<h2><a name="assoc" id="assoc">Associative Containers</a></h2>
|
|
|
|
<ol>
|
|
<li>Associative containers depend on their policies to a very
|
|
large extent. Implicitly hard-wiring policies can hamper their
|
|
performance and limit their functionality. An efficient
|
|
hash-based container, for example, requires policies for
|
|
testing key equivalence, hashing keys, translating hash
|
|
values into positions within the hash table, and determining
|
|
when and how to resize the table internally. A tree-based
|
|
container can efficiently support order statistics,
|
|
<i>i.e.</i>, the ability to query what is the order of each
|
|
key within the sequence of keys in the container, but only if
|
|
the container is supplied with a policy to internally update
|
|
meta-data. There are many other such examples.<p></p></li>
|
|
|
|
<li>Ideally, all associative containers would share the same
|
|
interface. Unfortunately, underlying data structures and
|
|
mapping semantics differentiate between different containers.
|
|
For example, suppose one writes a generic function
|
|
manipulating an associative container <tt>Cntnr</tt>:
|
|
<pre>
|
|
template<typename Cntnr>
|
|
void
|
|
some_op_sequence(Cntnr& r_cnt)
|
|
{
|
|
...
|
|
}
|
|
</pre>
|
|
|
|
then what can one assume about <tt>Cntnr</tt>? The answer
|
|
varies according to its underlying data structure. If the
|
|
underlying data structure of <tt>Cntnr</tt> is based on a tree or
|
|
trie, then the order of elements is well defined; otherwise, it is
|
|
not, in general. If the underlying data structure of <tt>Cntnr</tt>
|
|
is based on a collision-chaining hash table, then modifying
|
|
r_<tt>Cntnr</tt> will not invalidate its iterators' order; if the
|
|
underlying data structure is a probing hash table, then this is not
|
|
the case. If the underlying data structure is based on a tree or
|
|
trie, then <tt>r_cnt</tt> can efficiently be split; otherwise, it
|
|
cannot, in general. If the underlying data structure is a red-black
|
|
tree, then splitting <tt>r_cnt</tt> is exception-free; if it is an
|
|
ordered-vector tree, exceptions can be thrown.
|
|
<p></p></li>
|
|
</ol>
|
|
|
|
<h2><a name="pq" id="pq">Priority Queues</a></h2>
|
|
|
|
<p>Priority queues are useful when one needs to efficiently
|
|
access a minimum (or maximum) value as the set of values
|
|
changes.</p>
|
|
|
|
<ol>
|
|
<li>Most useful data structures for priority queues have a
|
|
relatively simple structure, as they are geared toward
|
|
relatively simple requirements. Unfortunately, these structures
|
|
do not support access to an arbitrary value, which turns out to
|
|
be necessary in many algorithms. Say, decreasing an arbitrary
|
|
value in a graph algorithm. Therefore, some extra mechanism is
|
|
necessary and must be invented for accessing arbitrary
|
|
values. There are at least two alternatives: embedding an
|
|
associative container in a priority queue, or allowing
|
|
cross-referencing through iterators. The first solution adds
|
|
significant overhead; the second solution requires a precise
|
|
definition of iterator invalidation. Which is the next
|
|
point...<p></p></li>
|
|
|
|
<li>Priority queues, like hash-based containers, store values in
|
|
an order that is meaningless and undefined externally. For
|
|
example, a <tt>push</tt> operation can internally reorganize the
|
|
values. Because of this characteristic, describing a priority
|
|
queues' iterator is difficult: on one hand, the values to which
|
|
iterators point can remain valid, but on the other, the logical
|
|
order of iterators can change unpredictably.<p></p></li>
|
|
|
|
<li>Roughly speaking, any element that is both inserted to a
|
|
priority queue (<i>e.g.</i>, through <tt>push</tt>) and removed
|
|
from it (<i>e.g.</i>, through <tt>pop</tt>), incurs a
|
|
logarithmic overhead (in the amortized sense). Different
|
|
underlying data structures place the actual cost differently:
|
|
some are optimized for amortized complexity, whereas others
|
|
guarantee that specific operations only have a constant
|
|
cost. One underlying data structure might be chosen if modifying
|
|
a value is frequent (Dijkstra's shortest-path algorithm),
|
|
whereas a different one might be chosen
|
|
otherwise. Unfortunately, an array-based binary heap - an
|
|
underlying data structure that optimizes (in the amortized
|
|
sense) <tt>push</tt> and <tt>pop</tt> operations, differs from
|
|
the others in terms of its invalidation guarantees. Other design
|
|
decisions also impact the cost and placement of the overhead, at
|
|
the expense of more difference in the the kinds of operations
|
|
that the underlying data structure can support. These
|
|
differences pose a challenge when creating a uniform interface
|
|
for priority queues.<p></p></li>
|
|
</ol>
|
|
</div>
|
|
</body>
|
|
</html>
|