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 |
#397 in Memory management
48 downloads per month
Used in 2 crates
(via embedded-executor)
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