*: Regenerate.
[gcc.git] / libstdc++-v3 / doc / html / manual / containers_and_c.html
1 <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Interacting with C</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"><meta name="keywords" content="
2 ISO C++
3 ,
4 library
5 "><meta name="keywords" content="
6 ISO C++
7 ,
8 runtime
9 ,
10 library
11 "><link rel="home" href="../index.html" title="The GNU C++ Library"><link rel="up" href="containers.html" title="Chapter 9.  Containers"><link rel="prev" href="associative.html" title="Associative"><link rel="next" href="iterators.html" title="Chapter 10.  Iterators"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="associative.html">Prev</a> </td><th width="60%" align="center">Chapter 9
12 Containers
13
14 </th><td width="20%" align="right"> <a accesskey="n" href="iterators.html">Next</a></td></tr></table><hr></div><div class="section" title="Interacting with C"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="std.containers.c"></a>Interacting with C</h2></div></div></div><div class="section" title="Containers vs. Arrays"><div class="titlepage"><div><div><h3 class="title"><a name="containers.c.vs_array"></a>Containers vs. Arrays</h3></div></div></div><p>
15 You're writing some code and can't decide whether to use builtin
16 arrays or some kind of container. There are compelling reasons
17 to use one of the container classes, but you're afraid that
18 you'll eventually run into difficulties, change everything back
19 to arrays, and then have to change all the code that uses those
20 data types to keep up with the change.
21 </p><p>
22 If your code makes use of the standard algorithms, this isn't as
23 scary as it sounds. The algorithms don't know, nor care, about
24 the kind of <span class="quote"><span class="quote">container</span></span> on which they work, since
25 the algorithms are only given endpoints to work with. For the
26 container classes, these are iterators (usually
27 <code class="code">begin()</code> and <code class="code">end()</code>, but not always).
28 For builtin arrays, these are the address of the first element
29 and the <a class="link" href="iterators.html#iterators.predefined.end" title="One Past the End">past-the-end</a> element.
30 </p><p>
31 Some very simple wrapper functions can hide all of that from the
32 rest of the code. For example, a pair of functions called
33 <code class="code">beginof</code> can be written, one that takes an array,
34 another that takes a vector. The first returns a pointer to the
35 first element, and the second returns the vector's
36 <code class="code">begin()</code> iterator.
37 </p><p>
38 The functions should be made template functions, and should also
39 be declared inline. As pointed out in the comments in the code
40 below, this can lead to <code class="code">beginof</code> being optimized out
41 of existence, so you pay absolutely nothing in terms of increased
42 code size or execution time.
43 </p><p>
44 The result is that if all your algorithm calls look like
45 </p><pre class="programlisting">
46 std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);
47 </pre><p>
48 then the type of foo can change from an array of ints to a vector
49 of ints to a deque of ints and back again, without ever changing
50 any client code.
51 </p><pre class="programlisting">
52 // beginof
53 template&lt;typename T&gt;
54 inline typename vector&lt;T&gt;::iterator
55 beginof(vector&lt;T&gt; &amp;v)
56 { return v.begin(); }
57
58 template&lt;typename T, unsigned int sz&gt;
59 inline T*
60 beginof(T (&amp;array)[sz]) { return array; }
61
62 // endof
63 template&lt;typename T&gt;
64 inline typename vector&lt;T&gt;::iterator
65 endof(vector&lt;T&gt; &amp;v)
66 { return v.end(); }
67
68 template&lt;typename T, unsigned int sz&gt;
69 inline T*
70 endof(T (&amp;array)[sz]) { return array + sz; }
71
72 // lengthof
73 template&lt;typename T&gt;
74 inline typename vector&lt;T&gt;::size_type
75 lengthof(vector&lt;T&gt; &amp;v)
76 { return v.size(); }
77
78 template&lt;typename T, unsigned int sz&gt;
79 inline unsigned int
80 lengthof(T (&amp;)[sz]) { return sz; }
81 </pre><p>
82 Astute readers will notice two things at once: first, that the
83 container class is still a <code class="code">vector&lt;T&gt;</code> instead
84 of a more general <code class="code">Container&lt;T&gt;</code>. This would
85 mean that three functions for <code class="code">deque</code> would have to be
86 added, another three for <code class="code">list</code>, and so on. This is
87 due to problems with getting template resolution correct; I find
88 it easier just to give the extra three lines and avoid confusion.
89 </p><p>
90 Second, the line
91 </p><pre class="programlisting">
92 inline unsigned int lengthof (T (&amp;)[sz]) { return sz; }
93 </pre><p>
94 looks just weird! Hint: unused parameters can be left nameless.
95 </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="associative.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="iterators.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Associative </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 10
96 Iterators
97
98 </td></tr></table></div></body></html>