2013-06-27 17:48:12 -05:00
|
|
|
% Containers and iterators
|
|
|
|
|
|
|
|
# Containers
|
|
|
|
|
|
|
|
The container traits are defined in the `std::container` module.
|
|
|
|
|
2013-09-18 21:26:48 -05:00
|
|
|
## Unique vectors
|
2013-06-27 17:48:12 -05:00
|
|
|
|
2013-09-18 21:26:48 -05:00
|
|
|
Vectors have `O(1)` indexing, push (to the end) and pop (from the end). Vectors
|
|
|
|
are the most common container in Rust, and are flexible enough to fit many use
|
|
|
|
cases.
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
Vectors can also be sorted and used as efficient lookup tables with the
|
2013-09-18 22:06:03 -05:00
|
|
|
`bsearch()` method, if all the elements are inserted at one time and
|
2013-06-27 17:48:12 -05:00
|
|
|
deletions are unnecessary.
|
|
|
|
|
|
|
|
## Maps and sets
|
|
|
|
|
|
|
|
Maps are collections of unique keys with corresponding values, and sets are
|
|
|
|
just unique keys without a corresponding value. The `Map` and `Set` traits in
|
|
|
|
`std::container` define the basic interface.
|
|
|
|
|
|
|
|
The standard library provides three owned map/set types:
|
|
|
|
|
|
|
|
* `std::hashmap::HashMap` and `std::hashmap::HashSet`, requiring the keys to
|
|
|
|
implement `Eq` and `Hash`
|
|
|
|
* `std::trie::TrieMap` and `std::trie::TrieSet`, requiring the keys to be `uint`
|
|
|
|
* `extra::treemap::TreeMap` and `extra::treemap::TreeSet`, requiring the keys
|
|
|
|
to implement `TotalOrd`
|
|
|
|
|
|
|
|
These maps do not use managed pointers so they can be sent between tasks as
|
|
|
|
long as the key and value types are sendable. Neither the key or value type has
|
|
|
|
to be copyable.
|
|
|
|
|
|
|
|
The `TrieMap` and `TreeMap` maps are ordered, while `HashMap` uses an arbitrary
|
|
|
|
order.
|
|
|
|
|
|
|
|
Each `HashMap` instance has a random 128-bit key to use with a keyed hash,
|
|
|
|
making the order of a set of keys in a given hash table randomized. Rust
|
|
|
|
provides a [SipHash](https://131002.net/siphash/) implementation for any type
|
|
|
|
implementing the `IterBytes` trait.
|
|
|
|
|
|
|
|
## Double-ended queues
|
|
|
|
|
2013-09-18 22:06:03 -05:00
|
|
|
The `extra::ringbuf` module implements a double-ended queue with `O(1)`
|
|
|
|
amortized inserts and removals from both ends of the container. It also has
|
|
|
|
`O(1)` indexing like a vector. The contained elements are not required to be
|
|
|
|
copyable, and the queue will be sendable if the contained type is sendable.
|
|
|
|
Its interface `Deque` is defined in `extra::collections`.
|
|
|
|
|
|
|
|
The `extra::dlist` module implements a double-ended linked list, also
|
|
|
|
implementing the `Deque` trait, with `O(1)` removals and inserts at either end,
|
|
|
|
and `O(1)` concatenation.
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
## Priority queues
|
|
|
|
|
|
|
|
The `extra::priority_queue` module implements a queue ordered by a key. The
|
|
|
|
contained elements are not required to be copyable, and the queue will be
|
|
|
|
sendable if the contained type is sendable.
|
|
|
|
|
|
|
|
Insertions have `O(log n)` time complexity and checking or popping the largest
|
|
|
|
element is `O(1)`. Converting a vector to a priority queue can be done
|
|
|
|
in-place, and has `O(n)` complexity. A priority queue can also be converted to
|
|
|
|
a sorted vector in-place, allowing it to be used for an `O(n log n)` in-place
|
|
|
|
heapsort.
|
|
|
|
|
|
|
|
# Iterators
|
|
|
|
|
|
|
|
## Iteration protocol
|
|
|
|
|
|
|
|
The iteration protocol is defined by the `Iterator` trait in the
|
|
|
|
`std::iterator` module. The minimal implementation of the trait is a `next`
|
|
|
|
method, yielding the next element from an iterator object:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
/// An infinite stream of zeroes
|
|
|
|
struct ZeroStream;
|
|
|
|
|
|
|
|
impl Iterator<int> for ZeroStream {
|
|
|
|
fn next(&mut self) -> Option<int> {
|
|
|
|
Some(0)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
~~~~
|
|
|
|
|
|
|
|
Reaching the end of the iterator is signalled by returning `None` instead of
|
|
|
|
`Some(item)`:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
/// A stream of N zeroes
|
|
|
|
struct ZeroStream {
|
|
|
|
priv remaining: uint
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ZeroStream {
|
|
|
|
fn new(n: uint) -> ZeroStream {
|
|
|
|
ZeroStream { remaining: n }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Iterator<int> for ZeroStream {
|
|
|
|
fn next(&mut self) -> Option<int> {
|
|
|
|
if self.remaining == 0 {
|
|
|
|
None
|
|
|
|
} else {
|
|
|
|
self.remaining -= 1;
|
|
|
|
Some(0)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
~~~
|
|
|
|
|
2013-08-03 15:51:49 -05:00
|
|
|
In general, you cannot rely on the behavior of the `next()` method after it has
|
|
|
|
returned `None`. Some iterators may return `None` forever. Others may behave
|
|
|
|
differently.
|
|
|
|
|
2013-06-27 17:48:12 -05:00
|
|
|
## Container iterators
|
|
|
|
|
|
|
|
Containers implement iteration over the contained elements by returning an
|
2013-07-24 17:36:23 -05:00
|
|
|
iterator object. For example, vector slices several iterators available:
|
2013-06-27 17:48:12 -05:00
|
|
|
|
2013-07-24 17:36:23 -05:00
|
|
|
* `iter()` and `rev_iter()`, for immutable references to the elements
|
|
|
|
* `mut_iter()` and `mut_rev_iter()`, for mutable references to the elements
|
2013-08-03 15:51:49 -05:00
|
|
|
* `move_iter()` and `move_rev_iter()`, to move the elements out by-value
|
2013-07-24 17:36:23 -05:00
|
|
|
|
|
|
|
A typical mutable container will implement at least `iter()`, `mut_iter()` and
|
2013-08-12 23:37:50 -05:00
|
|
|
`move_iter()` along with the reverse variants if it maintains an order.
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
### Freezing
|
|
|
|
|
|
|
|
Unlike most other languages with external iterators, Rust has no *iterator
|
|
|
|
invalidation*. As long an iterator is still in scope, the compiler will prevent
|
|
|
|
modification of the container through another handle.
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let mut xs = [1, 2, 3];
|
|
|
|
{
|
|
|
|
let _it = xs.iter();
|
|
|
|
|
|
|
|
// the vector is frozen for this scope, the compiler will statically
|
|
|
|
// prevent modification
|
|
|
|
}
|
|
|
|
// the vector becomes unfrozen again at the end of the scope
|
|
|
|
~~~
|
|
|
|
|
|
|
|
These semantics are due to most container iterators being implemented with `&`
|
|
|
|
and `&mut`.
|
|
|
|
|
|
|
|
## Iterator adaptors
|
|
|
|
|
2013-08-12 23:37:50 -05:00
|
|
|
The `Iterator` trait provides many common algorithms as default methods. For
|
|
|
|
example, the `fold` method will accumulate the items yielded by an `Iterator`
|
|
|
|
into a single value:
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1, 9, 2, 3, 14, 12];
|
|
|
|
let result = xs.iter().fold(0, |accumulator, item| accumulator - *item);
|
|
|
|
assert_eq!(result, -41);
|
|
|
|
~~~
|
|
|
|
|
2013-08-03 15:51:49 -05:00
|
|
|
Most adaptors return an adaptor object implementing the `Iterator` trait itself:
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1, 9, 2, 3, 14, 12];
|
|
|
|
let ys = [5, 2, 1, 8];
|
2013-08-12 23:37:50 -05:00
|
|
|
let sum = xs.iter().chain(ys.iter()).fold(0, |a, b| a + *b);
|
2013-06-27 17:48:12 -05:00
|
|
|
assert_eq!(sum, 57);
|
|
|
|
~~~
|
|
|
|
|
2013-08-03 15:51:49 -05:00
|
|
|
Some iterator adaptors may return `None` before exhausting the underlying
|
|
|
|
iterator. Additionally, if these iterator adaptors are called again after
|
|
|
|
returning `None`, they may call their underlying iterator again even if the
|
|
|
|
adaptor will continue to return `None` forever. This may not be desired if the
|
|
|
|
underlying iterator has side-effects.
|
|
|
|
|
|
|
|
In order to provide a guarantee about behavior once `None` has been returned, an
|
|
|
|
iterator adaptor named `fuse()` is provided. This returns an iterator that will
|
|
|
|
never call its underlying iterator again once `None` has been returned:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1,2,3,4,5];
|
|
|
|
let mut calls = 0;
|
|
|
|
let it = xs.iter().scan((), |_, x| {
|
|
|
|
calls += 1;
|
|
|
|
if *x < 3 { Some(x) } else { None }});
|
|
|
|
// the iterator will only yield 1 and 2 before returning None
|
|
|
|
// If we were to call it 5 times, calls would end up as 5, despite only 2 values
|
|
|
|
// being yielded (and therefore 3 unique calls being made). The fuse() adaptor
|
|
|
|
// can fix this.
|
|
|
|
let mut it = it.fuse();
|
|
|
|
it.next();
|
|
|
|
it.next();
|
|
|
|
it.next();
|
|
|
|
it.next();
|
|
|
|
it.next();
|
|
|
|
assert_eq!(calls, 3);
|
|
|
|
~~~
|
|
|
|
|
2013-06-27 17:48:12 -05:00
|
|
|
## For loops
|
|
|
|
|
2013-08-22 08:23:23 -05:00
|
|
|
The function `range` (or `range_inclusive`) allows to simply iterate through a given range:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
for i in range(0, 5) {
|
2013-09-18 22:06:03 -05:00
|
|
|
print!("{} ", i) // prints "0 1 2 3 4"
|
2013-08-22 08:23:23 -05:00
|
|
|
}
|
|
|
|
|
2013-09-08 10:01:16 -05:00
|
|
|
for i in std::iter::range_inclusive(0, 5) { // needs explicit import
|
2013-09-18 22:06:03 -05:00
|
|
|
print!("{} ", i) // prints "0 1 2 3 4 5"
|
2013-08-22 08:23:23 -05:00
|
|
|
}
|
|
|
|
~~~
|
|
|
|
|
2013-08-02 22:20:22 -05:00
|
|
|
The `for` keyword can be used as sugar for iterating through any iterator:
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
~~~
|
2013-08-19 17:15:01 -05:00
|
|
|
let xs = [2u, 3, 5, 7, 11, 13, 17];
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
// print out all the elements in the vector
|
2013-08-02 22:20:22 -05:00
|
|
|
for x in xs.iter() {
|
2013-06-27 17:48:12 -05:00
|
|
|
println(x.to_str())
|
|
|
|
}
|
|
|
|
|
|
|
|
// print out all but the first 3 elements in the vector
|
2013-08-02 22:20:22 -05:00
|
|
|
for x in xs.iter().skip(3) {
|
2013-06-27 17:48:12 -05:00
|
|
|
println(x.to_str())
|
|
|
|
}
|
|
|
|
~~~
|
|
|
|
|
|
|
|
For loops are *often* used with a temporary iterator object, as above. They can
|
|
|
|
also advance the state of an iterator in a mutable location:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1, 2, 3, 4, 5];
|
|
|
|
let ys = ["foo", "bar", "baz", "foobar"];
|
|
|
|
|
|
|
|
// create an iterator yielding tuples of elements from both vectors
|
|
|
|
let mut it = xs.iter().zip(ys.iter());
|
|
|
|
|
|
|
|
// print out the pairs of elements up to (&3, &"baz")
|
2013-08-02 22:20:22 -05:00
|
|
|
for (x, y) in it {
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{} {}", *x, *y);
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
if *x == 3 {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// yield and print the last pair from the iterator
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("last: {:?}", it.next());
|
2013-06-27 17:48:12 -05:00
|
|
|
|
|
|
|
// the iterator is now fully consumed
|
|
|
|
assert!(it.next().is_none());
|
|
|
|
~~~
|
2013-07-11 20:10:59 -05:00
|
|
|
|
|
|
|
## Conversion
|
|
|
|
|
|
|
|
Iterators offer generic conversion to containers with the `collect` adaptor:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [0, 1, 1, 2, 3, 5, 8];
|
2013-08-12 23:37:50 -05:00
|
|
|
let ys = xs.rev_iter().skip(1).map(|&x| x * 2).collect::<~[int]>();
|
2013-07-11 20:10:59 -05:00
|
|
|
assert_eq!(ys, ~[10, 6, 4, 2, 2, 0]);
|
|
|
|
~~~
|
|
|
|
|
|
|
|
The method requires a type hint for the container type, if the surrounding code
|
|
|
|
does not provide sufficient information.
|
|
|
|
|
|
|
|
Containers can provide conversion from iterators through `collect` by
|
|
|
|
implementing the `FromIterator` trait. For example, the implementation for
|
|
|
|
vectors is as follows:
|
|
|
|
|
2013-08-19 17:15:01 -05:00
|
|
|
~~~ {.xfail-test}
|
std: Move the iterator param on FromIterator and Extendable to the method.
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
fn foo<E: Extendable<int, Range<int>> +
Extendable<int, Map<&'self int, int, VecIterator<int>>>
(e: &mut E, ...) { ... }
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
2013-08-13 08:08:14 -05:00
|
|
|
impl<A> FromIterator<A> for ~[A] {
|
|
|
|
pub fn from_iterator<T: Iterator<A>>(iterator: &mut T) -> ~[A] {
|
2013-07-11 20:10:59 -05:00
|
|
|
let (lower, _) = iterator.size_hint();
|
|
|
|
let mut xs = with_capacity(lower);
|
2013-08-02 22:20:22 -05:00
|
|
|
for x in iterator {
|
2013-07-11 20:10:59 -05:00
|
|
|
xs.push(x);
|
|
|
|
}
|
|
|
|
xs
|
|
|
|
}
|
|
|
|
}
|
|
|
|
~~~
|
|
|
|
|
|
|
|
### Size hints
|
|
|
|
|
|
|
|
The `Iterator` trait provides a `size_hint` default method, returning a lower
|
|
|
|
bound and optionally on upper bound on the length of the iterator:
|
|
|
|
|
2013-08-19 17:15:01 -05:00
|
|
|
~~~ {.xfail-test}
|
2013-07-11 20:10:59 -05:00
|
|
|
fn size_hint(&self) -> (uint, Option<uint>) { (0, None) }
|
|
|
|
~~~
|
|
|
|
|
|
|
|
The vector implementation of `FromIterator` from above uses the lower bound
|
|
|
|
to pre-allocate enough space to hold the minimum number of elements the
|
|
|
|
iterator will yield.
|
|
|
|
|
|
|
|
The default implementation is always correct, but it should be overridden if
|
|
|
|
the iterator can provide better information.
|
|
|
|
|
|
|
|
The `ZeroStream` from earlier can provide an exact lower and upper bound:
|
|
|
|
|
|
|
|
~~~
|
|
|
|
/// A stream of N zeroes
|
|
|
|
struct ZeroStream {
|
|
|
|
priv remaining: uint
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ZeroStream {
|
|
|
|
fn new(n: uint) -> ZeroStream {
|
|
|
|
ZeroStream { remaining: n }
|
|
|
|
}
|
|
|
|
|
|
|
|
fn size_hint(&self) -> (uint, Option<uint>) {
|
|
|
|
(self.remaining, Some(self.remaining))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Iterator<int> for ZeroStream {
|
|
|
|
fn next(&mut self) -> Option<int> {
|
|
|
|
if self.remaining == 0 {
|
|
|
|
None
|
|
|
|
} else {
|
|
|
|
self.remaining -= 1;
|
|
|
|
Some(0)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
~~~
|
|
|
|
|
|
|
|
## Double-ended iterators
|
|
|
|
|
|
|
|
The `DoubleEndedIterator` trait represents an iterator able to yield elements
|
|
|
|
from either end of a range. It inherits from the `Iterator` trait and extends
|
|
|
|
it with the `next_back` function.
|
|
|
|
|
|
|
|
A `DoubleEndedIterator` can be flipped with the `invert` adaptor, returning
|
|
|
|
another `DoubleEndedIterator` with `next` and `next_back` exchanged.
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1, 2, 3, 4, 5, 6];
|
|
|
|
let mut it = xs.iter();
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{:?}", it.next()); // prints `Some(&1)`
|
|
|
|
println!("{:?}", it.next()); // prints `Some(&2)`
|
|
|
|
println!("{:?}", it.next_back()); // prints `Some(&6)`
|
2013-07-11 20:10:59 -05:00
|
|
|
|
|
|
|
// prints `5`, `4` and `3`
|
2013-08-02 22:20:22 -05:00
|
|
|
for &x in it.invert() {
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{}", x)
|
2013-07-11 20:10:59 -05:00
|
|
|
}
|
|
|
|
~~~
|
|
|
|
|
|
|
|
The `rev_iter` and `mut_rev_iter` methods on vectors just return an inverted
|
|
|
|
version of the standard immutable and mutable vector iterators.
|
2013-07-23 13:37:06 -05:00
|
|
|
|
2013-08-12 23:37:50 -05:00
|
|
|
The `chain`, `map`, `filter`, `filter_map` and `inspect` adaptors are
|
2013-07-23 13:37:06 -05:00
|
|
|
`DoubleEndedIterator` implementations if the underlying iterators are.
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1, 2, 3, 4];
|
|
|
|
let ys = [5, 6, 7, 8];
|
2013-08-12 23:37:50 -05:00
|
|
|
let mut it = xs.iter().chain(ys.iter()).map(|&x| x * 2);
|
2013-07-23 13:37:06 -05:00
|
|
|
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{:?}", it.next()); // prints `Some(2)`
|
2013-07-23 13:37:06 -05:00
|
|
|
|
|
|
|
// prints `16`, `14`, `12`, `10`, `8`, `6`, `4`
|
2013-08-02 22:20:22 -05:00
|
|
|
for x in it.invert() {
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{}", x);
|
2013-07-23 13:37:06 -05:00
|
|
|
}
|
|
|
|
~~~
|
2013-07-23 16:14:32 -05:00
|
|
|
|
2013-08-19 16:52:20 -05:00
|
|
|
The `reverse_` method is also available for any double-ended iterator yielding
|
|
|
|
mutable references. It can be used to reverse a container in-place. Note that
|
|
|
|
the trailing underscore is a workaround for issue #5898 and will be removed.
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let mut ys = [1, 2, 3, 4, 5];
|
|
|
|
ys.mut_iter().reverse_();
|
|
|
|
assert_eq!(ys, [5, 4, 3, 2, 1]);
|
|
|
|
~~~
|
|
|
|
|
2013-07-23 16:14:32 -05:00
|
|
|
## Random-access iterators
|
|
|
|
|
|
|
|
The `RandomAccessIterator` trait represents an iterator offering random access
|
|
|
|
to the whole range. The `indexable` method retrieves the number of elements
|
|
|
|
accessible with the `idx` method.
|
|
|
|
|
2013-08-12 23:37:50 -05:00
|
|
|
The `chain` adaptor is an implementation of `RandomAccessIterator` if the
|
2013-07-23 16:14:32 -05:00
|
|
|
underlying iterators are.
|
|
|
|
|
|
|
|
~~~
|
|
|
|
let xs = [1, 2, 3, 4, 5];
|
|
|
|
let ys = ~[7, 9, 11];
|
2013-08-12 23:37:50 -05:00
|
|
|
let mut it = xs.iter().chain(ys.iter());
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{:?}", it.idx(0)); // prints `Some(&1)`
|
|
|
|
println!("{:?}", it.idx(5)); // prints `Some(&7)`
|
|
|
|
println!("{:?}", it.idx(7)); // prints `Some(&11)`
|
|
|
|
println!("{:?}", it.idx(8)); // prints `None`
|
2013-07-23 16:14:32 -05:00
|
|
|
|
|
|
|
// yield two elements from the beginning, and one from the end
|
|
|
|
it.next();
|
|
|
|
it.next();
|
|
|
|
it.next_back();
|
|
|
|
|
2013-09-18 22:06:03 -05:00
|
|
|
println!("{:?}", it.idx(0)); // prints `Some(&3)`
|
|
|
|
println!("{:?}", it.idx(4)); // prints `Some(&9)`
|
|
|
|
println!("{:?}", it.idx(6)); // prints `None`
|
2013-07-23 16:14:32 -05:00
|
|
|
~~~
|