Unify and simplify de/serializeROSmessage processing

[jwang11]

For most type_id, there is no difference for serialization which can be unified in a common template function. However, for bool and string, there is extra check or logic for normal but array does not. Although it is weird, this commit keep the logic intact.

Signed-off-by: jwang jing.j.wang@intel.com

[mikaelarguedas]

This is a follow up of #168 now that most of the logic for array has been simplified and magic numbers removed.

Thanks @jwang11 we'll try to get this reviewed soon

[mikaelarguedas]

Although it is weird, this commit keep the logic intact.

Yes this extra logic is necessary, thanks for keeping it as is.

• Linux
• Linux-aarch64
• macOS
• Windows

[mikaelarguedas]

lgtm

[mikaelarguedas]

While it's counter intuitive to call (de)serializeArray for non array types I appreciate the code deduplication.

I'll leave a chance to @ros2/team to voice any concern before merging

[dirk-thomas]

Before the code was calling the following for non-array fields:

ser << *static_cast<uint8_t *>(field);

With the patch it is calling this line instead:

ser.serializeArray(static_cast<uint8_t *>(field), 1);

I don't think we can rely on them being equivalent without making assumptions about how serializeArray is implemented. And that could change anytime. Therefore this change doesn't look like a good idea to me.

[jwang11]

ser.serializeArray(static_cast<uint8_t *>(field), 1);

Ok, If it introduce the dependency on specific FastRTPS implementation, I can update the commit to handle non-array type separately, but still in same function.

[jwang11]

Code updated. Separate the process for single field and array according to comments, consolidate them in central function which obviously help code deduplication.

[dirk-thomas]

• Linux
• Linux-aarch64
• macOS
• Windows

[dirk-thomas]

Thank you for improving the code.