[][src]Struct rbl_circular_buffer::CircularBuffer

pub struct CircularBuffer<T> { /* fields omitted */ }


impl<T> CircularBuffer<T>[src]

pub fn new(size: usize) -> Self[src]

Create a new CircularBuffer of size size.

It allocate an array of exactly size element, if the allocation fail, the method panic.

Negligible amount of space used by the CircularBuffer beside the array itself.

pub fn len(&self) -> usize[src]

Returns the amount of elements in the CircularBuffer in O(1)

pub fn push(&mut self, value: T) -> usize[src]

Push a new element into the CircularBuffer in O(1) does not do any allocation.

If the CircularBuffer is full, the first element of the CircularBuffer is overwritten.

pub fn fill(&mut self, return_vector: &mut Vec<T>) -> usize[src]

Main method to read elements out of the CircularBuffer.

The return vector get filled, with as many as possible elements from the CircularBuffer.

The available elements in the CircularBuffer are the same returned by the method len. The elements that the vector can accepts are given by return_vector.capacity() - return_vector.len()

The method avoids allocating memory.

Hence if the vector is already full, no elements are pushed into the vector.

If the CircularBuffer is empty, no elements are pushed into the vector.

If the vector can accept more elements that are prensent in the CircularBuffer, the vector get filled as much as possible and the CircularBuffer will remain empty.

If the vector cannot accept all the element in the CircularBuffer, the vector get filled while the CircularBuffer will be left with some elements inside.

The operation runs in O(n) with n number of elements pushed into the vector.

pub fn _fast_fill(&mut self, return_vector: &mut Vec<T>) -> usize[src]

The _fast_fill method is supposed to be a faster alternative to the fill one. However, benchmarks failed to show any difference in performance. If the benchmark showed any difference, it was the _fast_fill method being a little slower.

The _fast_fill method is more complex that the fill method, so I suggest to rely on the simpler fill. However both methods passed the same properties tests, so they should be equally correct.

The _fast_fill is implemented using raw pointer and memcopy. While the fill method pull elements using the iterator and simply push them to the back of the vector.

Trait Implementations

impl<T: Clone> Clone for CircularBuffer<T>[src]

impl<T: Copy> Copy for CircularBuffer<T>[src]

impl<T: Debug> Debug for CircularBuffer<T>[src]

impl<T: Display> Display for CircularBuffer<T>[src]

impl<T> Iterator for CircularBuffer<T>[src]

Create an iterator, elements from the iterator are consumed and are not present anymore in the buffer.

type Item = T

The type of the elements being iterated over.

fn size_hint(&self) -> (usize, Option<usize>)[src]

The size_hint is correct, it is not an hint but it is the correct value.

Auto Trait Implementations

impl<T> RefUnwindSafe for CircularBuffer<T> where
    T: RefUnwindSafe

impl<T> !Send for CircularBuffer<T>

impl<T> !Sync for CircularBuffer<T>

impl<T> Unpin for CircularBuffer<T>

impl<T> UnwindSafe for CircularBuffer<T> where
    T: RefUnwindSafe

Blanket Implementations

impl<T> Any for T where
    T: 'static + ?Sized

impl<T> Borrow<T> for T where
    T: ?Sized

impl<T> BorrowMut<T> for T where
    T: ?Sized

impl<T> From<T> for T[src]

impl<T, U> Into<U> for T where
    U: From<T>, 

impl<I> IntoIterator for I where
    I: Iterator

type Item = <I as Iterator>::Item

The type of the elements being iterated over.

type IntoIter = I

Which kind of iterator are we turning this into?

impl<T> ToOwned for T where
    T: Clone

type Owned = T

The resulting type after obtaining ownership.

impl<T> ToString for T where
    T: Display + ?Sized

impl<T, U> TryFrom<U> for T where
    U: Into<T>, 

type Error = Infallible

The type returned in the event of a conversion error.

impl<T, U> TryInto<U> for T where
    U: TryFrom<T>, 

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.