7 releases (4 breaking)

0.5.0 Oct 25, 2020
0.4.1 Sep 16, 2020
0.3.1 Apr 3, 2019
0.2.0 Jan 27, 2019
0.1.0 Jan 26, 2019

#435 in Memory management


Used in 2 crates (via embedded-executor)

MIT/Apache

7KB
78 lines

alloc-facade: std-or-alloc API Facade

The alloc crate is often used in crates that are almost no_std-compatible and only need allocation capabilities to do their thing. The problem one usually faces when developing one of these "maybe std, maybe alloc" crates is that for the std variant, everything is available either in the prelude or at std:: paths, while in alloc-only situations, the prelude must be imported manually and everything lives under alloc:: paths.

To work around this, one could simply have #[cfg(...)] conditionals over all of the imports as needed, but this quickly gets ugly and unwieldy. A better approach is to use a facade which re-exports the api from either std or alloc, whichever happens to be in use at the time.

This crate provides such a facade. Simply make sure that one of either its std or alloc features is enabled and it provides the same importable API structure for either case. Optionally, the futures feature can also be enabled to provide the task module.

The setup_imports macro

Rather than use this facade crate directly, one could also use the setup_imports macro which will generate a similar facade in your own crate. This is useful if the conditions for enabling no_std and alloc are more complicated than a simple feature flag. See its documentation for more details. Thread-safe reference-counting pointers

No runtime deps

Features