Struct alloc::raw_vec::RawVec [−] [src]

pub struct RawVec<T> {
    // some fields omitted
}
Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

A low-level utility for more ergonomically allocating, reallocating, and deallocating a a buffer of memory on the heap without having to worry about all the corner cases involved. This type is excellent for building your own data structures like Vec and VecDeque. In particular:

This type does not in anyway inspect the memory that it manages. When dropped it will free its memory, but it won't try to Drop its contents. It is up to the user of RawVec to handle the actual things stored inside of a RawVec.

Note that a RawVec always forces its capacity to be usize::MAX for zero-sized types. This enables you to use capacity growing logic catch the overflows in your length that might occur with zero-sized types.

However this means that you need to be careful when roundtripping this type with a Box<[T]>: cap() won't yield the len. However with_capacity, shrink_to_fit, and from_box will actually set RawVec's private capacity field. This allows zero-sized types to not be special-cased by consumers of this type.

Methods

impl<T> RawVec<T>

fn new() -> Self

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Creates the biggest possible RawVec without allocating. If T has positive size, then this makes a RawVec with capacity 0. If T has 0 size, then it it makes a RawVec with capacity usize::MAX. Useful for implementing delayed allocation.

fn with_capacity(cap: usize) -> Self

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Creates a RawVec with exactly the capacity and alignment requirements for a [T; cap]. This is equivalent to calling RawVec::new when cap is 0 or T is zero-sized. Note that if T is zero-sized this means you will not get a RawVec with the requested capacity!

Panics

  • Panics if the requested capacity exceeds usize::MAX bytes.
  • Panics on 32-bit platforms if the requested capacity exceeds isize::MAX bytes.

Aborts

Aborts on OOM

unsafe fn from_raw_parts(ptr: *mut T, cap: usize) -> Self

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Reconstitutes a RawVec from a pointer and capacity.

Undefined Behavior

The ptr must be allocated, and with the given capacity. The capacity cannot exceed isize::MAX (only a concern on 32-bit systems). If the ptr and capacity come from a RawVec, then this is guaranteed.

fn from_box(slice: Box<[T]>) -> Self

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Converts a Box<[T]> into a RawVec<T>.

impl<T> RawVec<T>

fn ptr(&self) -> *mut T

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Gets a raw pointer to the start of the allocation. Note that this is heap::EMPTY if cap = 0 or T is zero-sized. In the former case, you must be careful.

fn cap(&self) -> usize

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Gets the capacity of the allocation.

This will always be usize::MAX if T is zero-sized.

fn double(&mut self)

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Doubles the size of the type's backing allocation. This is common enough to want to do that it's easiest to just have a dedicated method. Slightly more efficient logic can be provided for this than the general case.

This function is ideal for when pushing elements one-at-a-time because you don't need to incur the costs of the more general computations reserve needs to do to guard against overflow. You do however need to manually check if your len == cap.

Panics

  • Panics if T is zero-sized on the assumption that you managed to exhaust all usize::MAX slots in your imaginary buffer.
  • Panics on 32-bit platforms if the requested capacity exceeds isize::MAX bytes.

Aborts

Aborts on OOM

Examples

struct MyVec<T> {
    buf: RawVec<T>,
    len: usize,
}

impl<T> MyVec<T> {
    pub fn push(&mut self, elem: T) {
        if self.len == self.buf.cap() { self.buf.double(); }
        // double would have aborted or panicked if the len exceeded
        // `isize::MAX` so this is safe to do unchecked now.
        unsafe {
            ptr::write(self.buf.ptr().offset(self.len as isize), elem);
        }
        self.len += 1;
    }
}

fn reserve_exact(&mut self, used_cap: usize, needed_extra_cap: usize)

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Ensures that the buffer contains at least enough space to hold used_cap + needed_extra_cap elements. If it doesn't already, will reallocate the minimum possible amount of memory necessary. Generally this will be exactly the amount of memory necessary, but in principle the allocator is free to give back more than we asked for.

If used_cap exceeds self.cap(), this may fail to actually allocate the requested space. This is not really unsafe, but the unsafe code you write that relies on the behavior of this function may break.

Panics

  • Panics if the requested capacity exceeds usize::MAX bytes.
  • Panics on 32-bit platforms if the requested capacity exceeds isize::MAX bytes.

Aborts

Aborts on OOM

fn reserve(&mut self, used_cap: usize, needed_extra_cap: usize)

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Ensures that the buffer contains at least enough space to hold used_cap + needed_extra_cap elements. If it doesn't already have enough capacity, will reallocate enough space plus comfortable slack space to get amortized O(1) behavior. Will limit this behavior if it would needlessly cause itself to panic.

If used_cap exceeds self.cap(), this may fail to actually allocate the requested space. This is not really unsafe, but the unsafe code you write that relies on the behavior of this function may break.

This is ideal for implementing a bulk-push operation like extend.

Panics

  • Panics if the requested capacity exceeds usize::MAX bytes.
  • Panics on 32-bit platforms if the requested capacity exceeds isize::MAX bytes.

Aborts

Aborts on OOM

Examples

struct MyVec<T> {
    buf: RawVec<T>,
    len: usize,
}

impl<T> MyVec<T> {
    pub fn push_all(&mut self, elems: &[T]) {
        self.buf.reserve(self.len, elems.len());
        // reserve would have aborted or panicked if the len exceeded
        // `isize::MAX` so this is safe to do unchecked now.
        for x in elems {
            unsafe {
                ptr::write(self.buf.ptr().offset(self.len as isize), x.clone());
            }
            self.len += 1;
        }
    }
}

fn shrink_to_fit(&mut self, amount: usize)

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Shrinks the allocation down to the specified amount. If the given amount is 0, actually completely deallocates.

Panics

Panics if the given amount is larger than the current capacity.

Aborts

Aborts on OOM.

unsafe fn into_box(self) -> Box<[T]>

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

Converts the entire buffer into Box<[T]>.

While it is not strictly Undefined Behavior to call this procedure while some of the RawVec is unintialized, it cetainly makes it trivial to trigger it.

Note that this will correctly reconstitute any cap changes that may have been performed. (see description of type for details)

fn unsafe_no_drop_flag_needs_drop(&self) -> bool

Unstable (alloc #27783)

: this library is unlikely to be stabilized in its current form or name

This is a stupid name in the hopes that someone will find this in the not too distant future and remove it with the rest of

[unsafe_no_drop_flag]

Trait Implementations

impl<T> Drop for RawVec<T>

fn drop(&mut self)