You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's not much we can use there to deduce the existence of a virtual function on the A and B types. The parameter to the foo functions is not helpful.
Ideally we'd modify autocxx-bindgen to indicate that certain functions are virtual functions (adding to the list in #124). As a gross hack, we could assume that the output ordering is such that a this: *mut ::std::os::raw::c_void parameter represents the previously encountered virtual struct.
However we identify these virtual functions, we should not attempt to call them in Rust. Instead, we should always generate a FunctionWrapper for such calls, which will use -> on the std::unique_ptr and thus end up calling the right overridden version of the function, without any daft vtable interpretation on the Rust side. We'd need to make suitable entries in the impl blocks. And we'd want to do the same for any derived types, even if they didn't themselves implement the function.
The text was updated successfully, but these errors were encountered:
Currently there's no way to call virtual functions.
integration_tests::test_virtual_fns
does not actually call virtual functions; it just checks they don't break other things.For this test code:
bindgen
generates:There's not much we can use there to deduce the existence of a virtual function on the
A
andB
types. The parameter to thefoo
functions is not helpful.Ideally we'd modify
autocxx-bindgen
to indicate that certain functions are virtual functions (adding to the list in #124). As a gross hack, we could assume that the output ordering is such that athis: *mut ::std::os::raw::c_void
parameter represents the previously encountered virtual struct.However we identify these virtual functions, we should not attempt to call them in Rust. Instead, we should always generate a
FunctionWrapper
for such calls, which will use->
on thestd::unique_ptr
and thus end up calling the right overridden version of the function, without any daft vtable interpretation on the Rust side. We'd need to make suitable entries in theimpl
blocks. And we'd want to do the same for any derived types, even if they didn't themselves implement the function.The text was updated successfully, but these errors were encountered: