Sketch out merging the C/C++ APIs #10600
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fitzgen
reviewed
Apr 18, 2025
There was a problem hiding this comment.
I'm a fan of splitting up the monolith C++ header and also the tests, but I am less sold on sharing headers for C and C++. What do you think of having
foo.h-- the C API forfoothingsfoo.hh-- includes the C API, adds the C++ layer on top
?
But that said, this is just a soft preference, and I also don't have a ton of experience designing C/C++ libraries, so if there is a better way I am also all ears.
FWIW that's probably the way I'd go... |
With the merging of the C++ API into this repository in bytecodealliance#10582 it opens up some interesting questions about how to organize the C++ API. Externally it was all entirely a single file, but naturally this isn't great for evolution as it's just one giant tangled header. Instead this commit sketches out a possible different path forward which is to provide the C++ API as a sibling to the C API in preexisting header files. For example this moves the `Error` class to the `error.h` header file as an example. My rough hope would be that in the long-term we could deprecate/remove the `wasmtime.hh` header file and instead "just" have all the C++ APIs in the normal header files (e.g. `wasmtime.h`). Additionally the split of the C API in separate header files would be amenable to a similar split of the C++ API too where the API you see is basically conditional on the language mode of whatever's including the headers. I'll note though I've not seen prior art in doing this. I'm not aware of any other project which exports both a C and C++ API in its header files. That being said I'm not sure how many other projects would fall in such a bucket.
a0cc23b to
090ac38
Compare
|
Sounds reasonable to me, updated! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the merging of the C++ API into this repository in #10582 it opens up some interesting questions about how to organize the C++ API. Externally it was all entirely a single file, but naturally this isn't great for evolution as it's just one giant tangled header. Instead this commit sketches out a possible different path forward which is to provide the C++ API as a sibling to the C API in preexisting header files. For example this moves the
Errorclass to theerror.hheader file as an example.My rough hope would be that in the long-term we could deprecate/remove the
wasmtime.hhheader file and instead "just" have all the C++ APIs in the normal header files (e.g.wasmtime.h). Additionally the split of the C API in separate header files would be amenable to a similar split of the C++ API too where the API you see is basically conditional on the language mode of whatever's including the headers.I'll note though I've not seen prior art in doing this. I'm not aware of any other project which exports both a C and C++ API in its header files. That being said I'm not sure how many other projects would fall in such a bucket.