Heapless no_std #20
Comments
The ways I know how to support this are
I think (1) would be un-ergonomic, especially for users that are not taking advantage of this feature. I think (2) would have unacceptable runtime cost. And for (3) I feel that at this point it makes more sense to have a whole new crate that is specialized for the needs of micro-controller arenas. Unless I am missing a fourth way, I think that forking this repo (in the happy, blessed, with good will version of forking) and chopping it up to be specialized for your domain is the best way to go. |
Approach 1 could be done as a generic type with a default of |
If you can make a proof of concept patch that adds a generic storage type parameter with a default and the existing doc comment examples continue to Just Work without modification, then I would be convinced, and would accept a full PR that implements this. |
I started playing with this and think it could potentially work. What I'm playing with is a The annoying bit is if I were to do something like Would it be acceptable to do something like: pub struct Arena<T, S: Storage> {
[...]
}
pub type ArenaVec<T> = Arena<Vec<Entry<T>>; (there's probably a better name for |
I'm interested in using this crate in a microcontroller context (it's for a DSP engine, which I've found fits the whole ECS pattern extremely well).
It seems the extant
no_std
support needsalloc
for the purposes of allocating aVec
. Would it be possible to use a heapless::Vec instead?The text was updated successfully, but these errors were encountered: