3 unstable releases
0.2.1 | May 21, 2024 |
---|---|
0.2.0 | May 21, 2024 |
0.1.0 | May 19, 2024 |
#683 in Memory management
62 downloads per month
15KB
139 lines
hato
Heterogeneous Arenas of Trait Objects.
The collection is tied to a user trait, and elements are retrieved as trait objects.
This is an alternative to Vec<Box<dyn Trait>>
, without requiring one allocation per entry.
A bump allocator like bumpalo
will bring
similar benefits, but will not offer methods for memory reclamation.
This can be limiting for workloads involving alternating insertions and deletions.
Elements must implement
the Unscrupulous trait,
which makes cloning the arena fast, just a couple of memcpy
calls per type of objects
stored in the collection. Be aware that this is quite constraining; make sure your types fulfill
the requirements
for the trait.
Typical usage looks like this:
// Initialize the collection
let mut arena = hato::Hato::<dyn core::fmt::Debug>::default();
// Insert a elements of different types that all implement our trait
let x = arena.push(4_u16);
let y = arena.push(2_i32);
// We use the handles to access the trait objects
assert_eq!(format!("{:?}", arena.get(x)), "4");
assert_eq!(format!("{:?}", arena.get(y)), "2");
// We can remove individual elements...
arena.remove(x);
// ... and re-use the underlying capacity
let _z = arena.push(7_u16);
Caveats
- This crate requires unstable features, stay on version 0.1.0 if you cannot use nightly.
Hato
groups objects by their virtual table, which is duplicated across codegen units. Building withcodegen-units = 1
can be worthwhile to reduce the number of separate arenas.- This collection is subject to the ABA problem. See type documentation for more details.
Acknowledgements
Major thanks to @bluurryy! Without their skills and time, this crate would have stayed a messy, unwieldy, non-generic, unergonomic macro.
Dependencies
~0.4–0.8MB
~20K SLoC