11 unstable releases
0.6.1 | Oct 28, 2022 |
---|---|
0.5.0 | Oct 24, 2021 |
0.4.1 | Jul 3, 2021 |
#503 in Memory management
Used in encase
89KB
1.5K
SLoC
StaticRc
is a safe reference-counted pointer, similar to Rc
or Arc
, though performing its reference-counting at
compile-time rather than run-time, and therefore avoiding most run-time overhead.
Motivating Example
A number of collections, such as linked-lists, binary-trees, or B-Trees are most easily implemented with aliasing pointers.
Traditionally, this requires either unsafe
raw pointers, or using Rc
or Arc
depending on the scenario. A key
observation, however, is that in those collections the exact number of aliases is known at compile-time:
- A doubly linked-list has 2 pointers to each node.
- A binary-tree has 3 pointers to each node: one from the parent, and one from each child.
- A B-Tree of cardinality N has N+1 pointers to each node.
In this type of scenario, static-rc
offers the safety of Rc
and Arc
, with the performance of unsafe
raw
pointers.
Goals
Provide safe and efficient reference-counting:
- Efficiency: most associated functions boil down to copying a
NonNull<T>
, a trivial operation.- One key exception are
join
functions: a run-time check must be performed to ensure the instances being joined refer to the same pointer. Unsafe unchecked variants are available if their overhead is too high.
- One key exception are
- Safety: most associated functions are safe to use.
- The few unsafe functions are strictly optional.
Maturity
This crate is still very much experimental.
Review:
- Minimally reviewed.
- Not audited.
- Not formally proven.
Documentation:
- All
StaticRc
associated functions are documented, with example. - All
StaticRcRef
associated functions are documented, with example.
Testing:
- All compile-time assertions are tested with compile-fail tests.
- All panics are tested with panic tests.
- Miri runs the test-suite without any complain.
Debug checks
This library contains a number of additional checks when building with debug_assertions
, in particular the Drop
implementation of StaticRc
will catch any attempt at destroying a StaticRc<T, N, D>
where N <> D
, as this would
typically result in a leak.
Those checks are not strictly necessary for safety, they are included to help point out logic errors.
From experience, the Drop
check on top of an extensive test-suite will help catch all those instances where one path
accidentally let a pointer drop.
That's all folks!
And thanks for reading.