autocxx
autocxx copied to clipboard
google
Tool for safe ergonomic Rust/C++ interop driven from existing C++ headers
`cxx` allows C++ functions which return references, but only if they take exactly one reference parameter (since then the lifetimes are obvious). As our hope is to handle existing C++...
A follow up from #93, much harder. We need to figure out how to expose C++ constants which are types that cannot be represented in Rust by value. We probably...
We should support C++ string constants. We already support int constants. Later today I will commit an `#[ignore]`d test for this, `integration_tests::test_pod_constant`. `bindgen` does output the constant, like this: ```rust...
There are some C++ types where `autocxx` just says "nope, we can't pass it by value" - `autocxx` calls these non-POD types; `cxx` calls them `Opaque` (see #17 for the...
When running against a codebase using `std::option::Option`, I get: ``` Ignored item discovered whilst parsing: autocxx does not yet know how to support the built-in C++ type std::option::Option - please...
`autocxx-bindgen` now outputs attrtibutes to indicate whether function parameters and return types are references, as opposed to pointers. We don't attempt to output any such attributes for `typedefs`. We should....
Versions of cxx prior to 1.0 and versions of autocxx prior to 0.5 do not require an `unsafe` keyword. That policy changes with 1.0 and 0.5 respectively, such that at...
After #76 we will still have a bit more namespace work to do. The final output structure should be correct, but within our internal `cxxbridge` mod we'll still have a...
Right now, autocxx uses the words "POD" and "non-POD" a lot. cxx now calls this 'trivial' and 'opaque'. We should achieve consistency by renaming everything to match.