+ iterator find(StringRef Key); +
and clients can call it using any one of:
-
+
Map.find("foo"); // Lookup "foo"
Map.find(std::string("bar")); // Lookup "bar"
Map.find(StringRef("\0baz", 4)); // Lookup "\0baz"
-Similarly, APIs which need to return a string may return a StringRef instance, which can be used directly or converted to an std::string @@ -499,7 +496,8 @@ for more information.
You should rarely use the StringRef 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).
+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. @@ -1211,14 +1209,14 @@ and erasing, but does not support iteration.SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is -transparently implemented with a SmallPtrSet), but also supports iterators. If +
SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is +transparently implemented with a SmallPtrSet), but also supports iterators. If more than 'N' insertions are performed, a single quadratically probed hash table is allocated and grows as needed, providing extremely efficient access (constant time insertion/deleting/queries with low constant factors) and is very stingy with malloc traffic.
-Note that, unlike std::set, the iterators of SmallPtrSet are invalidated +
Note that, unlike std::set, the iterators of SmallPtrSet are invalidated whenever an insertion occurs. Also, the values visited by the iterators are not visited in sorted order.
@@ -1437,7 +1435,7 @@ to the key string for a value.The StringMap is very fast for several reasons: quadratic probing is very
cache efficient for lookups, the hash value of strings in buckets is not
-recomputed when lookup up an element, StringMap rarely has to touch the
+recomputed when looking up an element, StringMap rarely has to touch the
memory for unrelated objects when looking up a value (even when hash collisions
happen), hash table growth does not recompute the hash values for strings
already in the table, and each pair in the map is store in a single allocation
@@ -1510,6 +1508,23 @@ a Config parameter to the ValueMap template.
IntervalMap is a compact map for small keys and values. It maps key +intervals instead of single keys, and it will automatically coalesce adjacent +intervals. When then map only contains a few intervals, they are stored in the +map object itself to avoid allocations.
+ +The IntervalMap iterators are quite big, so they should not be passed around +as STL iterators. The heavyweight iterators allow a smaller data structure.
+ +Unfortunately, these implicit conversions come at a cost; they prevent +these iterators from conforming to standard iterator conventions, and thus +from being usable with standard algorithms and containers. For example, they +prevent the following code, where B is a BasicBlock, +from compiling:
+ ++ llvm::SmallVector<llvm::Instruction *, 16>(B->begin(), B->end()); ++
Because of this, these implicit conversions may be removed some day, +and operator* changed to return a pointer instead of a reference.
+ @@ -1962,7 +1992,11 @@ for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i -Alternately, it's common to have an instance of the Note that dereferencing a Value::use_iterator is not a very cheap +operation. Instead of performing *i above several times, consider +doing it only once in the loop body and reusing its result.
+ +Alternatively, it's common to have an instance of the User Class and need to know what Values are used by it. The list of all Values used by a User is known as a use-def chain. Instances of class @@ -1981,10 +2015,13 @@ for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) - +
Declaring objects as const is an important tool of enforcing +mutation free algorithms (such as analyses, etc.). For this purpose above +iterators come in constant flavors as Value::const_use_iterator +and Value::const_op_iterator. They automatically arise when +calling use/op_begin() on const Value*s or +const User*s respectively. Upon dereferencing, they return +const Use*s. Otherwise the above patterns remain unchanged.
@@ -3058,7 +3095,7 @@ the lib/VMCore directory.