主页 / user-8447743

NoBullsh1t's questions

Martin Hope
NoBullsh1t
Asked: 2025-02-12 05:30:55 +0800 CST
  • 5

我正在构建一个应用程序。它有一个核心构件，我称之为“大脑”，它了解所有子系统（例如 DB）。

我不想直接使用任何特定的 DB 实现，而是使用特征对象（或任何可以实现相同目的的东西）。

所以看起来就像

struct Brain {
  db: Box<dyn DbTrait>,
}

但是，我也希望所有代码都是高效的，因此我使用 tokio，并且大多数内容都是异步的

trait DbTrait {
  fn do_something(&self) -> impl Future<Output = Whatever>;
}

这会产生冲突，因为 Rust 无法从返回impl类型的特征中创建特征对象，如下面的 MWE 所强调的那样：

trait ReturnsFutures {
    fn futuristic(&self) -> impl Future<Output = ()>;
}

struct FutureReturner {}

impl ReturnsFutures for FutureReturner {
    async fn futuristic(&self) {
        println!("just fake async");
    }
}

struct OtherFutureReturner {}

impl ReturnsFutures for OtherFutureReturner {
    async fn futuristic(&self) {
            println!("also fakin' it");
    }
}

struct FuturisticService {
    future_returner: Box<dyn ReturnsFutures>,
}

给出错误

the trait `ReturnsFutures` cannot be made into an object
consider moving `futuristic` to another trait
the following types implement the trait, consider defining an enum where each variant holds one of these types, implementing `ReturnsFutures` for this new enum and using it instead:
  FutureReturner
  OtherFutureReturnerrustcClick for full compiler diagnostic

目前，我能想到一种解决方法，即改为异步，特征可以返回一个通道来等待结果。虽然我觉得更复杂，但这可能是相当可行的。对于这类问题，还有其他更可行/惯用的解决方案吗？

asynchronous
Martin Hope
NoBullsh1t
Asked: 2025-02-10 03:05:25 +0800 CST
  • 7

我做了一些看起来很聪明的事情。为了更好地处理错误，我编写了如下 DB 操作

    fn handle_delete(&self, id: &Id) -> Result<(), SqliteError> {
        db_op(
            || DbOperationInfo::new("filerequests", OperationType::Delete),
            || {
                self.conn
                    .execute("DELETE FROM filerequests WHERE id = ?", [id.to_string()])?;
                Ok(())
            },
        )
    }

我的想法是，我有我的 SqliteError 枚举，它包含一个相当小的结构，其中包含有关尝试的操作及其rusqlite::error::Error原因的一些信息。

该db_op函数的作用是接受两个闭包，第一个闭包生成包含操作信息的小结构，第二个闭包执行实际操作。如果（且仅当）发生错误，则执行第一个闭包生成操作信息，然后添加导致错误的代码以创建SqliteError。

因此操作信息的创建是懒惰的。

但是我在这里真的有收获吗？还是创建闭包的成本同样高昂？或者，也许编译器会优化闭包创建并只执行一次？或者也许它会同样优化结构创建（内容有点静态）？

在此寻求一些指导：这种优化（可能）真的有帮助吗？

performance
Martin Hope
NoBullsh1t
Asked: 2024-01-10 03:59:02 +0800 CST
  • 4

我正在尝试使用相当长（1017 个字符）的承载令牌向我的 API 发出 POST 请求以进行授权。

无论我尝试什么，当我启动请求时，我都会收到一条错误消息，指出\u2026位置 512 中的（水平省略号）无法使用“latin-1”编码进行编码。由于我找不到我指定的标头的任何问题（或省略号），我唯一的解释是请求模块在内部默默地截断了我的令牌。难道是这样吗？可以禁用吗？还有其他解决方法吗？

python
Martin Hope
NoBullsh1t
Asked: 2023-09-24 03:07:07 +0800 CST
  • 5

我已经玩 Rust 一段时间了。这很难，很新，很令人兴奋，而且编译器非常有帮助。所以我通常会得到工作代码。但有一个问题我根本不明白。这就是为什么拥有多个可变引用，或者一些不可变引用和一个可变引用是一个问题？

首先，在顺序执行的程序中，我不认为这会成为问题。假设我有两个引用，无论是可变的还是不可变的。在任何时间点，只有一件事会使用该引用。当然，该值可能会改变，但我不明白这里会如何出现内存不安全。

唯一可以以任何方式相关的方法（我可以想象）是当我们引入多个线程时。我会更放心地知道所有这些都只读取数据，因为在我读取数据时，其他线程无法篡改该值。这个假设正确吗？整个可变性处理是否仅与多线程上下文相关（除了在其他语言（如JSlet和constJS）中也存在的代码可预测性）？如果不是，顺序程序怎么会因为数据在不应该可变的情况下可变而陷入麻烦（如 Rust 所见）？

第二个问题似乎更引人注目：当然，我一次只能有一个可变引用，或者在拥有不可变引用的同时没有一个可变引用。但数据的所有者仍然存在！他可以随时改变它，特别是当另一个生成的线程通过不可变引用读取数据时（如果可能的话，我对此表示怀疑，因为生命周期检查）。当所有者仍然保留改变数据的权利时，通过禁止对其他引用数据的可变引用来增加什么样的安全性？

正如你所看到的，这些问题对于我理解 Rust 在内存安全方面添加的内容非常重要。不幸的是，我没有找到任何明确的解释来解释为什么这样做，只有这样。

rust