The motivation behind this is that I would like a convenient way to create a subscription associated with a callback group within a node's initializer list. It is straightforward to do this for actions and services, since rclcpp::create_service, rclcpp_action::create_server, etc., allow me to pass a callback group as an argument. However, the rclcpp::create_subscription function takes a SubscriptionOptions struct as an argument, and the SubscriptionOptions struct does not provide a constructor that takes a rclcpp::CallbackGroup::SharedPtr. This means that I have to pass an instance of a CallbackGroup to my SubscriptionOptions in the body of the node's constructor and then create the subscription using those SubscriptionOptions.
A simple approach would be to add a constructor overload to SubscriptionOptions that just takes rclcpp::CallbackGroup::SharedPtr as an argument. As an extension, rclcpp::create_subscription could be overloaded to take a callback group as an argument, similar to the equivalent functions that create clients and servers.
A simple approach would be to add a constructor overload to SubscriptionOptions that just takes rclcpp::CallbackGroup::SharedPtr as an argument. As an extension, rclcpp::create_subscription could be overloaded to take a callback group as an argument, similar to the equivalent functions that create clients and servers.
I prefer the first option, but I think both are ok. PRs are welcomed.
Thanks for opening the issue @schornakj.
Another option is to use the parameter idiom (similar to NodeOptions) in SubscriptionOptions, that's maybe better than having lots of different constructors.
I think the following API is used in this use case.
But it is usefull to use parameter idiom, so I sent PR above.
By the way, I dont know "parameter ideom" well, and I believe it is type of method chaining. Please tell me if I misunderstand.
explicit SubscriptionOptionsWithAllocator(
const SubscriptionOptionsBase & subscription_options_base)
Thank you.
By the way, I dont know "parameter ideom" well, and I believe it is type of method chaining. Please tell me if I misunderstand.
Yeap, the "named parameter idiom" and "method chaining" is the same thing.
Thanks for opening a PR @y-okumura-isp !