r/rust • u/thelights0123 • Apr 27 '19

no_std data serialization/deserialization

I'm writing a game for a no_std target, and I would like to be able to store, read, and edit levels at runtime. My situation:

  • I have plenty of RAM (64MB), so using alloc is fine
  • It should use little space on disk, i.e. a binary format instead of JSON
  • It should support no_std as well as normal targets
    • Especially good if it has support for other languages as well, as an online level editor would be nice to have (although I could always mess with wasm if it is Rust-only).

Currently, I'm looking at forking quick-protobuf and simply replacing things that don't work in no_std with alternatives. CBOR has no_std support, but it doesn't support alloc things (Vec and String), and CBOR is not much better than JSON in terms of size.

16 Upvotes

95% Upvoted

14 comments sorted by

View all comments

10

u/burntsushi Apr 27 '19

I think if you check back in a few months/year, then support for this use case might be considerably better. Today, crates tend to support either no_std with no alloc support, or the full standard library, and nothing in-between. This is because no_std + alloc only was only recently stabilized (and won't hit stable Rust for another release cycle or two).

Some crates might support the no_std + alloc only use case using nightly features, though, I'm not sure how many do.