Open ShoreFlower opened 6 months ago
I'm not an expert of C++, but maybe try adding .data()
at the end:
std::memcpy(PointCloud2.data.data(), output_data, output_data_len);
From memory alone, I think that PointCloud2.data
is a standard vector in C++
https://chat.openai.com/c/c42af36d-9385-4db5-a168-c1337d570335
p.s: note that you can use ```c++ for syntax highlighting
See https://cxx.rs/binding/vec.html for the type definition of rust::Vec<T>
. While it's similar to a std::vector
, it's a different type without any direction conversion. Unfortunately, I don't see any more efficient way to push multiple values either.
std::memcpy(PointCloud2.data.data(), output_data, output_data_len);
This is unsafe and will lead to undefined behavior if output_data_len
is greater than PointCloud2.data.size()
.
A possible solution could be to generate two versions of each message type: one based on Rust types and one based on C++ types. The version based on C++ types would then contain normal std::vector
fields instead of rust::Vec
. Subscribe methods would only support the version based on Rust-types, but publish methods could support both types. The drawback is that it duplicates all message types, which could be confusing. What do you think about this approach @ShoreFlower?
I don't think this is a good approach.
---- 回复的原邮件 ---- | 发件人 | Philipp @.> | | 日期 | 2024年04月03日 19:30 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [dora-rs/dora] 类型 char 转化为 ::rust::Vec<::std::uint8_t> 的问题。The problem of converting type char to ::rust::Vec<::std::uint8_t>. (Issue #444) |
See https://cxx.rs/binding/vec.html for the type definition of rust::Vec
std::memcpy(PointCloud2.data.data(), output_data, output_data_len);
This is unsafe and will lead to undefined behavior if output_data_len is greater than PointCloud2.data.size().
A possible solution could be to generate two versions of each message type: one based on Rust types and one based on C++ types. The version based on C++ types would then contain normal std::vector fields instead of rust::Vec. Subscribe methods would only support the version based on Rust-types, but publish methods could support both types. The drawback is that it duplicates all message types, which could be confusing. What do you think about this approach @ShoreFlower?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
To avoid the boilerplate of the for
loop, you should be able to use back_inserter
together with std::copy
.
Doing a pointer copy would require a public set_len
method, which is being discussed upstream. However, apparently such a function isn't even available for the standard C++ vector
type.
If you're concerned about efficiency, you should try doing a benchmark with link-time optimization enabled. I can imagine that the compiler/linker optimizes the for
loop and push_back
calls to some quite efficient code.
To make the push_back
operation cheap you can call reserve
with the required capacity beforehand. Then no reallocation is required anymore.
Thank you for your answer, for having used std::copy
can solve the data problem.
std::copy(output_data + 16, output_data + output_data_len, std::back_inserter(PointCloud2.data));
在应用ROS消息类型的时候存在字节转化问题,临时使用的
for
循环转化,效率较低,请问有比较高效的方式么?比如直接copy指针,C++提供的copy无法执行。When using ROS message types, there is a byte conversion issue. The temporary solution is to use a for loop for conversion, which is inefficient. Is there a more efficient way, such as directly copying pointers? The copy provided by C++ does not work.
bug code
all code