5个版本

0.1.4 2020年6月18日
0.1.3 2019年8月13日
0.1.2 2019年8月11日
0.1.1 2019年8月11日
0.1.0 2019年8月11日

#1398 in 数据结构

Download history 150/week @ 2024-03-13 227/week @ 2024-03-20 74/week @ 2024-03-27 409/week @ 2024-04-03 387/week @ 2024-04-10 467/week @ 2024-04-17 393/week @ 2024-04-24 383/week @ 2024-05-01 273/week @ 2024-05-08 337/week @ 2024-05-15 644/week @ 2024-05-22 263/week @ 2024-05-29 309/week @ 2024-06-05 154/week @ 2024-06-12 442/week @ 2024-06-19 372/week @ 2024-06-26

1,321 每月下载次数
用于 genmap

Apache-2.0 / MIT

86KB
1.5K SLoC

handy: 句柄和句柄映射。

Docs CircleCI codecov

handy 为Rust代码提供句柄和句柄映射。这是一个相当有用的数据结构,因为它可以帮助你绕过借用检查器的问题。

基本上,HandleHandleMap 是一种更健壮的模式,你不再直接存储对 &T 的引用,而是存储一个 usize,它指示它在某个 Vec 中的位置。我认为它们更健壮,因为:

  • 它们可以检测你是否试图在提供句柄的映射之外使用句柄。

  • 如果你从句柄映射中删除一个项目,句柄映射不会让你使用过时的句柄来获取在那个槽位上可能存在的任何值。

类似的项目

有很多。

  • slotmap:与这个想法相同,但它要求 T: Copy(有方法绕过这个限制,但我觉得很麻烦)。有一个系统来定义用于特定映射的句柄,但不能检测你是否在一个映射中使用来自另一个映射的键,如果映射类型相同。它还有一大堆用于不同性能情况的映射,但说实话,T: Copy 的限制阻止了我深入研究。

  • slab:也是同样的想法,但你不一定从文档中意识到。它不能检测使用错误的映射或在使用项目后删除另一个项目占用相同位置的情况。

  • ffi_supportHandleMap:我写了这个。它与这个非常相似,但有一些不同的权衡,并且基本上是不同的代码。此外,这个库不会引入太多重量级的依赖项,具有更多功能,并且不专注于FFI内部的使用。

  • 与它们中的任何一个不同,我们可以在无_std环境下使用(当然,我们与extern crate alloc链接)。

许可证

TLDR:与每个Rust库一样,MIT / Apache2。

此代码与https://crates.io/crates/ffi-support中的Handle/HandleMap类型具有共同的遗产(毕竟,我也编写了那个库)。我还从那个crate中直接借鉴了测试代码。因此,这个库具有完全相同的许可证,包括版权归属Mozilla。

实际上这并不重要,因为谁在乎呢,它们都是MIT / Apache2,但我认为我应该把它写下来。

无运行时依赖