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
Complex struct should be #repr(C) #79
Comments
It's more complicated than that, C's complex type needs its own handling in the C ABI and rust can't do that yet. See RFC issue here: rust-lang/rfcs/issues/793 That said, the representation is the same when it comes to accessing complex numbers in memory, so for example BLAS bindings still work with it as it is today: it's only complex by-value function parameters and return values that are not c-compatible as it is now. Due to being usable with ffi when accessed behind a pointer, I think it would be good to mark it |
Any chance of this happening? Even when numbers are passed by value, AFAIC tell most modern platforms also use this representation. Would you need a PR? |
I'm really hesitant to add this with such documented limitations. People are prone to ignoring that sort of thing until it blows up in their face. Maybe it could be added just for the known-good architectures with Another possibility is to solve it in the hypothetical |
I'd disagree. When interfacing with certain numeric centric libraries with C-ABI, interfacing with
This does not involve the It would be super nice, if we could interface directly with the C |
OK, if |
Could anyone link the section of C99 standard that describes memory layout of |
@hauleth See my post above. |
@fkjogu ok. So now we need to be sure that our struct with |
The memory layout is one thing, but the ABI for complex parameters is certainly implementation defined. |
FWIW, it's easy to approximate this, if you want to deal with ABI on your own: #[repr(C)]
struct c_complex_double([f64; 2]);
impl From<Complex64> for c_complex_double {
fn from(c: Complex64) -> Self {
c_complex_double([c.re, c.im])
}
}
impl From<c_complex_double> for Complex64 {
fn from(c: c_complex_double) -> Self {
Complex64::new(c.0[0], c.0[1])
}
} |
@cuviper Good point. But I'm not sure, what Also I'm never sure what consequences this type of copy conversation has on performance in real applications. Definitely more, than just passing a pointer, for some amount of more. |
I don't know about guarantees, but tuple structs should be transparent as long as you don't implement something like
Besides, you can only attach As for the performance of copy conversions, I'd expect it to have negligible overhead. This is completely transparent to the optimizer, so in some cases the copies might be avoided entirely. I would avoid conversions back and forth in the loop of a math kernel though. |
If it does not have #[repr(C)], then crates will need to migrate off using num's complex. It would be unsound (strictly speaking, but in practice not a problem) for numerical projects to use num's complex when integrating with complex-consuming libraries like BLAS. |
I think that's overstated. It just means crates just shouldn't use
Adding That said, I think I can relent. It doesn't look like |
Great. Using a different type for ffi would mean using a different type all the time. (Converting an ndarray of thousands of entries is not done for free, can't do that just to call a function.) |
Regarding |
Complex: Use repr(C) and add documentation for what it means Here's an ambitious proposal that puts currently practiced ffi usage of `Complex<f32/f64>` on sound footing. Fixes #79 Current users appear to be: - https://crates.io/crates/blas + Their use is not about Complex<f64> in an extern function's signature, but it is explicitly using that it is memory layout compatible.
The memory layout is probably already identical to C's complex type or
std::complex<T>
, but it'd be nice to make it explicit. This would help with C interop, and things like real-only FFTs that need to cast real-only vectors into vectors of alternating real/imaginary.The text was updated successfully, but these errors were encountered: