ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
4

Design Question. Why *_msgs/*.h and not ros/*_msgs/*.h?

asked 2011-06-22 04:41:46 -0500

rado0x54 gravatar image

updated 2011-09-02 10:17:14 -0500

kwc gravatar image

Hey,

I'm currently creating a Framework for Apple's iOS that includes all the roscpp binaries (for arm6/7 and i386) and the ros header files. If done properly a developer can just import the framework and does not have to worry about architecture or Header location. (runs on simulator(x86) and device(arm)). More Info: http://developer.apple.com/library/ma...

Everything works fine, except of the fact that I had to change all includes to message headers, since they cannot be found under ros, but have independent top-level names. Apple's Framework design only allows for includes like <framework_name>/HEADERSTRUCTURE (here: ros/HEADERSTRUCTURE) so for me, there seems to be no solution to include header files that can not be found unter ros/.

I just wanted to know if it's a good design decision to not group all headers underneath of ros (at least if they are part of roscpp).

I'm also open to suggestions how I can keep the framework structure, without having to rename all references to _msgs/.h

Thanks.

edit retag flag offensive close merge delete

Comments

That's a good question, and applies to the namespaces as well e.g. foo_msgs::MyMsg vs ros::foo_msgs::MyMsg
Asomerville gravatar image Asomerville  ( 2011-06-22 05:09:17 -0500 )edit
Well, I skipped using the framework architecture and went with manual header and library includes.. There's just too much that lives outside the scope of ros.. (messages, tf.. etc)
rado0x54 gravatar image rado0x54  ( 2011-07-14 01:19:49 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2011-09-02 10:20:07 -0500

kwc gravatar image

The "ros::" namespace is only meant for ROS-specific APIs. Placing everything the same namespace makes it difficult to determine what are the actual client library APIs, and what is separate. Also, putting them in the same namespace would require making more names illegal as they would claim the same symbols that the client library is using.

edit flag offensive delete link more

Question Tools

Stats

Asked: 2011-06-22 04:41:46 -0500

Seen: 266 times

Last updated: Sep 02 '11