为什么我不能在同一个结构体中存储一个值和对该值的引用?

引起类似编译器消息的一个稍微不同的问题是对象生命周期依赖，而不是存储显式引用。ssh2库就是一个例子。当开发比测试项目更大的项目时，尝试将从会话中获得的Session和Channel放在一个结构体中，对用户隐藏实现细节是很有吸引力的。然而，请注意，Channel定义的类型注释中有'sess生命期，而Session没有。

这将导致与生命周期相关的类似编译器错误。

一种非常简单的解决方法是在调用者外部声明Session，然后用生命周期注释结构内的引用，类似于这个Rust用户论坛帖子在封装SFTP时讨论相同问题的答案。这看起来并不优雅，可能并不总是适用-因为现在您有两个实体要处理，而不是您想要的一个!

use ssh2::{Channel, Error, Session};
use std::net::TcpStream;


use owning_ref::OwningHandle;


struct DeviceSSHConnection {
tcp: TcpStream,
channel: OwningHandle<Box<Session>, Box<Channel<'static>>>,
}


impl DeviceSSHConnection {
fn new(targ: &str, c_user: &str, c_pass: &str) -> Self {
use std::net::TcpStream;
let mut session = Session::new().unwrap();
let mut tcp = TcpStream::connect(targ).unwrap();


session.handshake(&tcp).unwrap();
session.set_timeout(5000);
session.userauth_password(c_user, c_pass).unwrap();


let mut sess = Box::new(session);
let mut oref = OwningHandle::new_with_fn(
sess,
unsafe { |x| Box::new((*x).channel_session().unwrap()) },
);


oref.shell().unwrap();
let ret = DeviceSSHConnection {
tcp: tcp,
channel: oref,
};
ret
}
}

这段代码的结果是，我们不能再使用Session，但它与我们将使用的Channel一起存储。因为OwningHandle对象在将其存储在结构体中时解引用了Box，而Box解引用了Channel，所以我们这样命名它。这只是我的理解。我怀疑这可能是不正确的，因为它似乎非常接近OwningHandle不安全性的讨论。

这里一个奇怪的细节是，Session在逻辑上与TcpStream有类似的关系，因为Channel必须与Session有类似的关系，但它的所有权没有被占用，并且没有类型注释。相反，这是由用户来处理的，正如握手方法的文档所述:

这个会话不拥有所提供的套接字，它是 建议确保套接字在此生命周期内持续存在

.会话，确保通信正常进行

还强烈建议不使用所提供的流 在本届会议期间，视情况同时在其他地方 干扰协议

因此，对于TcpStream的使用，完全由程序员来确保代码的正确性。对于OwningHandle，使用unsafe {}块绘制“危险魔法”发生的位置。

这个问题的进一步和更高级的讨论在Rust用户论坛线程中-其中包括一个不同的例子和它的解决方案使用租赁板条箱，其中不包含不安全的块。

我发现Arc(只读)或Arc<Mutex>(带锁的读写)模式有时是性能和代码复杂性之间非常有用的权衡(主要是由生命期注释引起的)。

弧:

use std::sync::Arc;


struct Parent {
child: Arc<Child>,
}
struct Child {
value: u32,
}
struct Combined(Parent, Arc<Child>);


fn main() {
let parent = Parent { child: Arc::new(Child { value: 42 }) };
let child = parent.child.clone();
let combined = Combined(parent, child.clone());


assert_eq!(combined.0.child.value, 42);
assert_eq!(child.value, 42);
// combined.0.child.value = 50; // fails, Arc is not DerefMut
}

Arc + Mutex:

use std::sync::{Arc, Mutex};


struct Child {
value: u32,
}
struct Parent {
child: Arc<Mutex<Child>>,
}
struct Combined(Parent, Arc<Mutex<Child>>);


fn main() {
let parent = Parent { child: Arc::new(Mutex::new(Child {value: 42 }))};
let child = parent.child.clone();
let combined = Combined(parent, child.clone());


assert_eq!(combined.0.child.lock().unwrap().value, 42);
assert_eq!(child.lock().unwrap().value, 42);
child.lock().unwrap().value = 50;
assert_eq!(combined.0.child.lock().unwrap().value, 50);
}

参见RwLock (什么时候或者为什么我应该使用互斥锁而不是RwLock?)

作为Rust的新手，我有一个类似于你上一个例子的情况:

struct Combined<'a>(Parent, Child<'a>);


fn make_combined<'a>() -> Combined<'a> {
let parent = Parent::new();
let child = parent.child();


Combined(parent, child)
}

最后，我用这个模式解决了这个问题:

fn make_parent_and_child<'a>(anchor: &'a mut DataAnchorFor1<Parent>) -> Child<'a> {
// construct parent, then store it in anchor object the caller gave us a mut-ref to
*anchor = DataAnchorFor1::holding(Parent::new());


// now retrieve parent from storage-slot we assigned to in the previous line
let parent = anchor.val1.as_mut().unwrap();


// now proceed with regular code, except returning only the child
// (the parent can already be accessed by the caller through the anchor object)
let child = parent.child();
child
}


// this is a generic struct that we can define once, and use whenever we need this pattern
// (it can also be extended to have multiple slots, naturally)
struct DataAnchorFor1<T> {
val1: Option<T>,
}
impl<T> DataAnchorFor1<T> {
fn empty() -> Self {
Self { val1: None }
}
fn holding(val1: T) -> Self {
Self { val1: Some(val1) }
}
}


// for my case, this was all I needed
fn main_simple() {
let anchor = DataAnchorFor1::empty();
let child = make_parent_and_child(&mut anchor);
let child_processing_result = do_some_processing(child);
println!("ChildProcessingResult:{}", child_processing_result);
}


// but if access to parent-data later on is required, you can use this
fn main_complex() {
let anchor = DataAnchorFor1::empty();
    

// if you want to use the parent object (which is stored in anchor), you must...
// ...wrap the child-related processing in a new scope, so the mut-ref to anchor...
// ...gets dropped at its end, letting us access anchor.val1 (the parent) directly
let child_processing_result = {
let child = make_parent_and_child(&mut anchor);
// do the processing you want with the child here (avoiding ref-chain...
// ...back to anchor-data, if you need to access parent-data afterward)
do_some_processing(child)
};


// now that scope is ended, we can access parent data directly
// so print out the relevant data for both parent and child (adjust to your case)
let parent = anchor.val1.unwrap();
println!("Parent:{} ChildProcessingResult:{}", parent, child_processing_result);
}

这远远不是一个普遍的解决方案!但它在我的情况下是有效的，并且只需要使用上面的main_simple模式(而不是main_complex变体)，因为在我的情况下，"parent"对象只是一些临时的东西(一个数据库"客户端"对象)，我必须构建，以传递给“孩子”;对象(数据库"事务"所以我可以运行一些数据库命令。

无论如何，它完成了我所需要的封装/简化样板文件(因为我有许多需要创建Transaction/“;child”的函数;对象，现在他们所需要的只是通用的锚对象创建行)，同时避免了使用整个新库的需要。

以下是我所知道的可能相关的库:

• own -ref
• 出租 .
• 衔尾蛇
• 引用
• self_cell
• escher
• rust-viewbox

然而，我浏览了它们，它们似乎都有这样或那样的问题(多年未更新，有多个不健全的问题/担忧，等等)，所以我犹豫是否使用它们。

因此，虽然这不是一个通用的解决方案，但我想我应该为具有类似用例的人提到它:

• 调用者只需要"child"对象返回。
• 但是被调用的函数需要构造一个&;parent&;对象来执行其功能。
• 而借款规则要求“父母”;对象被存储在“make_parent_and_child"函数。(在我的例子中，这是一个start_transaction函数)