-
Notifications
You must be signed in to change notification settings - Fork 16
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
First take on a no_std support #26
base: main
Are you sure you want to change the base?
Conversation
Select dependencies according to features. Move pretty_env_logger to dev-dependencies.
This requires structs containing Vecs to accept generic const arguments with maximum vector sizes.
In std build size constants are ignored, so value itself doesn't matter. Enabled feature(generic_arg_infer) and nightly toolchain to simplify matters.
Hello, this sounds very interesting. I have no experience in no_std support but will check your PR as soon as I can :) Thanks! |
Hello, I can you rebase on the new code in main. Do you have any idea how to solve the the double Vec in lib.rs #[cfg(feature="std")]
#[allow(type_alias_bounds)]
pub type Vec<T: Sized, const N: usize> = std::vec::Vec<T>;
#[cfg(feature="no_std")]
pub use heapless::Vec; |
Hello, sorry for my latency, I will look at that. |
Does current implementation with double Vec cause any trouble? std::Vec is used in std builds, and heapless::Vec is used in no_std builds. One think that I don't like is that all Vecs now must be supplied with generic constant N, which is then ignored by std::Vec in std builds. Only other solution that comes to my mind are macros. We could use some macro throughout the library to instantiate either Vec or heapless::Vec<T,N> depending on std/no_std feature. Would you like this solution better? (I don't like it) |
Yes, the build is failing. |
One possible solution would be to select Vec when the features are |
@elrafoon I think @Erk- suggestions is good. If you want to update your PR we can try it. |
Hello,
I modified your nice library to support no_std environments.
It has some impact on std environment too, but maybe it could be worked out...
Would you be interested in reviewing and eventually merging no_std support?
Alternatively I can keep no_std version as in a standalone repo, but it seems to me as a waste of effort to maintain two crates when it could be one.