迭代 BTreeMap 和 &BTreeMap 的区别

Question

我试图了解两者之间的区别

let rows = Vec::new();
for (k, v) in my_btree { // BTreeMap<i64, String>
    rows.push((&k, &v)) // k and v don't live long enough.
}

和：

let rows = Vec::new();
for (k, v) in &my_btree { // BTreeMap<i64, String>
    rows.push((k, v))
}

有人能解释一下迭代&my_btree和迭代my_btree之间的区别吗？

具体来说，我想了解所有权如何变化以及上述两个示例中引用了哪些内存

这是我正在尝试做的一个完整示例（target_function 是我正在使用的一个库，它具有与此处类似的函数签名，因此无法更改）：

use std::collections::BTreeMap;

struct SomeStruct {
    x: BTreeMap<i64, String>
}

fn target_function(rows: &[(&i64, &String)]) {
    for row in rows.iter() {
        println!("{:#?}", row);
    }    
}
fn test(ss: SomeStruct) {
    let mut rows = Vec::new();

    for (k, v) in &ss.x {
        rows.push((k, v));
    }
    target_function(&rows[..]);
}

fn main() {
    let mut a = BTreeMap::new();
    a.insert(1, "hello".to_string());
    a.insert(2, "goodbye".to_string());

    let mystruct = SomeStruct{x: a};
    test(mystruct);
}

Answer 1

其中的微妙之处在于 IntoIterator 对 BTreeMap 的双重实现（实际上是大多数集合）。你可以在documentation看到，按顺序：

• impl<K, V> IntoIterator for BTreeMap<K, V>

这是您的第一个案例。您正在做的是移动 BTreeMap 并使用它来生成 (K, V) 迭代器。您可以通过以下 sn-p 说服自己：

let mut my_btree:BTreeMap<i64, String> = BTreeMap::new();
my_tree.insert(3, "this is a test".to_string());
let mut rows = Vec::new();
for (k, v) in my_btree { // BTreeMap<i64, String>
    rows.push((k, v))
}

这会消耗my_btree 并一对一地产生(K, V) 对。由于这些对是拥有的，因此您可以安全地将它们推送到您提供的Vec。在您的 sn-p 中，您有 &k 和 &v - 这些引用永远不会起作用，因为这些项目会立即从范围中删除。

• impl<'a, K, V> IntoIterator for &'a BTreeMap<K, V>

这是您的第二个案例。在这种情况下，您的迭代器现在是(&'a K, &'a V)，您可以通过尝试将Vec 移出BTreeMap 的范围来轻松说服自己，如下所示：

fn does_not_work<'a>() -> Vec<(&'a i64, &'a String)> {
    let my_btree:BTreeMap<i64, String> = BTreeMap::new();
    let mut rows = Vec::new();
    for (k, v) in &my_btree { // BTreeMap<i64, String>
        rows.push((k, v))
    }
    rows
}

这不会编译，因为您在 BTreeMap 中插入了一堆对元素的引用，然后您将其删除（由于它超出范围） - 如果借用检查器没有，所有这些引用都将无效来救援。

所以，这就是区别 - 在一种情况下，您使用 BTreeMap 对拥有的结构进行操作，而在另一种情况下，您正在处理引用。

因此，您的示例函数 - 由于 &ss.x 迭代器从不消耗地图，您实际上从未取消引用地图。