< 返回版块

Cupnfish 发表于 2021-11-11 22:43

为Rust有很多字符串类型而烦恼吗?好吧,它没有必要

众所周知Rust有几种不同的字符串类型。两个主要的竞争者是:

  • &str是一个 "字符串引用"。它是不可调整大小的,它的可变性是有限的。
  • String是一个 “自有(owned)字符串"。它是可调整大小的,并且可以简单地被改变。

事实证明,这两个字符串并没有太大区别。 str只是一个由[u8]字节片支持的字符串。 同样地,String只是一个Vec<u8>支持的字符串

那么为什么它们真的是不同的类型呢?理论上我们不能有这样的东西吗:

type str = StringBase<[u8]>;
type String = StringBase<Vec<u8>>;

所以,就是这一点。这主要是为了与标准库中的字符串进行功能比对。很多标准trait的实现,这里也实现了。

我还实现了

type str32 = StringBase<[char]>;
type String32 = StringBase<Vec<char>>;

用于utf-32应用程序。

顺便贴上这个万恶的表情包:

doge

Github: https://github.com/conradludgate/generic-str

Redox OS(以及类似的项目)计划如何处理缺乏动态链接支持的问题?

几天前,我问是否有人对C FFI之外的二进制库发行有什么建议,人们不断地给我指出各种 "hack "解决方案,对此我非常感激(尽管这些hack的方法在我的特定情况下没有帮助,C FFI看起来仍然是最不坏的解决方案)。

然而,有一件事让我很吃惊,那就是动态链接(或者说是可预测的ABI,我认为动态链接需要ABI)的想法(也许只是被认为)受到了反对。还有一个事实是,几乎没有人关心在我看来是系统语言设计中的一个巨大漏洞。

TL;DR:

这让我想到:Redox OS或类似的项目(比如今天早些时候u/dptzippy发布的项目)打算如何解决这个问题?他们肯定不会期望人们在某个核心库/缓存中的错误修复后重新编译整个操作系统,或者他们会怎样做?还是我错过了什么?

*我说的是 "可预测 "而不是 "稳定",因为我们不需要一个完全稳定的ABI。即使只是保证如果我用同一版本的编译器编译东西,如果公共API保持不变,公共ABI也会有很大的帮助。

今日reddit上的Rust板块的热帖,贴一下高赞回复:

你好,我是Theseus操作系统的作者。很好的帖子,真的和我心底的想法一致。

缺乏一个稳定的ABI是我们尚未完全解决的一个大障碍。这个问题对于像 Theseus 这样基于安全语言的 SAS/SPL 操作系统来说特别重要,考虑到我们的目标是让编译器对系统各层的所有代码都能可见(visibility)/自我反省(instrospection),没有盲点,就更重要了。我个人认为,对于使用系统调用作为用户应用程序和内核之间的 "稳定 "接口的其他操作系统来说,这不是一个问题,或者在更广泛的意义上,作为两个独立编译的代码片断之间的 "稳定 "连接层,它们在执行时相互依赖。 我记录了我在实现针对现有 Theseus 编译实例为了编译out-of-tree这个crate(以及一个各种启动器 libc 骨架)的工具时所经历的历程和思考过程。这涉及到对cargo的hack式滥用,我没必要推荐其他用例 -- 在我们有限的事例下,它是有效的,因为我们可以控制一切的编译 -- 但相当难以处理。它很可能无法扩展到支持闭源应用程序或库的分发。显然,我意识到,在运行时动态地重新链接单独编译的二进制文件中的符号/依赖关系是非常愚蠢和乏味的,这些符号/依赖关系在构建时是静态链接的,与实际运行的系统实例中存在的这些依赖关系的版本相一致。请注意,我们还没有时间去探索更好的选择。我发这个帖子只是为了说明人们为了解决稳定的ABI问题而可能需要做的事情。

最好的 "替代方案 "基本上是其他人在你上面链接的u/dptzippy的帖子中所建议的—使用某种bindgen来创建一个薄的FFI层,将稳定的C ABI函数作为Rust函数的存根来暴露。然而,这有一个主要的缺点,那就是到处引入不必要的unsafe因素,这有点违反了我上面提到的Theseus的整个目标,因为unsafe因素是一个盲点。

不管怎么说,我只是觉得应该把我的想法说出来,在这里分享我的经验,让对话进行下去,看看其他人有什么意见。

Read More: https://www.reddit.com/r/rust/comments/qr5pyo/how_is_redox_os_and_similar_projects_planning_to/

异步取消(asnyc cancellation)

有时我们开始做事情,但中途决定宁愿不做这些事情。这个过程有时被称为 "取消"。比如我们不小心在浏览器中点击了 "下载 "一个大文件。我们应该有办法告诉计算机停止下载它。

今年早些时候,当Rust异步工作组在研究用户体验时,异步取消被反复提及。这是一种很重要的东西,但推理起来却很麻烦。我想我可以通过写一篇关于这个主题的深度研究来改变这种状况。

在这篇文章中,我们将看一下Async Rust的异步原语,并介绍今天这些原语的取消是如何进行的。然后,我们将继续研究如何确保我们不会出现资源悬空的情况。最后,我们将看看当前Async Rust的方向对Async取消意味着什么。听起来像个计划?很好,让我们开始行动吧

技术向博文。

Read More: https://blog.yoshuawuyts.com/async-cancellation-1/

保持冷静,学习Rust。我们很快就会在Linux中更多的看到这种语言。

要成为一名Linux开发者,你曾经需要C语言作为你的护照。现在Rust也可以让你成为一个操作系统程序员。

有这样一个笑话。"C语言结合了汇编语言的力量和性能以及汇编语言的灵活性和易用性"。我曾经用C语言和IBM 360汇编语言编程--那是很久以前的事了,好吧--这话是有道理的。由于C语言的功能、性能和可移植性,它成为操作系统语言的首选,当然也包括Linux。

一篇博文,介绍Rust在Linux中的应用。

Read More: https://www.theregister.com/2021/11/10/where_rust_fits_into_linux/

本周周报

即使你能修复rustc的所有健全性漏洞,或者以其他方式防止用户代码利用这些漏洞,任何第三方库中的健全性漏洞也会使恶意的crates有可能从安全代码中触发任意行为。

[...]

这就是为什么我们需要强调,虽然Rust的静态分析在限制非恶意代码的意外漏洞方面非常出色,但它们并不是一个可以对恶意代码进行有意义限制的沙盒系统。

Read More: https://this-week-in-rust.org/blog/2021/11/10/this-week-in-rust-416/

最后

这个月的游戏月报,有不少很好的作品,关注Rust游戏开发的小伙伴,别忘了去看月报!

Read More: https://gamedev.rs/news/027/

From 日报小组 Cupnfish

社区学习交流平台订阅:

评论区

写评论

还没有评论

1 共 0 条评论, 1 页