Christof Petig (Jul 29 2023 at 10:02): Christof Petig (Jul 29 2023 at 10:02):I have created a wit-bindgen fork providing high level type support for C++ (std::{optional, expected, string, vector, …}, namespaces, methods on resources).
Because this is sadly not commercially backed and I prefer writing Rust over C++ in my spare time, I don't aim to maintain a functionally complete solution (yet), but perhaps there is enough interest to turn this into a group effort.
Over the past weeks I gained enough knowledge of the code base to adapt it into supporting my subset of WIT, both on the guest and host (WAMR) side.
Robin Brown (Jul 31 2023 at 16:44):Is this a temporary fork that you're intending to contribute back up to wit-bindgen?
Christof Petig (Jul 31 2023 at 22:17):This is meant as a temporary fork, mostly because I won't be able to quickly reach the quality of code and completeness I would expect from integration into the official repository.
Christof Petig (Sep 18 2023 at 19:27):Ayako Akasaka said:
I saw your great work(https://github.com/cpetig/resource-demo/blob/main/guest-cpp/main.cpp) and https://github.com/cpetig/wit-bindgen.git. It worked well for my project.
Are you going to push "wit-bindgen cpp-host/c-host" to main wit-bindgen? And can we contribute if it can help you to accelerate?
I answer in this channel to keep the information about C++ bindings more together.
I plan to propose a merge into main wit-bindgen once the test cases work for C++ and I no longer have lots of dead and duplicated code - as I copied parts together from the Rust and C binding. Also my understanding of the inner structure has improved a lot since I started the fork, now I know how to use FunctionBindgen::emit(). Even though this isn't yet used in all places it makes sense.
I would love to get some feedback on the binding, e.g. whether std::optional and std::expected work for you and whether using && for non-borrowed arguments would be acceptable (I think this is the most reasonable option, but it will require plenty of std::move). Borrowed arguments (also all non-resource arguments to imported functions) would receive T const&.
If you happen to use C++ in the context of adaptive AUTOSAR you have an additional option, as I maintain a special fork² to generate code for their C++14 compatible types.
Best regards
Christof
Christof Petig (Sep 18 2023 at 19:43):Another issue is with string and list types, as with Rust you can convert these objects into and from a realloced pointer - but with C++ these conversions aren't supported by the std library (as far as I can tell). So I used an owning string_view and span derivative as a workaround.
Ayako Akasaka (Nov 26 2023 at 14:46):Hi, @Christof Petig
I saw you doing a lot at https://github.com/cpetig/wit-bindgen/pull/1.
You're doing a lot of hard work.
If possible, could you please tell me about the current status?
Christof Petig (Nov 26 2023 at 22:17):Ayako Akasaka said:
If possible, could you please tell me about the current status?
The overly simple resource example from https://github.com/cpetig/resource-demo/blob/main/wit/simple.wit works for both guest and host (but I want to change the interface for class implementation from private implementation to a user controlled class definition ASAP).
Today I was able to create host bindings for WASI:cli@0.2.0-rc (no panic) but with a lot of stubs in the generated code. I plan to enable this case within the coming days. But still supporting all data types (record, flags, variant, list, result, resource) in both directions is a large task.
So I would say that unless you want to generate something very simple, the current code is not yet up to the task (because I need resources I didn't implement the more simple data types first). Feel free to give it a try, but don't expect the generated code to be correct, yet.
But the most arduous part (getting any code output) should be completed as of today.
Best regards, Christof
Christof Petig (Nov 27 2023 at 21:25):Update: I changed the class implementation (export) to include an user controlled header (with an autogenerated template).
I will now proceed to implementing more of the WASI types on host side.
PS: Please drop me a note if my constant rebasing to upstream main creates unnecessary work, then I can start creating merges.
Christof Petig (Dec 11 2023 at 21:10):I promised @Trevor Elliott updates whenever I work on C++ code generation.
I currently work on getting the host part of the WASI interfaces supported (wamr target). Today I implemented tuple, flags and host load+store.
Open points are that the order of resource definitions aren't right in case of inter-dependencies (Rust doesn't care) - and some of the lifting lowering is incomplete.
Gordon Smith (Jan 09 2024 at 08:56):@Christof Petig Have you implemented a c/c++ version of the canonical ABI as part of your work?
I have started one as part of a plugin project for a big data platform (currently only supporting "scalars") and didn't want to duplicate work... (See: https://github.com/hpcc-systems/HPCC-Platform/blob/master/plugins/wasmembed/abi.cpp)
Christof Petig (Jan 09 2024 at 09:32):Oh interesting, I was using the Rust implementation for the c++ code generator.
Christof Petig (Jan 09 2024 at 09:34):Also I realized that calling into exported functions on the host side requires generating proper wasm guest calling code...
Gordon Smith (Jan 09 2024 at 09:37):So your plan for the host was to import / reference a rust lib?
Christof Petig (Jan 09 2024 at 23:41):No, the Rust crate calls into the bindgen code to generate c++ code to lift/lower the data types, so no Rust at runtime.
Last updated: Nov 22 2024 at 16:03 UTC