gpt4 book ai didi

rust - 如何安全地将 Vec 重新解释为大小减半的 Vec>?

转载 作者:行者123 更新时间:2023-11-29 07:46:02 24 4
gpt4 key购买 nike

我将复数数据填充到 Vec<f64> 中通过外部 C 库(最好不要更改),形式为 [i_0_real, i_0_imag, i_1_real, i_1_imag, ...]看起来这个 Vec<f64>Vec<num_complex::Complex<f64>> 具有相同的内存布局鉴于 num_complex::Complex<f64>,一半的长度将是的数据结构与 [f64; 2] 的内存布局兼容。如记录here .我想这样使用它而不需要重新分配可能很大的缓冲区。

我假设使用 from_raw_parts() 是有效的在std::vec::Vec伪造一个新的 Vec拥有旧 Vec 的所有权的内存(通过忘记旧的 Vec )并使用 size / 2capacity / 2 ,但这需要不安全的代码。是否有一种“安全”的方式来进行这种数据重新解释?

Vec在 Rust 中分配为 Vec<f64>并由使用 .as_mut_ptr() 的 C 函数填充填写 Vec<f64> .

我当前的编译不安全实现:

extern crate num_complex;

pub fn convert_to_complex_unsafe(mut buffer: Vec<f64>) -> Vec<num_complex::Complex<f64>> {
let new_vec = unsafe {
Vec::from_raw_parts(
buffer.as_mut_ptr() as *mut num_complex::Complex<f64>,
buffer.len() / 2,
buffer.capacity() / 2,
)
};
std::mem::forget(buffer);
return new_vec;
}

fn main() {
println!(
"Converted vector: {:?}",
convert_to_complex_unsafe(vec![3.0, 4.0, 5.0, 6.0])
);
}

最佳答案

Is there a "safe" way to do this kind of data re-interpretation?

没有。至少,这是因为您需要了解的信息并未在 Rust 类型系统中表达,而是通过散文(又名文档)表达:

Complex<T> is memory layout compatible with an array [T; 2].

Complex docs

If a Vec has allocated memory, then [...] its pointer points to len initialized, contiguous elements in order (what you would see if you coerced it to a slice),

Vec docs

Arrays coerce to slices ([T])

Array docs

Complex与数组内存兼容,数组的数据与切片内存兼容,Vec的数据与切片内存兼容,此转换应该是安全的,即使编译器无法告知这一点。

此信息应附加(通过注释)到您的不安全 block 。

对您的函数做一些小的调整:

  • 有两个Vec同时指向相同的数据让我非常紧张。通过引入一些变量并在创建另一个变量之前忘记一个变量,可以轻松避免这种情况。

  • 删除 return关键字更地道

  • 添加一些断言数据的起始长度是二的倍数。

  • 作为rodrigo points out ,容量很容易是奇数。为了避免这种情况,我们调用 shrink_to_fit .这有一个缺点,即 Vec 可能需要重新分配和复制内存,具体取决于实现情况。

  • 展开 unsafe block 以覆盖确保维护安全不变量所需的所有相关代码。

pub fn convert_to_complex(mut buffer: Vec<f64>) -> Vec<num_complex::Complex<f64>> {
// This is where I'd put the rationale for why this `unsafe` block
// upholds the guarantees that I must ensure. Too bad I
// copy-and-pasted from Stack Overflow without reading this comment!
unsafe {
buffer.shrink_to_fit();

let ptr = buffer.as_mut_ptr() as *mut num_complex::Complex<f64>;
let len = buffer.len();
let cap = buffer.capacity();

assert!(len % 2 == 0);
assert!(cap % 2 == 0);

std::mem::forget(buffer);

Vec::from_raw_parts(ptr, len / 2, cap / 2)
}
}

为了避免所有关于容量的担忧,您可以将切片转换为 Vec .这也没有任何额外的内存分配。它更简单,因为我们可以“丢失”任何奇数尾随值,因为 Vec仍然维护它们。

pub fn convert_to_complex(buffer: &[f64]) -> &[num_complex::Complex<f64>] {
// This is where I'd put the rationale for why this `unsafe` block
// upholds the guarantees that I must ensure. Too bad I
// copy-and-pasted from Stack Overflow without reading this comment!
unsafe {
let ptr = buffer.as_ptr() as *const num_complex::Complex<f64>;
let len = buffer.len();

assert!(len % 2 == 0);

std::slice::from_raw_parts(ptr, len / 2)
}
}

关于rust - 如何安全地将 Vec<f64> 重新解释为大小减半的 Vec<num_complex::Complex<f64>>?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54185667/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com