macro_rules! extern_cpp_type {
($($tt:tt)*) => { ... };
}
Expand description
Indicates that a C++ type is not to be generated by autocxx in this case, but instead should refer to some pre-existing Rust type.
If you wish for the type to be POD, you can use a pod!
directive too
(but see the “requirements” section below).
The syntax is:
extern_cpp_type!("CppNameGoesHere", path::to::rust::type)
Generally speaking, this should be used only to refer to types
generated elsewhere by autocxx
or cxx
to ensure that they meet
all the right requirements. It’s possible - but fragile - to
define such types yourself.
§Requirements for externally defined Rust types
It’s generally expected that you would make such a type
in Rust using a separate include_cpp!
macro, or
a manual #[cxx::bridge]
directive somehwere. That is, this
directive is intended mainly for use in cross-linking different
sets of bindings in different mods, rather than truly to point to novel
external types.
But with that in mind, here are the requirements you must stick to.
For non-POD external types:
- The size and alignment of this type must be correct.
For POD external types:
- As above
- Your type must correspond to the requirements of
cxx::kind::Trivial
. In general, that means, no move constructor and no destructor. If you generate this type usingcxx
itself (orautocxx
) this will be enforced usingstatic_assert
s within the generated C++ code. Without using those tools, you’re on your own for determining this… and it’s hard because the presence of particular fields or base classes may well result in your type violating those rules.
A directive to be included inside include_cpp - see include_cpp for general information.