Repository navigation
C++ language support #826
Description
I have been working on a C++ bindings generator in a fork at https://github.com/cpetig/wit-bindgen for some time.
After a rewrite the code is less clumsy and could be considered for merging upstream once tests pass for more data types.
Please note that this generator is intended for host bindings (WAMR) as well and prefers most modern C++ wherever helpful. You can take a look at the intended API in https://github.com/cpetig/wit-bindgen/blob/main/crates/cpp/DESIGN.md .
Activity
alexcrichton commentedon Jan 31, 2024
I think this'd be awesome to merge, thanks for working on this! I'd be happy to help review this when you feel it's ready.
trcrsired commentedon Feb 3, 2024
better not. the problem is that these features are not freestanding C++ features. You will end up with troubles like binary bloat etc. C++ does not guarantee features that are not freestanding would exist. Plus EH is not well supported on wasm vms.
https://en.cppreference.com/w/cpp/freestanding
cpetig commentedon Feb 3, 2024
I need to guess what exactly you are recommending against.
One assumption could be to avoid using
expectedbecause the implementations are immature (and an embedded suitable (this is what I understand freestanding to imply) variant might take years to come).Personally I am less affected because my primary target, AUTOSAR adaptive platform, brings its own Result class. Another option is to use a freely available implementation compatible with c++-17 (I think with MISRA targeting this older versions should soon phase out) https://github.com/TartanLlama/expected
PS: You can read about our plans to leverage WIT for adaptive platform in https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_ARARustApplications.pdf §7.2.1
trcrsired commentedon Feb 8, 2024
expected does not make sense and i do not use it. The only solution is Herb Sutter's P0709.
trcrsired commentedon Feb 8, 2024
tschneidereit commentedon Feb 8, 2024
@trcrsired please refrain from this kind of unproductive and hostile comment. As all Bytecode Alliance projects, wit-bindgen is governed by our Code of Conduct, which we require all contributions (including comments on issues and PRs) to abide by.
Your comment violates the standards described in the Code of Conduct, so I'll hide it. If you want to discuss the merits of specific coding style or architecture decisions, you're free to do so, as long as you keep to respectful language, and accept that the maintainers of this project might not agree with your point of view and make decisions you disagree with.
trcrsired commentedon Feb 9, 2024
squillace commentedon Feb 9, 2024
"insanely inappropriate" is absolutely a point of view, and one that uses strong language implying an inability to think to pile emotion on top of its judgment. These are not a collaborative comments, regardless of your belief of its correctness. You are free to make your technical argument, of course! But a rhetorical attempt to characterize others' abilities to think "rationally" is not a technical argument.
trcrsired commentedon Feb 9, 2024
squillace commentedon Feb 9, 2024
You have complete freedom to disagree with the wasm standard, which of course you know so your comment is merely trolling. The joy of the world is this disagreement, and you remain absolutely free to spread your joy all over the internet. But here, you can make a technical argument. You made two: that because the PR isn't freestanding "there will be problems" and that in addition
EH is not well supported on wasm vms.We can evaluate those; but we won't be doing that with abuse.
tschneidereit commentedon Feb 9, 2024
While I know that @squillace will wear the SJW label as a badge of honor, using it as a derogatory term is a very clear violation of our standards and code of conduct. @trcrsired, I will hide your comments and will ask you once more to engage productively.
tschneidereit commentedon Feb 9, 2024
@cpetig as Alex says, this is great! Are there things still blocking it, or do you think it's ready to review? If so, can you open a PR?
cpetig commentedon Feb 10, 2024
@tschneidereit Thank you for your interest here, I would like to finish support for (string|list|record|option|result)⨉(guest import|export)⨉(argument|result) before filing a PR. But if you already want to take a look at the code and monitor progress, I can easily create a draft one and add these as open tasks.
PS: The last days I have been busy merging components as a plugin architecture for https://veloren.net , so don't be alarmed by the slowed progress on this branch.
tschneidereit commentedon Feb 10, 2024
That makes sense, yeah. And I'm not in a rush—I have a use case that currently works with the C generator, but which I'd love to port to C++, whenever that starts making sense.
Very cool! <3
meastp commentedon Sep 23, 2024
@cpetig I'm sorry for the noise, but it does look like your fork (https://github.com/cpetig/wit-bindgen mentioned in the first post) is (still) active - could you please provide a progress update? Just eagerly awaiting C++ support :)
cpetig commentedon Sep 24, 2024
Don't feel sorry for telling me that you are interested in what I am currently working on!
The C++ support suffered a bit from dispersion, I was working on guest and host support (two different host runtime options) and then found that symmetric ABI (which is the same on host and guest side) solves my problems much more elegantly. I even revised the original API to be symmetric (passing arguments always by rvalue reference feels more right for C++).
Just some days ago I made the lists runtime test work, so now there is a better chance that the C++ guest code will satisfy your needs. Give it a try and tell what is missing or feels wrong. I tend to recommend the --new-api variant (which isn't default, yet).
cpetig commentedon Jun 22, 2025
C++ bindings got merged, there is more polish to do, but the basic support is there.
ShalokShalom commentedon Jul 4, 2025
Sorry, should get this maybe documented as well?
The initial text of the README seems heavily outdated anyway, and also its "host section" does not speak at all about C++ as an option.