-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Support a fixed-dynamic-capacity Vec #353
Comments
SliceVec<'a, T>
, backed by a &mut [MaybeUninit<T>]
instead of [MaybeUninit<T>; N]
SliceVec<'a, T>
, backed by a &mut [MaybeUninit<T>]
instead of [MaybeUninit<T>; N]
SliceVec<'a, T>
, backed by a &'a mut [MaybeUninit<T>]
instead of [MaybeUninit<T>; N]
SliceVec<'a, T>
, backed by a &'a mut [MaybeUninit<T>]
instead of [MaybeUninit<T>; N]
So, after some deliberation, my initial proposal isn't quite right. You cannot simply produce a /// Read up to `N` bytes from some response into `out`.
fn read_from_response<const N: usize>(&mut self, out: &mut heapless::Vec<u8, N>) -> Result<(), Err>; We want this to be able to work safely with different However, I also want to be able to work with an externally provided buffer, as parts of our system design require it. Right now we're just So, I want a So, the best design I have is two separate types, and I'd like to hear your thoughts. Both avoid monomorphization on
Our paradigms pretty much require the latter, but the former seems like an overall better fit for the library. I'd love if I could have both in here and spruce up some of the utility functions, but I don't want to put in the effort in to upstream if the maintenance/usability burden is excessive on your end. |
So, a dynamically sized
Vec
, but still with a max capacity. This would remain heapless, as you can construct the slice on the stack orstatic
and pass it in. There are some particular advantages to this approach in an embedded environment, the biggest of which being the lack of monomorphization required to support multiple capacities.A. It can also be safely produced from aSliceVec<'a, T>
with dynamic lengthN
can be produced via a method on&'a mut Vec<T, N>
&'a mut [MaybeUninit<T>]
and&'a mut [T]
, since we never write new uninit data.A
SliceVec
can also be used on external buffers, such as keeping track of how many bytes of an uninit buffer have been written to and provide a safe method to retrieve the initialized bytes. This is particularly useful for zero-copy deserialization.If I were send a PR to add this, would it be accepted? This is a blocker for my team switching to
heapless
off ofFixedVec
, which has less support and fewer types to work with.The text was updated successfully, but these errors were encountered: