【问题标题】:Runtime Building: String not found in this scope运行时构建:在此范围内找不到字符串
【发布时间】:2020-12-17 21:19:54
【问题描述】:

基板开发人员可能会遇到一个常见问题:开发自定义托盘以将映射存储到具有常见类型的存储中,例如 String。举个例子:

#[derive(Encode, Decode, Clone, Default, RuntimeDebug)]
pub struct ClusterMetadata {
    ip_address: String,
    namespace: String,
    whitelisted_ips: String,
}

在构建运行时时,每个String 都会出现此错误:

     |
  21 |     ip_address: String,
     |                 ^^^^^^ not found in this scope

为什么Strings 不在范围内?和其他std 锈类型?

【问题讨论】:

标签: string rust substrate rust-no-std


【解决方案1】:

此处的错误与no_std 无关,因此您可能只需要导入String 类型即可获得在运行时使用字符串的真正错误。

您会发现真正的问题是 String 不能被 Parity SCALE 编解码器编码,这显然是运行时中任何存储项目(或大多数您想使用的任何类型)的要求。

所以问题是“为什么 SCALE 不编码 String”?

这是自愿的。一般来说,String 是一种非常复杂的类型。 Rust 书花了a whole section 讨论类型的复杂性。

因此,它很容易成为人们错误使用Strings 的运行时环境中的枪。

此外,将Strings 存储在运行时存储中通常是不好的做法。我认为我们可以很容易地同意,在运行时最小化存储使用是一种最佳实践,因此您应该只将需要能够在运行时获得共识和状态转换的存储项放入存储中。大多数情况下,String 数据将用于元数据,这种用法并不是最佳做法。

如果您更仔细地查看 Substrate,您会发现我们不止一次违反了此最佳实践,但这是我们明确做出的决定,手头有信息能够正确评估成本/收益。

所有这些结合起来就是为什么Strings 在运行时不被视为第一类对象。相反,我们要求用户将字符串编码为字节,然后使用该字节数组。

【讨论】:

  • 如果可能的话,您能否详细说明一下关于基板中String 的副作用?虽然从你的写作来看是合理的,但我无法得到令人印象深刻的结果。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-03-24
  • 2019-10-30
  • 1970-01-01
  • 1970-01-01
  • 2015-05-26
相关资源
最近更新 更多