所有权和有条件执行的代码 [英] Ownership and conditionally executed code

问题描述

我在周末阅读了 rust book 并且我有一个关于所有权.我得到的印象是所有权用于静态地确定可以在哪里释放资源.现在，假设我们有以下内容:

I read the rust book over the weekend and I have a question about the concept of ownership. The impression I got is that ownership is used to statically determine where a resource can be deallocated. Now, suppose that we have the following:

{                                                 // 1
    let x;                                        // 2
    {                                             // 3
        let y = Box::new(1);                      // 4
        x = if flip_coin() {y} else {Box::new(2)} // 5
    }                                             // 6
}                                                 // 7

我很惊讶地看到编译器接受了这个程序.通过插入 println!s 并为装箱值实现 Drop trait，我看到包含值 1 的框将在第 6 行或第 7 行被释放，具体取决于flip_coin 的返回值.编译器如何知道何时释放那个盒子?这是在运行时使用一些运行时信息(例如指示框是否仍在使用的标志)来决定的吗?

I was surprised to see that the compiler accepts this program. By inserting println!s and implementing the Drop trait for the boxed value, I saw that the box containing the value 1 will be deallocated at either line 6 or 7 depending on the return value of flip_coin. How does the compiler know when to deallocate that box? Is this decided at run-time using some run-time information (like a flag to indicate if the box is still in use)?

推荐答案

经过一些研究我发现 Rust 目前 为实现 Drop 特性的每个类型添加一个标志，因此它知道该值是否已被删除，这当然会产生运行时成本.已经有人提议通过使用 static drop 或 热切滴 但这些解决方案在语义上存在问题，即滴落可能发生在你不会的地方't 期望(例如在代码块的中间)，特别是如果您习惯于 C++ 风格的 RAII.现在一致认为最好的妥协是 不同的解决方案，其中从类型中删除标志.相反，标志将添加到堆栈中，但仅当编译器无法确定何时静态执行 drop 时(同时具有与 C++ 相同的语义)，这特别发生在有条件移动时，例如示例在这个问题中给出.对于所有其他情况，将没有运行时成本.不过，这个提议似乎不会在 1.0 中及时实施.

After some research I found out that Rust currently adds a flag to every type that implements the Drop trait so that it knows whether the value has been dropped or not, which of course incurs a run-time cost. There have been proposals to avoid that cost by using static drops or eager drops but those solutions had problems with their semantics, namely that drops could occur at places that you wouldn't expect (e.g. in the middle of a code block), especially if you are used to C++ style RAII. There is now consensus that the best compromise is a different solution where the flags are removed from the types. Instead flags will be added to the stack, but only when the compiler cannot figure out when to do the drop statically (while having the same semantics as C++) which specifically happens when there are conditional moves like the example given in this question. For all other cases there will be no run-time cost. It appears though, that this proposal will not be implemented in time for 1.0.

请注意，C++ 具有与 unique_ptr 相关的类似运行时成本.当新的 Drop 实现时，Rust 在这方面将严格优于 C++.

Note that C++ has similar run-time costs associated with unique_ptr. When the new Drop is implemented, Rust will be strictly better than C++ in that respect.

我希望这是对情况的正确总结.归功于 u/dyoll1013、u/pcwalton、u/!!kibwen、u/Kimundi 在 reddit 和 Chris Morgan 在 SO 上.

I hope this is a correct summary of the situation. Credit goes to u/dyoll1013, u/pcwalton, u/!!kibwen, u/Kimundi on reddit, and Chris Morgan here on SO.

这篇关于所有权和有条件执行的代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！