about summary refs log tree commit diff
path: root/src/libstd
diff options
context:
space:
mode:
authorGeorg Brandl <georg@python.org>2015-08-25 18:20:34 +0200
committerGeorg Brandl <georg@python.org>2015-08-25 18:20:42 +0200
commitfc7c0f99d7cb5616230f7a61e86bcb4fc01dab5e (patch)
tree3674657c7af5feec8f0e211e929050c4a1913eef /src/libstd
parent1806174ab430583fe09df508ddf426bea9f4a3e1 (diff)
downloadrust-fc7c0f99d7cb5616230f7a61e86bcb4fc01dab5e.tar.gz
rust-fc7c0f99d7cb5616230f7a61e86bcb4fc01dab5e.zip
collections doc: remove mention of BitVec, BitSet, VecMap
These have been removed and should not be documented here.
Diffstat (limited to 'src/libstd')
-rw-r--r--src/libstd/collections/mod.rs34
1 files changed, 6 insertions, 28 deletions
diff --git a/src/libstd/collections/mod.rs b/src/libstd/collections/mod.rs
index 4367dda8466..83e28e39a72 100644
--- a/src/libstd/collections/mod.rs
+++ b/src/libstd/collections/mod.rs
@@ -25,9 +25,9 @@
 //!
 //! Rust's collections can be grouped into four major categories:
 //!
-//! * Sequences: `Vec`, `VecDeque`, `LinkedList`, `BitVec`
-//! * Maps: `HashMap`, `BTreeMap`, `VecMap`
-//! * Sets: `HashSet`, `BTreeSet`, `BitSet`
+//! * Sequences: `Vec`, `VecDeque`, `LinkedList`
+//! * Maps: `HashMap`, `BTreeMap`
+//! * Sets: `HashSet`, `BTreeSet`
 //! * Misc: `BinaryHeap`
 //!
 //! # When Should You Use Which Collection?
@@ -70,22 +70,11 @@
 //! * You want to be able to get all of the entries in order on-demand.
 //! * You want a sorted map.
 //!
-//! ### Use a `VecMap` when:
-//! * You want a `HashMap` but with known to be small `usize` keys.
-//! * You want a `BTreeMap`, but with known to be small `usize` keys.
-//!
 //! ### Use the `Set` variant of any of these `Map`s when:
 //! * You just want to remember which keys you've seen.
 //! * There is no meaningful value to associate with your keys.
 //! * You just want a set.
 //!
-//! ### Use a `BitVec` when:
-//! * You want to store an unbounded number of booleans in a small space.
-//! * You want a bit vector.
-//!
-//! ### Use a `BitSet` when:
-//! * You want a `BitVec`, but want `Set` properties
-//!
 //! ### Use a `BinaryHeap` when:
 //!
 //! * You want to store a bunch of elements, but only ever want to process the
@@ -123,31 +112,20 @@
 //! | Vec          | O(1)           | O(n-i)*         | O(n-i)         | O(m)*  | O(n-i)         |
 //! | VecDeque     | O(1)           | O(min(i, n-i))* | O(min(i, n-i)) | O(m)*  | O(min(i, n-i)) |
 //! | LinkedList   | O(min(i, n-i)) | O(min(i, n-i))  | O(min(i, n-i)) | O(1)   | O(min(i, n-i)) |
-//! | BitVec       | O(1)           | O(n-i)*         | O(n-i)         | O(m)*  | O(n-i)         |
 //!
 //! Note that where ties occur, Vec is generally going to be faster than VecDeque, and VecDeque
-//! is generally going to be faster than LinkedList. BitVec is not a general purpose collection, and
-//! therefore cannot reasonably be compared.
+//! is generally going to be faster than LinkedList.
 //!
 //! ## Maps
 //!
-//! For Sets, all operations have the cost of the equivalent Map operation. For
-//! BitSet,
-//! refer to VecMap.
+//! For Sets, all operations have the cost of the equivalent Map operation.
 //!
 //! |          | get       | insert   | remove   | predecessor |
 //! |----------|-----------|----------|----------|-------------|
 //! | HashMap  | O(1)~     | O(1)~*   | O(1)~    | N/A         |
 //! | BTreeMap | O(log n)  | O(log n) | O(log n) | O(log n)    |
-//! | VecMap   | O(1)      | O(1)?    | O(1)     | O(n)        |
-//!
-//! Note that VecMap is *incredibly* inefficient in terms of space. The O(1)
-//! insertion time assumes space for the element is already allocated.
-//! Otherwise, a large key may require a massive reallocation, with no direct
-//! relation to the number of elements in the collection.  VecMap should only be
-//! seriously considered for small keys.
 //!
-//! Note also that BTreeMap's precise performance depends on the value of B.
+//! Note that BTreeMap's precise performance depends on the value of B.
 //!
 //! # Correct and Efficient Usage of Collections
 //!