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
Nunavut should code-generate C++ serialization functions that do a simple memcpy when possible. This would only be possible where the underlying architecture is compatible with the Cyphal serialization in certain ways (such as endianness, alignment, etc.) Also it may not be possible to do this with certain types of messages such as those that contain variable length arrays. In these cases the generated C++ uses std::vector or CETL VariableLengthArray and their memory layout would not match Cyphal's specified serialization due to having private bookkeeping members (allocator, capacity, size, max size.)
Perhaps it would also be good to provide some kind of DSDL annotation to assert that a message is compatible with zero-cost serialization. The goal would be for users to be able to say "Here's my carefully crafted set of DSDLs that I want to make sure are zero-cost. These other DSDL's I don't care if that's the case."
Nunavut should code-generate C++ serialization functions that do a simple memcpy when possible. This would only be possible where the underlying architecture is compatible with the Cyphal serialization in certain ways (such as endianness, alignment, etc.) Also it may not be possible to do this with certain types of messages such as those that contain variable length arrays. In these cases the generated C++ uses std::vector or CETL VariableLengthArray and their memory layout would not match Cyphal's specified serialization due to having private bookkeeping members (allocator, capacity, size, max size.)
Perhaps it would also be good to provide some kind of DSDL annotation to assert that a message is compatible with zero-cost serialization. The goal would be for users to be able to say "Here's my carefully crafted set of DSDLs that I want to make sure are zero-cost. These other DSDL's I don't care if that's the case."
Here are some related Cyphal items with additional context:
#285
OpenCyphal/pydsdl#24
The text was updated successfully, but these errors were encountered: