may have embedded null characters. Therefore, they cannot simply take
a <tt>const char *</tt>, and taking a <tt>const std::string&</tt> requires
clients to perform a heap allocation which is usually unnecessary. Instead,
-many LLVM APIs use a <tt>const StringRef&</tt> or a <tt>const
-Twine&</tt> for passing strings efficiently.</p>
+many LLVM APIs use a <tt>StringRef</tt> or a <tt>const Twine&</tt> for
+passing strings efficiently.</p>
</div>
an <tt>std::string</tt>, or explicitly with a character pointer and length.
For example, the <tt>StringRef</tt> find function is declared as:</p>
-<div class="doc_code">
- iterator find(const StringRef &Key);
-</div>
+<pre class="doc_code">
+ iterator find(StringRef Key);
+</pre>
<p>and clients can call it using any one of:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
Map.find("foo"); <i>// Lookup "foo"</i>
Map.find(std::string("bar")); <i>// Lookup "bar"</i>
Map.find(StringRef("\0baz", 4)); <i>// Lookup "\0baz"</i>
</pre>
-</div>
<p>Similarly, APIs which need to return a string may return a <tt>StringRef</tt>
instance, which can be used directly or converted to an <tt>std::string</tt>
<p>You should rarely use the <tt>StringRef</tt> class directly, because it contains
pointers to external memory it is not generally safe to store an instance of the
-class (unless you know that the external storage will not be freed).</p>
+class (unless you know that the external storage will not be freed). StringRef is
+small and pervasive enough in LLVM that it should always be passed by value.</p>
</div>