Crates.io | orx-selfref-col |
lib.rs | orx-selfref-col |
version | |
source | src |
created_at | 2024-02-27 22:21:06.596195 |
updated_at | 2024-12-12 20:02:59.73459 |
description | SelfRefCol is a core data structure to conveniently build safe and efficient self referential collections, such as linked lists and trees. |
homepage | |
repository | https://github.com/orxfun/orx-selfref-col/ |
max_upload_size | |
id | 1155780 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
SelfRefCol
is a core data structure to conveniently build safe and efficient self referential collections, such as linked lists and trees.
It is tricky to implement safe self referential collections, SelfRefCol
provides a safe and convenient api to enable them with the following approach:
PinnedVec
,The elements of the SelfRefCol
are internally stored in a PinnedVec
implementation, which is crucial for the correctness and safety of the references.
Furthermore, in this way, elements of the collection are stored close to each other rather than being in arbitrary locations in memory in order to improve cache locality.
Note that this core structure is capable of representing a wide range of self referential collections, where the variant is conveniently defined by expressive trait type definitions.
V: Variant
: defines the structure of the collection with the following:
V::Item
: is the type of the items or elements.V::Prev
: defines how references to previous elements will be stored.
RefsNone
: there is no previous reference of elements.RefsSingle
: there is either one or no previous reference of elements, stored as Option<&Node>
.RefsArray
: there are multiple possible previous references up to a constant number N
, stored as [Option<&Node>; N]
.RefsVec
: there are multiple possible previous references, stored as Vec<&Node>
.V::Next
: defines how references to next elements will be stored:
RefsNone
or RefsSingle
or RefsArray
or RefsVec
.V::Ends
: defines how references to ends of the collection will be stored:
RefsNone
or RefsSingle
or RefsArray
or RefsVec
.M: MemoryReclaimPolicy
: defines how memory of closed nodes will be reclaimed:
MemoryReclaimNever
will never claim closed nodes.MemoryReclaimOnThreshold<D>
will claim memory of closed nodes whenever the ratio of closed nodes exceeds one over 2^D
.Consider the following four structs implementing Variant
to define four different self referential collections.
Note that the definitions are expressive and concise leading to efficient implementations.
use orx_selfref_col::*;
use core::marker::PhantomData;
pub struct Singly<T> {
p: PhantomData<T>,
}
impl<T> Variant for Singly<T> {
type Item = T;
type Prev = RefsNone;
type Next = RefsSingle<Self>;
type Ends = RefsSingle<Self>; // front
}
pub struct Doubly<T> {
p: PhantomData<T>,
}
impl<T> Variant for Doubly<T> {
type Item = T;
type Prev = RefsSingle<Self>;
type Next = RefsSingle<Self>;
type Ends = RefsArray<2, Self>; // front & back
}
pub struct BinaryTree<T> {
p: PhantomData<T>,
}
impl<T> Variant for BinaryTree<T> {
type Item = T;
type Prev = RefsSingle<Self>; // parent
type Next = RefsArray<2, Self>; // 2 children
type Ends = RefsSingle<Self>; // root
}
pub struct DynamicTree<T> {
p: PhantomData<T>,
}
impl<T> Variant for DynamicTree<T> {
type Item = T;
type Prev = RefsSingle<Self>; // parent
type Next = RefsVec<Self>; // n children
type Ends = RefsSingle<Self>; // root
}
NodeIndex
NodeIndex
belongs in the intersection of the two features efficient and safe.
A NodeIndex
is a struct holding a reference to an element of the collection. It provides constant time access to the element. Furthermore, a node index can be stored independently of the collection, elsewhere.
In this sense NodeIndex
to a SelfRefCol
is sort of analogous to usize
to standard Vec
.
However, it puts a special emphasis on safety and correctness. The following invalid uses cannot happen with NodeIndex
and SelfRefCol
. The following safety guarantees are provided by the self referential collection:
cannot use a NodeIndex
on a wrong SelfRefCol
cannot use a NodeIndex
after the corresponding element is removed
cannot use a NodeIndex
after a reorganization of the elements
SelfRefCol
The following crates use SelfRefCol
to conveniently build the corresponding data structure:
Contributions are welcome! If you notice an error, have a question or think something could be improved, please open an issue or create a PR.
This library is licensed under MIT license. See LICENSE for details.