Skip to content
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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

elrafoon
Copy link

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.

@tommymalmqvist
Copy link
Member

Hello, this sounds very interesting. I have no experience in no_std support but will check your PR as soon as I can :)

Thanks!

@tommymalmqvist
Copy link
Member

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?

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;

@elrafoon
Copy link
Author

Hello, sorry for my latency, I will look at that.

@elrafoon
Copy link
Author

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)

@tommymalmqvist
Copy link
Member

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.

@Erk-
Copy link
Contributor

Erk- commented Oct 3, 2023

One possible solution would be to select Vec when the features are any(all(feature = "std", not(feature = "no_std")), all(feature = "std", feature = "no_std")) and then make the heapless vec only be there if only no_std is enabled

@tommymalmqvist
Copy link
Member

One possible solution would be to select Vec when the features are any(all(feature = "std", not(feature = "no_std")), all(feature = "std", feature = "no_std")) and then make the heapless vec only be there if only no_std is enabled

@elrafoon I think @Erk- suggestions is good. If you want to update your PR we can try it.

@parberge parberge added the stale Pull requests that need some sort of update but the author seems to have forgotten about it label Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Pull requests that need some sort of update but the author seems to have forgotten about it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants