@Kevin: actually i want to be able to restart the ROS node. This may include
different command line arguments, mappings, whatever. Therefore the cycle should
cover all aspect including the initialization.
> Out of curiosity, what's your use case?
@Blaise: good question, difficult answer :-)
Currently it is more a prototype and testing than a real world application.
I build a ROS node (or a ROS Nodeletmanager) in a shared library. This library
is then loaded and run from an other binary. This binary should be capable of
restarting the ROS node with e.g. modified command line arguments if needed.
If the library is rebuild the binary must unload/reload the modified lib. But
if only command line arguments are changed it should keep the current lib
loaded and just perform a second cycle.
I will post more details of the use case when i am some steps further...
I'm not sure that restructuring the roscpp node to be reinitted regularly is actually the best way to do this. Since you're not actually passing new command line arguments, it doesn't make much sense to simulate the arguments. In the default nodelet manager there is examples of how to replicated everything the command line parsing does w/o recalling ros::init.
Using the arguments to NodeHandle constructor, as nodelets do, instead of recalling ros::init does not set the default NodeHandle constructor which means that you cannot use that. However if you are planning to write libraries which are expected to use seperate remappings than other parts of the same process it is much cleaner to pass that library a NodeHandle at construction, and the library will then base all it's communications off of the namespace embedded in the NodeHandle passed to it.
Stopping and restarting the entire roscpp infrastructure is also dangerous to do if you might have other ROS based libraries elsewhere in the process that you could side effect. And you can only have one ROS node per process, which if the entire node is built into the library it is mutually exclusive with any other library which wants to use ROS.
If you could explain your use case more fully we might be able to suggest an approach which would be easier to implement. We've done several libraries with the approach I suggested above, for example classes in the tf library are all use this design pattern for portability.
http://www.ros.org/doc/api/tf/html/c++/classtf_1_1TransformListener.html#a40d8462819c4e5280e8553080c4bd908
Tully
PS For clarity when we refer to ROS Nodes, that actually refers to the executable.
http://www.ros.org/wiki/Nodes