[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5605":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":24,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},5605,"cxx","dtolnay\u002Fcxx","dtolnay","Safe interop between Rust and C++","https:\u002F\u002Fcxx.rs",null,"Rust",6738,409,59,160,0,5,22,1,68.54,"Apache License 2.0",false,"master",true,[],"2026-06-12 04:00:25","CXX — safe FFI between Rust and C++\n=========================================\n\n[\u003Cimg alt=\"github\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fgithub-dtolnay\u002Fcxx-8da0cb?style=for-the-badge&labelColor=555555&logo=github\" height=\"20\">](https:\u002F\u002Fgithub.com\u002Fdtolnay\u002Fcxx)\n[\u003Cimg alt=\"crates.io\" src=\"https:\u002F\u002Fimg.shields.io\u002Fcrates\u002Fv\u002Fcxx.svg?style=for-the-badge&color=fc8d62&logo=rust\" height=\"20\">](https:\u002F\u002Fcrates.io\u002Fcrates\u002Fcxx)\n[\u003Cimg alt=\"docs.rs\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fdocs.rs-cxx-66c2a5?style=for-the-badge&labelColor=555555&logo=docs.rs\" height=\"20\">](https:\u002F\u002Fdocs.rs\u002Fcxx)\n[\u003Cimg alt=\"build status\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002Fdtolnay\u002Fcxx\u002Fci.yml?branch=master&style=for-the-badge\" height=\"20\">](https:\u002F\u002Fgithub.com\u002Fdtolnay\u002Fcxx\u002Factions?query=branch%3Amaster)\n\nThis library provides a **safe** mechanism for calling C++ code from Rust and\nRust code from C++, not subject to the many ways that things can go wrong when\nusing bindgen or cbindgen to generate unsafe C-style bindings.\n\nThis doesn't change the fact that 100% of C++ code is unsafe. When auditing a\nproject, you would be on the hook for auditing all the unsafe Rust code and\n*all* the C++ code. The core safety claim under this new model is that auditing\njust the C++ side would be sufficient to catch all problems, i.e. the Rust side\ncan be 100% safe.\n\n```toml\n[dependencies]\ncxx = \"1.0\"\n\n[build-dependencies]\ncxx-build = \"1.0\"\n```\n\n*Compiler support: requires rustc 1.85+ and c++11 or newer*\u003Cbr>\n*[Release notes](https:\u002F\u002Fgithub.com\u002Fdtolnay\u002Fcxx\u002Freleases)*\n\n\u003Cbr>\n\n## Guide\n\nPlease see **\u003Chttps:\u002F\u002Fcxx.rs>** for a tutorial, reference material, and example\ncode.\n\n\u003Cbr>\n\n## Overview\n\nThe idea is that we define the signatures of both sides of our FFI boundary\nembedded together in one Rust module (the next section shows an example). From\nthis, CXX receives a complete picture of the boundary to perform static analyses\nagainst the types and function signatures to uphold both Rust's and C++'s\ninvariants and requirements.\n\nIf everything checks out statically, then CXX uses a pair of code generators to\nemit the relevant `extern \"C\"` signatures on both sides together with any\nnecessary static assertions for later in the build process to verify\ncorrectness. On the Rust side this code generator is simply an attribute\nprocedural macro. On the C++ side it can be a small Cargo build script if your\nbuild is managed by Cargo, or for other build systems like Bazel or Buck we\nprovide a command line tool which generates the header and source file and\nshould be easy to integrate.\n\nThe resulting FFI bridge operates at zero or negligible overhead, i.e. no\ncopying, no serialization, no memory allocation, no runtime checks needed.\n\nThe FFI signatures are able to use native types from whichever side they please,\nsuch as Rust's `String` or C++'s `std::string`, Rust's `Box` or C++'s\n`std::unique_ptr`, Rust's `Vec` or C++'s `std::vector`, etc in any combination.\nCXX guarantees an ABI-compatible signature that both sides understand, based on\nbuiltin bindings for key standard library types to expose an idiomatic API on\nthose types to the other language. For example when manipulating a C++ string\nfrom Rust, its `len()` method becomes a call of the `size()` member function\ndefined by C++; when manipulating a Rust string from C++, its `size()` member\nfunction calls Rust's `len()`.\n\n\u003Cbr>\n\n## Example\n\nIn this example we are writing a Rust application that wishes to take advantage\nof an existing C++ client for a large-file blobstore service. The blobstore\nsupports a `put` operation for a discontiguous buffer upload. For example we\nmight be uploading snapshots of a circular buffer which would tend to consist of\n2 chunks, or fragments of a file spread across memory for some other reason.\n\nA runnable version of this example is provided under the *demo* directory of\nthis repo. To try it out, run `cargo run` from that directory.\n\n```rust\n#[cxx::bridge]\nmod ffi {\n    \u002F\u002F Any shared structs, whose fields will be visible to both languages.\n    struct BlobMetadata {\n        size: usize,\n        tags: Vec\u003CString>,\n    }\n\n    extern \"Rust\" {\n        \u002F\u002F Zero or more opaque types which both languages can pass around but\n        \u002F\u002F only Rust can see the fields.\n        type MultiBuf;\n\n        \u002F\u002F Functions implemented in Rust.\n        fn next_chunk(buf: &mut MultiBuf) -> &[u8];\n    }\n\n    unsafe extern \"C++\" {\n        \u002F\u002F One or more headers with the matching C++ declarations. Our code\n        \u002F\u002F generators don't read it but it gets #include'd and used in static\n        \u002F\u002F assertions to ensure our picture of the FFI boundary is accurate.\n        include!(\"demo\u002Finclude\u002Fblobstore.h\");\n\n        \u002F\u002F Zero or more opaque types which both languages can pass around but\n        \u002F\u002F only C++ can see the fields.\n        type BlobstoreClient;\n\n        \u002F\u002F Functions implemented in C++.\n        fn new_blobstore_client() -> UniquePtr\u003CBlobstoreClient>;\n        fn put(&self, parts: &mut MultiBuf) -> u64;\n        fn tag(&self, blobid: u64, tag: &str);\n        fn metadata(&self, blobid: u64) -> BlobMetadata;\n    }\n}\n```\n\nNow we simply provide Rust definitions of all the things in the `extern \"Rust\"`\nblock and C++ definitions of all the things in the `extern \"C++\"` block, and get\nto call back and forth safely.\n\nHere are links to the complete set of source files involved in the demo:\n\n- [demo\u002Fsrc\u002Fmain.rs](demo\u002Fsrc\u002Fmain.rs)\n- [demo\u002Fbuild.rs](demo\u002Fbuild.rs)\n- [demo\u002Finclude\u002Fblobstore.h](demo\u002Finclude\u002Fblobstore.h)\n- [demo\u002Fsrc\u002Fblobstore.cc](demo\u002Fsrc\u002Fblobstore.cc)\n\nTo look at the code generated in both languages for the example by the CXX code\ngenerators:\n\n```console\n   # run Rust code generator and print to stdout\n   # (requires https:\u002F\u002Fgithub.com\u002Fdtolnay\u002Fcargo-expand)\n$ cargo expand --manifest-path demo\u002FCargo.toml\n\n   # run C++ code generator and print to stdout\n$ cargo run --manifest-path gen\u002Fcmd\u002FCargo.toml -- demo\u002Fsrc\u002Fmain.rs\n```\n\n\u003Cbr>\n\n## Details\n\nAs seen in the example, the language of the FFI boundary involves 3 kinds of\nitems:\n\n- **Shared structs** — their fields are made visible to both languages.\n  The definition written within cxx::bridge is the single source of truth.\n\n- **Opaque types** — their fields are secret from the other language.\n  These cannot be passed across the FFI by value but only behind an indirection,\n  such as a reference `&`, a Rust `Box`, or a `UniquePtr`. Can be a type alias\n  for an arbitrarily complicated generic language-specific type depending on\n  your use case.\n\n- **Functions** — implemented in either language, callable from the other\n  language.\n\nWithin the `extern \"Rust\"` part of the CXX bridge we list the types and\nfunctions for which Rust is the source of truth. These all implicitly refer to\nthe `super` module, the parent module of the CXX bridge. You can think of the\ntwo items listed in the example above as being like `use super::MultiBuf` and\n`use super::next_chunk` except re-exported to C++. The parent module will either\ncontain the definitions directly for simple things, or contain the relevant\n`use` statements to bring them into scope from elsewhere.\n\nWithin the `extern \"C++\"` part, we list types and functions for which C++ is the\nsource of truth, as well as the header(s) that declare those APIs. In the future\nit's possible that this section could be generated bindgen-style from the\nheaders but for now we need the signatures written out; static assertions will\nverify that they are accurate.\n\nYour function implementations themselves, whether in C++ or Rust, *do not* need\nto be defined as `extern \"C\"` ABI or no\\_mangle. CXX will put in the right shims\nwhere necessary to make it all work.\n\n\u003Cbr>\n\n## Comparison vs bindgen and cbindgen\n\nNotice that with CXX there is repetition of all the function signatures: they\nare typed out once where the implementation is defined (in C++ or Rust) and\nagain inside the cxx::bridge module, though compile-time assertions guarantee\nthese are kept in sync. This is different from [bindgen] and [cbindgen] where\nfunction signatures are typed by a human once and the tool consumes them in one\nlanguage and emits them in the other language.\n\n[bindgen]: https:\u002F\u002Fgithub.com\u002Frust-lang\u002Frust-bindgen\n[cbindgen]: https:\u002F\u002Fgithub.com\u002Feqrion\u002Fcbindgen\u002F\n\nThis is because CXX fills a somewhat different role. It is a lower level tool\nthan bindgen or cbindgen in a sense; you can think of it as being a replacement\nfor the concept of `extern \"C\"` signatures as we know them, rather than a\nreplacement for a bindgen. It would be reasonable to build a higher level\nbindgen-like tool on top of CXX which consumes a C++ header and\u002For Rust module\n(and\u002For IDL like Thrift) as source of truth and generates the cxx::bridge,\neliminating the repetition while leveraging the static analysis safety\nguarantees of CXX.\n\nBut note in other ways CXX is higher level than the bindgens, with rich support\nfor common standard library types. Frequently with bindgen when we are dealing\nwith an idiomatic C++ API we would end up manually wrapping that API in C-style\nraw pointer functions, applying bindgen to get unsafe raw pointer Rust\nfunctions, and replicating the API again to expose those idiomatically in Rust.\nThat's a much worse form of repetition because it is unsafe all the way through.\n\nBy using a CXX bridge as the shared understanding between the languages, rather\nthan `extern \"C\"` C-style signatures as the shared understanding, common FFI use\ncases become expressible using 100% safe code.\n\nIt would also be reasonable to mix and match, using CXX bridge for the 95% of\nyour FFI that is straightforward and doing the remaining few oddball signatures\nthe old fashioned way with bindgen and cbindgen, if for some reason CXX's static\nrestrictions get in the way. Please file an issue if you end up taking this\napproach so that we know what ways it would be worthwhile to make the tool more\nexpressive.\n\n\u003Cbr>\n\n## Cargo-based setup\n\nFor builds that are orchestrated by Cargo, you will use a build script that runs\nCXX's C++ code generator and compiles the resulting C++ code along with any\nother C++ code for your crate.\n\nThe canonical build script is as follows. The indicated line returns a\n[`cc::Build`] instance (from the usual widely used `cc` crate) on which you can\nset up any additional source files and compiler flags as normal.\n\n[`cc::Build`]: https:\u002F\u002Fdocs.rs\u002Fcc\u002F1.0\u002Fcc\u002Fstruct.Build.html\n\n```toml\n# Cargo.toml\n\n[build-dependencies]\ncxx-build = \"1.0\"\n```\n\n```rust\n\u002F\u002F build.rs\n\nfn main() {\n    cxx_build::bridge(\"src\u002Fmain.rs\")  \u002F\u002F returns a cc::Build\n        .file(\"src\u002Fdemo.cc\")\n        .std(\"c++11\")\n        .compile(\"cxxbridge-demo\");\n\n    println!(\"cargo:rerun-if-changed=src\u002Fdemo.cc\");\n    println!(\"cargo:rerun-if-changed=include\u002Fdemo.h\");\n}\n```\n\n\u003Cbr>\n\n## Non-Cargo setup\n\nFor use in non-Cargo builds like Bazel or Buck, CXX provides an alternate way of\ninvoking the C++ code generator as a standalone command line tool. The tool is\npackaged as the `cxxbridge-cmd` crate on crates.io or can be built from the\n*gen\u002Fcmd* directory of this repo.\n\n```bash\n$ cargo install cxxbridge-cmd\n\n$ cxxbridge src\u002Fmain.rs --header > path\u002Fto\u002Fmybridge.h\n$ cxxbridge src\u002Fmain.rs > path\u002Fto\u002Fmybridge.cc\n```\n\n\u003Cbr>\n\n## Safety\n\nBe aware that the design of this library is intentionally restrictive and\nopinionated! It isn't a goal to be powerful enough to handle arbitrary\nsignatures in either language. Instead this project is about carving out a\nreasonably expressive set of functionality about which we can make useful safety\nguarantees today and maybe extend over time. You may find that it takes some\npractice to use CXX bridge effectively as it won't work in all the ways that you\nare used to.\n\nSome of the considerations that go into ensuring safety are:\n\n- By design, our paired code generators work together to control both sides of\n  the FFI boundary. Ordinarily in Rust writing your own `extern \"C\"` blocks is\n  unsafe because the Rust compiler has no way to know whether the signatures\n  you've written actually match the signatures implemented in the other\n  language. With CXX we achieve that visibility and know what's on the other\n  side.\n\n- Our static analysis detects and prevents passing types by value that shouldn't\n  be passed by value from C++ to Rust, for example because they may contain\n  internal pointers that would be screwed up by Rust's move behavior.\n\n- To many people's surprise, it is possible to have a struct in Rust and a\n  struct in C++ with exactly the same layout \u002F fields \u002F alignment \u002F everything,\n  and still not the same ABI when passed by value. This is a longstanding\n  bindgen bug that leads to segfaults in absolutely correct-looking code\n  ([rust-lang\u002Frust-bindgen#778]). CXX knows about this and can insert the\n  necessary zero-cost workaround transparently where needed, so go ahead and\n  pass your structs by value without worries. This is made possible by owning\n  both sides of the boundary rather than just one.\n\n- Template instantiations: for example in order to expose a UniquePtr\\\u003CT\\> type\n  in Rust backed by a real C++ unique\\_ptr, we have a way of using a Rust trait\n  to connect the behavior back to the template instantiations performed by the\n  other language.\n\n[rust-lang\u002Frust-bindgen#778]: https:\u002F\u002Fgithub.com\u002Frust-lang\u002Frust-bindgen\u002Fissues\u002F778\n\n\u003Cbr>\n\n## Builtin types\n\nIn addition to all the primitive types (i32 <=> int32_t), the following\ncommon types may be used in the fields of shared structs and the arguments and\nreturns of functions.\n\n\u003Ctable>\n\u003Ctr>\u003Cth>name in Rust\u003C\u002Fth>\u003Cth>name in C++\u003C\u002Fth>\u003Cth>restrictions\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>String\u003C\u002Ftd>\u003Ctd>rust::String\u003C\u002Ftd>\u003Ctd>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>&str\u003C\u002Ftd>\u003Ctd>rust::Str\u003C\u002Ftd>\u003Ctd>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>&[T]\u003C\u002Ftd>\u003Ctd>rust::Slice<const T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque C++ type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>&mut [T]\u003C\u002Ftd>\u003Ctd>rust::Slice<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque C++ type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fdocs.rs\u002Fcxx\u002F1.0\u002Fcxx\u002Fstruct.CxxString.html\">CxxString\u003C\u002Fa>\u003C\u002Ftd>\u003Ctd>std::string\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot be passed by value\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Box<T>\u003C\u002Ftd>\u003Ctd>rust::Box<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque C++ type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fdocs.rs\u002Fcxx\u002F1.0\u002Fcxx\u002Fstruct.UniquePtr.html\">UniquePtr<T>\u003C\u002Fa>\u003C\u002Ftd>\u003Ctd>std::unique_ptr<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque Rust type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fdocs.rs\u002Fcxx\u002F1.0\u002Fcxx\u002Fstruct.SharedPtr.html\">SharedPtr<T>\u003C\u002Fa>\u003C\u002Ftd>\u003Ctd>std::shared_ptr<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque Rust type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>[T; N]\u003C\u002Ftd>\u003Ctd>std::array<T, N>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque C++ type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Vec<T>\u003C\u002Ftd>\u003Ctd>rust::Vec<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot hold opaque C++ type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fdocs.rs\u002Fcxx\u002F1.0\u002Fcxx\u002Fstruct.CxxVector.html\">CxxVector<T>\u003C\u002Fa>\u003C\u002Ftd>\u003Ctd>std::vector<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>cannot be passed by value, cannot hold opaque Rust type\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>*mut T, *const T\u003C\u002Ftd>\u003Ctd>T*, const T*\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>fn with a raw pointer argument must be declared unsafe to call\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>fn(T, U) -> V\u003C\u002Ftd>\u003Ctd>rust::Fn<V(T, U)>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>only passing from Rust to C++ is implemented so far\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Result<T>\u003C\u002Ftd>\u003Ctd>throw\u002Fcatch\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>allowed as return type only\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\nThe C++ API of the `rust` namespace is defined by the *include\u002Fcxx.h* file in\nthis repo. You will need to include this header in your C++ code when working\nwith those types.\n\nThe following types are intended to be supported \"soon\" but are just not\nimplemented yet. I don't expect any of these to be hard to make work but it's a\nmatter of designing a nice API for each in its non-native language.\n\n\u003Ctable>\n\u003Ctr>\u003Cth>name in Rust\u003C\u002Fth>\u003Cth>name in C++\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>BTreeMap<K, V>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>tbd\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>HashMap<K, V>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>tbd\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Arc<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>tbd\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Option<T>\u003C\u002Ftd>\u003Ctd>\u003Csup>\u003Ci>tbd\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Csup>\u003Ci>tbd\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003Ctd>std::map<K, V>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Csup>\u003Ci>tbd\u003C\u002Fi>\u003C\u002Fsup>\u003C\u002Ftd>\u003Ctd>std::unordered_map<K, V>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\n\u003Cbr>\n\n## Remaining work\n\nThis is still early days for CXX; I am releasing it as a minimum viable product\nto collect feedback on the direction and invite collaborators. Please check the\nopen issues.\n\nEspecially please report issues if you run into trouble building or linking any\nof this stuff. I'm sure there are ways to make the build aspects friendlier or\nmore robust.\n\nFinally, I know more about Rust library design than C++ library design so I\nwould appreciate help making the C++ APIs in this project more idiomatic where\nanyone has suggestions.\n\n\u003Cbr>\n\n#### License\n\n\u003Csup>\nLicensed under either of \u003Ca href=\"LICENSE-APACHE\">Apache License, Version\n2.0\u003C\u002Fa> or \u003Ca href=\"LICENSE-MIT\">MIT license\u003C\u002Fa> at your option.\n\u003C\u002Fsup>\n\n\u003Cbr>\n\n\u003Csub>\nUnless you explicitly state otherwise, any contribution intentionally submitted\nfor inclusion in this project by you, as defined in the Apache-2.0 license,\nshall be dual licensed as above, without any additional terms or conditions.\n\u003C\u002Fsub>\n","CXX 是一个用于Rust和C++之间安全互操作的库。它通过提供一种安全机制来调用C++代码从Rust中，反之亦然，从而避免了使用bindgen或cbindgen生成不安全C风格绑定时可能出现的问题。CXX的核心功能包括静态分析类型和函数签名以确保Rust和C++的不变性和要求，并且在编译时生成必要的`extern \"C\"`签名及静态断言以验证正确性。该库适合需要高效、安全地集成Rust与C++代码的项目场景，如游戏开发、高性能计算等领域。CXX支持Rust 1.85及以上版本以及C++11或更新版本。",2,"2026-06-11 03:04:19","top_language"]