1
0
mirror of https://github.com/google/comprehensive-rust.git synced 2025-04-13 04:30:31 +02:00

Chromium: Enumerate automation benefits of cxx + other minor tweaks. ()

This commit is contained in:
Lukasz Anforowicz 2023-12-01 08:24:59 +00:00 committed by GitHub
parent c7fb26fe0e
commit f3e045ddf4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 33 additions and 10 deletions
src/chromium

@ -19,9 +19,32 @@ See the [CXX tutorial][1] for a full example of using this.
<details>
Talk through the diagram. Explain that behind the scenes, this is doing
just the same as you previously did --- but by programmatically ensuring that
the C++ and Rust sides match, cxx can ensure there aren't obvious errors
with object lifetimes, string lengths, etc. It reduces lots of fiddly
boilerplate and the resulting code feels more "natural".
just the same as you previously did. Point out that automating the process has
the following benefits:
* The tool guarantees that the C++ and Rust sides match
(e.g. you get compile errors if the `#[cxx::bridge]` doesn't match the actual
C++ or Rust definitions, but with out-of-sync manual bindings you'd get
Undefined Behavior)
* The tool automates generation of FFI thunks (small, C-ABI-compatible, free
functions) for non-C features
(e.g. enabling FFI calls into Rust or C++ methods;
manual bindings would require authoring such top-level, free functions
manually)
* The tool and the library can handle a set of core types - for example:
- `&[T]` can be passed across the FFI boundary, even though it doesn't
guarantee any particular ABI or memory layout. With manual bindings
`std::span<T>` / `&[T]` have to be manually destructured and rebuilt out
of a pointer and length - this is error-prone given that each language
represents empty slices slightly differently)
- Smart pointers like `std::unique_ptr<T>`,
`std::shared_ptr<T>`, and/or `Box` are natively supported. With manual
bindings, one would have to pass C-ABI-compatible raw pointers, which
would increase lifetime and memory-safety risks.
- `rust::String` and `CxxString` types understand and maintain differences
in string representation across the languages (e.g. `rust::String::lossy`
can build a Rust string from non-UTF8 input and `rust::String::c_str`
can NUL-terminate a string).
</details>

@ -1,23 +1,23 @@
# Example bindings
cxx requires you to declare the whole C++/Rust boundary in one of your `.rs`
files. For instance:
cxx requires that the whole C++/Rust boundary is declared in `cxx::bridge`
"modules" inside `.rs` source code.
```rust,ignore
{{#include ../../../third_party/cxx/book/snippets.rs:cxx_overview}}
```
<details>
Point out:
* Native support for C++'s `std::unique_ptr` in Rust
* Native support for Rust slices in C++
* Calls from C++ to Rust, and Rust types (in the top part)
* Calls from Rust to C++, and C++ types (in the bottom part)
* If the function definitions in C++ or Rust don't match the cxx::bridge,
a compilation failure results.
**Common misconception**: It _looks_ like a C++ header is being parser by Rust,
**Common misconception**: It _looks_ like a C++ header is being parsed by Rust,
but this is misleading. This header is never interpreted by Rust, but simply
`#include`d in the generated C++ code for the benefit of C++ compilers.
</details>
</details>