Skip to content
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

init and fini function for creating introspection messages #416

Merged
merged 5 commits into from
Oct 18, 2019

Conversation

Karsten1987
Copy link
Contributor

connects to ros2/ros2#785
fixes #404

Signed-off-by: Karsten Knese karsten@openrobotics.org

With this PR, one can create a ROS message solely by providing the rosidl_typesupport_introspection_<c|cpp>.

depicted below for C, works analog to this in C++

  auto string_typesupports =
    ROSIDL_GET_MSG_TYPE_SUPPORT(std_msgs, msg, String);
  auto string_ts_c = get_message_typesupport_handle(string_typesupports, rosidl_typesupport_introspection_c__identifier);
  auto introspection_ts = static_cast<const rosidl_typesupport_introspection_c__MessageMembers *>(string_ts_c->data);
  void * message_memory = malloc(introspection_ts->size_of_);
  introspection_ts->init_function(message_memory, true);
  std_msgs__msg__String msg = *static_cast<std_msgs__msg__String *>(message_memory);
  rosidl_generator_c__String__assign(&msg.data, "Hello world!");
  introspection_ts->fini_function(message_memory);
  free(message_memory);
  message_memory = nullptr;

Question: I know that in C we can specify whether the data structure should be default initialized or not. Hence the second bool parameter for the init function. However, looking at the initializer functions for the C datatype, I haven't found any way to specify that. How do I do that?

@@ -49,6 +49,17 @@ namespace @(ns)
namespace rosidl_typesupport_introspection_cpp
{

void init_function__@(message.structure.namespaced_type.name)(void * message_memory, bool default_initialize)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The constructor of C++ message classes uses more than a bool to determine how to initialize the values (see

explicit @(message.structure.namespaced_type.name)_(rosidl_generator_cpp::MessageInitialization _init = rosidl_generator_cpp::MessageInitialization::ALL)
). Why shouldn't this signature offer the same?

Also atm the argument doesn't seem to be used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct, I've used a bool as a placeholder because I wasn't exactly aware of the right datastructure/enum to use for the initializers. I'll change that accordingly.
After talking with @clalancette, the default initializers are only yet implemented in C++. I'll change the API for the C datatypes accordingly though to accept a enum as described here: https://github.com/ros2/rosidl/blob/master/rosidl_generator_c/include/rosidl_generator_c/message_initialization.h#L20

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 319d6c7

@@ -132,7 +143,7 @@ for index, member in enumerate(message.structure.members):
# size_t string_upper_bound
print(' 0, // upper bound of string')
# const rosidl_generator_c::MessageTypeSupportHandle * members_
print(' NULL, // members of sub message')
print(' nullptr, // members of sub message')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems unrelated?

Same below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is unrelated, but given that it's really just a two line change, I believe it can be changed within the scope of this PR as well.
I don't have any problem reverting this change here though if preferred.

@(function_prefix)__@(message.structure.namespaced_type.name)_message_member_array // message members
@(function_prefix)__@(message.structure.namespaced_type.name)_message_member_array, // message members
@(function_prefix)__init_function, // function to initialize message memory (memory has to be allocated)
@(function_prefix)__fini_function // function to terminate message instance (will not free memory)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why these functions don't use _@(message.structure.namespaced_type.name) as the other symbols?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 71404ca

@(message.structure.namespaced_type.name)_message_member_array // message members
@(message.structure.namespaced_type.name)_message_member_array, // message members
init_function__@(message.structure.namespaced_type.name), // function to initialize message memory (memory has to be allocated)
fini_function__@(message.structure.namespaced_type.name) // function to terminate message instance (will not free memory)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why these functions use the opposite order of message name and hard coded name parts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 71404ca

@dirk-thomas
Copy link
Member

fixes #404

That tickets mentions message allocation atm. Either it needs to be changed (see also the pending question #404 (comment)) or this PR addresses something different.

@Karsten1987
Copy link
Contributor Author

Karsten1987 commented Oct 2, 2019

first round of CI (using fastrtps dynamic as they make use of typesupport introspection):

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@Karsten1987
Copy link
Contributor Author

new round of CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@Karsten1987
Copy link
Contributor Author

I put that up for another round of reviews.
CI on MS fails because of connectivity errors.

Copy link
Member

@dirk-thomas dirk-thomas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more minor comment inline.

LGTM with passing CI.

void @(function_prefix)__@(message.structure.namespaced_type.name)_init_function(
void * message_memory, enum rosidl_runtime_c_message_initialization _init)
{
// initializers are not yet implemented for typesupport c
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a TODO here.

@Karsten1987
Copy link
Contributor Author

re-running windows only:
Build Status

@Karsten1987
Copy link
Contributor Author

ms warnings seem unrelated.

Signed-off-by: Karsten Knese <karsten@openrobotics.org>
Signed-off-by: Karsten Knese <karsten@openrobotics.org>
Signed-off-by: Karsten Knese <karsten@openrobotics.org>
Signed-off-by: Karsten Knese <karsten@openrobotics.org>
Signed-off-by: Karsten Knese <karsten@openrobotics.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Initialize generic typesupport_introspection_cpp message
3 participants