export for the event type support function#747
export for the event type support function#747iuhilnehc-ynos wants to merge 1 commit intoros2:rollingfrom
Conversation
Signed-off-by: Chen Lihui <lihui.chen@sony.com>
|
which is different from rosidl_runtime_c using a macro to call the function, I wonder if it's necessary to add the declaration for each message/service in the header file by rosidl_generator_cpp.
#include "rosidl_typesupport_cpp/message_type_support.hpp"
#ifdef __cplusplus
extern "C"
{
#endif
// Forward declare the get type support functions for this type.
ROSIDL_GENERATOR_CPP_PUBLIC_example_interfaces
const rosidl_message_type_support_t *
ROSIDL_TYPESUPPORT_INTERFACE__MESSAGE_SYMBOL_NAME(
rosidl_typesupport_cpp,
example_interfaces,
srv,
AddTwoInts_Request
)();
#ifdef __cplusplus
}
#endif
// already included above
// #include "rosidl_typesupport_cpp/message_type_support.hpp"
#ifdef __cplusplus
extern "C"
{
#endif
// Forward declare the get type support functions for this type.
ROSIDL_GENERATOR_CPP_PUBLIC_example_interfaces
const rosidl_message_type_support_t *
ROSIDL_TYPESUPPORT_INTERFACE__MESSAGE_SYMBOL_NAME(
rosidl_typesupport_cpp,
example_interfaces,
srv,
AddTwoInts_Response
)();
#ifdef __cplusplus
}
#endifAs we know, the definition of messages std::string symbol_name = typesupport_identifier + "__get_message_type_support_handle__" +
package_name + "__" + (middle_module.empty() ? "msg" : middle_module) + "__" + type_name;
const rosidl_message_type_support_t * (* get_ts)() = nullptr;
// This will throw runtime_error if the symbol was not found.
get_ts = reinterpret_cast<decltype(get_ts)>(library.get_symbol(symbol_name));My question is, |
|
I think it's not good to add #define ROSIDL_GET_MSG_TYPE_SUPPORT_CPP(PkgName, MsgSubfolder, MsgName) \
ROSIDL_TYPESUPPORT_INTERFACE__MESSAGE_SYMBOL_NAME( \
rosidl_typesupport_cpp, PkgName, MsgSubfolder, MsgName)()in |
fujitatomoya
left a comment
There was a problem hiding this comment.
I think this can be added along with response and request message types.
it is doable, but the difference is between compile time and runtime? i might be mistaken. |
Yes, but no. Let me take a generated service typesupport in cpp as an example,
namespace rosidl_typesupport_cpp
{
template<>
ROSIDL_TYPESUPPORT_CPP_PUBLIC
const rosidl_service_type_support_t *
get_service_type_support_handle<example_interfaces::srv::AddTwoInts>()
{
return &::example_interfaces::srv::rosidl_typesupport_cpp::AddTwoInts_service_type_support_handle;
}
} // namespace rosidl_typesupport_cpp
#ifdef __cplusplus
extern "C"
{
#endif
ROSIDL_TYPESUPPORT_CPP_PUBLIC
const rosidl_service_type_support_t *
ROSIDL_TYPESUPPORT_INTERFACE__SERVICE_SYMBOL_NAME(rosidl_typesupport_cpp, example_interfaces, srv, AddTwoInts)() {
return ::rosidl_typesupport_cpp::get_service_type_support_handle<example_interfaces::srv::AddTwoInts>();
}
#ifdef __cplusplus
}
#endifIs there anybody want to use Please notice:
This is why I was confused that adding the declaration |
|
@iuhilnehc-ynos thanks for the explanation.
in short, i think this is unnecessary. according to your explanation, it seems that we do not need to have these macros in the header file, although i am not familiar with history, there could be intention to add. lets hear opinion from maintainers. |
There is no reason to ignore
event_message.Please see
rosidl/rosidl_generator_c/resource/srv__type_support.h.em
Line 19 in a63f32e