Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support unboxed opaque types that are Copy #103

Open
TheButlah opened this issue May 3, 2022 · 0 comments
Open

Support unboxed opaque types that are Copy #103

TheButlah opened this issue May 3, 2022 · 0 comments
Labels
K-feature Kind: proposed new code to implement new behaviour

Comments

@TheButlah
Copy link
Contributor

TheButlah commented May 3, 2022

It would be cool if there was support for safer_ffi opaque types that don't require boxing because they are Copy. Ostensibly, one could just look at the size and alignment of the type and create a C type with the same layout. This is what autocxx does and it seems to work well:

Generated rust code:

#[repr(C, align(4))]
pub struct HmdMatrix34_t {
    _pinned: core::marker::PhantomData<core::marker::PhantomPinned>,
    _non_send_sync: core::marker::PhantomData<[*const u8; 0]>,
    _data: [u8; 48],
}

Corresponding C/C++ POD type:

struct HmdMatrix34_t
{
	float m[3][4];
};

I'm assuming that this solution won't work for non-copy types (implying that they have a drop fn and cannot be memcopied), but in my API I have a bunch of opaque types that are Copy, and I'l really like to avoid boxing all of them, and having the caller have to allocate and drop them all the time

@danielhenrymantilla danielhenrymantilla added the K-feature Kind: proposed new code to implement new behaviour label May 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
K-feature Kind: proposed new code to implement new behaviour
Projects
None yet
Development

No branches or pull requests

2 participants