How would you go about creating a stack-allocated vector-like container with some fixed upper limit on the number of elements it can contain? You can see my attempt at this
I've written an implementation, and I'll go over the highlights.
Full code is available at crates.io/arrayvec (API doc)
Use a trait (called Array) to abstract over different array sizes. It needs to provide raw pointers so that we can use the array as backing storage.
/// Trait for fixed size arrays.
pub unsafe trait Array {
/// The array's element type
type Item;
unsafe fn new() -> Self;
fn as_ptr(&self) -> *const Self::Item;
fn as_mut_ptr(&mut self) -> *mut Self::Item;
fn capacity() -> usize;
}
macro_rules! fix_array_impl {
($len:expr ) => (
unsafe impl<T> Array for [T; $len] {
type Item = T;
/// Note: Returning an uninitialized value here only works
/// if we can be sure the data is never used. The nullable pointer
/// inside enum optimization conflicts with this this for example,
/// so we need to be extra careful. See `Flag` enum.
unsafe fn new() -> [T; $len] { mem::uninitialized() }
fn as_ptr(&self) -> *const T { self as *const _ as *const _ }
fn as_mut_ptr(&mut self) -> *mut T { self as *mut _ as *mut _}
fn capacity() -> usize { $len }
}
)
}
macro_rules! fix_array_impl_recursive {
() => ();
($len:expr, $($more:expr,)*) => (
fix_array_impl!($len);
fix_array_impl_recursive!($($more,)*);
);
}
fix_array_impl_recursive!(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
32, 40, 48, 56, 64, 72, 96, 128, 160, 192, 224,);
We need to suppress the default drop of the embedded array. You can do this by in theory using Option<Array> and using ptr::write to overwrite it with None at the last moment in Drop.
We must however use our own enum, similar to Option for one reason: We need to avoid non-nullable pointer optimization that applies to enums that have the same representation as Option. Then in Drop we do the crucial inhibition of the inner array's default destructor: we forcibly overwrite our enum. Only after destructing all the elements, of course.
/// Make sure the non-nullable pointer optimization does not occur!
#[repr(u8)]
enum Flag<T> {
Dropped,
Alive(T),
}
/// A vector with a fixed capacity.
pub struct ArrayVec<A: Array> {
len: u8,
xs: Flag<A>,
}
impl<A: Array> Drop for ArrayVec<A> {
fn drop(&mut self) {
// clear all elements, then inhibit drop of inner array
while let Some(_) = self.pop() { }
unsafe {
ptr::write(&mut self.xs, Flag::Dropped);
}
}
}
Deref<Target=[T]> and DerefMut and get tons of slice methods for free. This is a great feature of Rust!impl<A: Array> Deref for ArrayVec<A> {
type Target = [A::Item];
fn deref(&self) -> &[A::Item] {
unsafe {
slice::from_raw_parts(self.inner_ref().as_ptr(), self.len())
}
}
}
Flag<A> is always Flag::Alive(A) when the value is alive. We should be able to optimize with this in mind. (A FIXME is marked there.)fn inner_mut(&mut self) -> &mut A {
// FIXME: Optimize this, we know it's always present.
match self.xs {
Flag::Alive(ref mut xs) => xs,
_ => unreachable!(),
}
}
Thank you kmky for asking question! Exploring this answer led to the creation of arrayvec linked above, and uncovered some of the points that were very important to have it be a safe rust data structure.
My guess is that the compiler doesn't know which elements of the array are "free" and which need a destructor to run when the array is dropped.
Try storing Option<T>, which has a .take() method that will allow you to move an element out of the array.