[−][src]Crate alloc_many
[Proof of Concept] Allocator singletons and parameterized collections on stable
Isn't the alloc crate going to be stabilized in 1.36?
Yes, and you will be able to use it in libraries and std binaries but not in no_std
binaries because alloc has a hard dependency on #[global_allocator] (stable) and, on
no_std, #[global_allocator] has a hard dependency on #[alloc_error_handler] which is
unstable and has no stabilization date.
Features
-
You are not limited to a single global allocator; you can create as many allocators as you want.
-
Instantiate collections on any of these allocators.
-
Works on stable.
Cons
-
Doesn't integrate with the
alloccrate. Meaning that we need to re-create that crate from scratch. -
Dynamically Sized Types (e.g.
Box<[u8]>andBox<dyn Fn()>) are not supported becauseCoerceUnsizedandUnsizeare unstable APIs.
Example
#![no_main] #![no_std] use core::alloc::Layout; use alloc_many::{alloc, oom}; use alloc_many_bump::{consts, BumpAlloc}; // NOTE: MSRV = 1.36 use alloc_many_collections::Box; // instead of the (still) unstable `alloc` crate use cortex_m_rt::entry; use panic_halt as _; // panic handler // instantiate a bump allocator and bind it to the type `A` #[allocator] // instead of the reserved `#[global_allocator]` static A: BumpAlloc<consts::U128> = BumpAlloc::new(); #[entry] fn main() -> ! { // allocate this value on allocator `A` let _x: Box<A, _> = Box::new(0); loop {} } // called when any allocator signals OOM #[oom] // instead of the reserved, unstable `#[alloc_error_handler]` fn oom(_: Layout) -> ! { loop {} }
(Yes, a bump pointer allocator is not a really good choice for an allocator. You may want to check out my TLSF allocator)
Minimum Supported Rust Version (MSRV)
This crate is guaranteed to compile on stable Rust 1.32 and up. It might compile on older versions but that may change in any new patch release.
Re-exports
pub use alloc_many_macros::allocator; |
pub use alloc_many_macros::oom; |
Traits
| Alloc | Singleton version of |