gpt4 book ai didi

rust - 变量具有不同的生命周期,而它们本应具有相同的生命周期

转载 作者:行者123 更新时间:2023-11-29 07:55:28 28 4
gpt4 key购买 nike

为了学习 Rust,我正在写一个 library包装 JNI。我遇到了很多终身问题,并勇敢地与编译器抗争以解决它们,但是对于这个问题我只是放弃了。这就是问题所在。

现在,JNI 是 Java 虚拟机的接口(interface),因此每个 java 对象都必须绑定(bind)到 VM。为了做到这一点,我创建了“VM 指针”类型的 JavaVM,它主要只是指针的包装器和用于创建 JavaEnv 对象的接口(interface),它们只是 JNIEnv* 的包装器,也是更安全的接口(interface)的提供者大多数 JNI 方法。

为了声明 JavaEnv 对象绑定(bind)到 VM,我执行了以下操作:

pub struct JavaEnv<'a> {
phantom: PhantomData<&'a JavaVM>,
...
}

现在,如果我理解正确的话,所有 JavaEnv 对象都将在生命周期内绑定(bind)到某个 JavaVM 对象,并且不会超过它,这正是我想要的。

JavaEnv —— 是一个用于操作 Java 对象(和其他一些东西)的接口(interface)。现在,所有类型的 JNI 对象都实现了一个特征:

pub trait JObject<'a>: Drop {
fn get_env(&self) -> &'a JavaEnv<'a>;
...
}

他们自己都是这样的:

pub struct JavaObject<'a> {
env: &'a JavaEnv<'a>,
...
}

pub struct JavaClass<'a> {
env: &'a JavaEnv<'a>,
...
}

现在,如果我再次理解正确的话,所有 JavaObject-s 都将在生命周期内绑定(bind)到某个 JavaEnv 对象,而后者又绑定(bind)到 JavaVM 对象。

最后,Java 是默认引用语义的语言,所以对象比较只是浅层引用比较,我想在 Rust 接口(interface)中体现:

impl<'a, R: 'a + JObject<'a>> PartialEq<R> for JavaObject<'a> {
fn eq(&self, other: &R) -> bool {
self.get_env().is_same_object(self, other)
}
}

impl<'a, R: 'a + JObject<'a>> PartialEq<R> for JavaClass<'a> {
fn eq(&self, other: &R) -> bool {
self.get_env().is_same_object(self, other)
}
}

pub fn JavaEnv::is_same_object<T1: 'a + JObject<'a>, T2: 'a + JObject<'a>>(&self, obj1: &T1, obj2: &T2) -> bool {
unsafe {
((**self.ptr).IsSameObject)(self.ptr, obj1.get_obj(), obj2.get_obj()) == JNI_TRUE
}
}

这行不通。这是一个测试:

let (cls, cap) = JavaClass::find(&env, "java/lang/String", cap).unwrap();
let (obj /*of class java/lang/String*/, cap) = cls.alloc(cap).unwrap();
let cls1 /*also java/lang/String*/ = obj.get_class(&cap);
assert!(cls1 == cls);
let (sobj /*also of java/lang/String*/, cap) = JavaString::new(&env, "hi!", cap).unwrap();
assert!(cls1 != sobj);
let scls /*also java/lang/String*/ = sobj.get_class(&cap);
assert!(scls == cls1);
assert!(scls == cls);
// TODO: somehow these cls1, scls and cls have different lifetimes (or not?)
// So those two asserts do not compile!!
assert!(cls1 == scls);
assert!(cls == scls);

要“修复”这个问题,我必须更改 eq 代码:

impl<'a, 'b, R: 'b + JObject<'b>> PartialEq<R> for JavaObject<'a> {
fn eq(&self, other: &R) -> bool {
self.get_env().is_same_object(self, other)
}
}

impl<'a, 'b, R: 'b + JObject<'b>> PartialEq<R> for JavaClass<'a> {
fn eq(&self, other: &R) -> bool {
self.get_env().is_same_object(self, other)
}
}

pub fn JavaEnv::is_same_object<'b, T1: 'a + JObject<'a>, T2: 'b + JObject<'b>>(&self, obj1: &T1, obj2: &T2) -> bool {
unsafe {
((**self.ptr).IsSameObject)(self.ptr, obj1.get_obj(), obj2.get_obj()) == JNI_TRUE
}
}

但我不想比较附加到不同 VM 的 JObject!而且,甚至更多:我只是不明白,这些对象如何最终具有不同的生命周期参数?它们都是从同一个 JavaEnv 获得的,因此也是同一个 JavaVM!

因此,问题是:我做错了什么,为什么会发生这种情况以及如何解决这个问题?

最佳答案

我认为您的基本前提有问题。查看此示例代码:

fn are_equal<'a>(a: &'a u8, b: &'a u8) -> bool {
*a == *b
}

fn main() {
let a = 42;

{
let b = 84;
println!("{}", are_equal(&a, &b));
}
}

在这里,我们有一个方法接受两个引用参数,生命周期参数为 'a。但是,您可以清楚地看到 ab(在 main 中)的实际生命周期不同 — 由于 block 结束,ab 长。

所需要的只是一些生命周期可以统一两个参数,并且有 - 内部 block 的范围。这并不意味着整个生命周期必须完全相等。

关于rust - 变量具有不同的生命周期,而它们本应具有相同的生命周期,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30485961/

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