gpt4 book ai didi

rust - 在 Rust 中,Box :ed struct compared to a plain struct? 的放置顺序是否存在差异

转载 作者:行者123 更新时间:2023-12-03 07:50:01 26 4
gpt4 key购买 nike

以下代码无法编译:

struct Ref<'a> {
nbr: &'a u32,
}

fn func<'a>() {
let nbr: u32 = 42;
let _a_ref: Box<Ref<'a>> = Box::new(Ref { nbr: &nbr });
}

fn main() {
func();
}

编译器提示 'nbr' 的生存时间不够长,并且它在 func() 末尾被删除,同时仍然是借用的。我基本上到处都搜索过,但我不明白为什么会出现这个错误。与声明相比,变量应该以相反的顺序删除,因此包含引用的装箱 Ref 应该在删除 nbr 之前删除,对吗?

如果我将 func() 更改为:

fn func<'a>() {
let nbr: u32 = 42;
let _a_ref = Ref { nbr: &nbr };
}

它构建得很好!因此,盒装引用所需的生命周期/范围存在一些差异 - 但我找不到对这个明显基本问题的任何清晰而简单的解释。

为了让它更加困惑,我注意到如果我像这样声明 _a_ref 的类型:

fn func<'a>() {
let nbr: u32 = 42;
let _a_ref: Ref<'a> = Ref { nbr: &nbr };
}

我再次收到“nbr”生命周期不够长错误。

最后,我使用了下划线,如下所示:

fn func<'a>() {
let nbr: u32 = 42;
let _a_ref: Ref<'_> = Ref { nbr: &nbr };
}

现在它又恢复正常了!这 3 种使用非装箱 Ref 结构的方法有什么区别?它们与盒装版本相比如何?

最佳答案

Box不是这里的问题,'a是。

&nbr生命周期为nbr 。但是'a是调用者选择的生命周期,它可能(甚至总是)大于 nbr 的生命周期。所以你不能分配 Ref<'nbr>Ref<'a> .

Ref<'_>意思是“让编译器推断生命周期”,基本上相当于根本不指定类型。

关于rust - 在 Rust 中,Box :ed struct compared to a plain struct? 的放置顺序是否存在差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/77459294/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com