ros / gencpp Goto Github PK
View Code? Open in Web Editor NEWROS C++ message definition and serialization generators
Home Page: http://wiki.ros.org/gencpp
ROS C++ message definition and serialization generators
Home Page: http://wiki.ros.org/gencpp
I get this warning on an ARM HF system for all unsigned constants in a msg description:
msg:
uint32 ALL = 4294967295
The generated code for this constant is:
enum { ALL = 4294967295 };
and should be
enum { ALL = 4294967295u };
to get rid of this warning.
In action_client.h (on lines 217 and 221) both goal_pub_ and cancel_pub_ are advertised with queue sizes of 1. This occasionally causes goals to be dropped. Could these queue sizes be configurable or at least increased?
when using custom message with big structure, we may reach the windows compilator limit of 65535 character for a string.
This happens in msg creation when building the comment string in escape_message_definition function.
proposed patch is to break when 64000 size limit is reached 👍
def escape_message_definition(definition):
lines = definition.splitlines()
if not lines:
lines.append('')
s = StringIO()
count = 0
for line in lines:
line = _escape_string(line)
# individual string literals cannot be too long; need to utilize string concatenation for long strings
# https://docs.microsoft.com/en-us/cpp/c-language/maximum-string-length?view=vs-2017
s.write('"%s\n"\n' % (line))
#patch to exit when line total greater than 64000 due to windows compil limitation
count = count + len(line) + 6
if count > 64000:
break
val = s.getvalue()
s.close()
return val
ROS messages have a shared pointer to a _connection_header
in the message. This field is unused, and takes a large amount of space (8 bytes on 64bit systems). We should remove this field to make using ROS messages easier.
From the "msg.h.template" file:
// REMOVE THIS FIELD
boost::shared_ptr<std::map<std::string, std::string> > __connection_header;
https://github.com/ros/gencpp/blob/indigo-devel/scripts/msg.h.template#L17
The BSD license still attributes copyright to Willow Garage for auto generated message files. Should this (can this) be changed?
Hi,
I originally posted this here: http://answers.ros.org/question/49422/undefined-reference-for-string-constant-in-service/ , then submitted a ticket here: https://code.ros.org/trac/ros-pkg/ticket/5587, so I hope this is in the right place here now ;)
when I define a simple service in Fuerte, e.g.
string my_string
string CONST_STRING=some_value
---
I get an undefined reference to ...::CONST_STRING during linking. Looking at the generated header file, I noticed that CONST_STRING gets declared, but never defined. I tested the same with messages: here it works fine and I can see the definition of CONST_STRING.
The same applies for floatXX-- I guess that problem exists for every constant that can not be encoded into an enum.
Best, Markus
If a comment description line in a .msg file (starting with #) ends in a a special character such as ( ), extra newlines are added in the generated header file which gives compiler errors when included. Example below:
# ICD-XXXXX - Delta Position
# Primary Measurement: Change in position over a time interval (1D, 2D, or 3D)
# Standard Header
Header header
#1, 2, or 3 elements based on dimension specified in metadata
float64[] delta_pos
# Delta position covariance matrix (row-major) in [units^2] of size nDim x nDim.
# The matrix is linearized into a single array for storage.
float64[] delta_pos_covariance
generates the header with the following code (note the extra newlines):
template<class ContainerAllocator>
struct Definition< ::MyClass::DeltaPosition_<ContainerAllocator> >
{
static const char* value()
{
return "# ICD-XXXXX - Delta Position
\n\
# Primary Measurement: Change in position over a time interval (1D, 2D, or 3D)
\n\
\n\
# Standard Header
\n\
Header header
trac data:
For full introspection, Python is typically the better answer, but we have some cases where we'd like to be able to reference constant names for example in rosparam yaml, or transform variables into the appropriate constants for the purposes of emitting more helpful logs / diagnostics— from the context of a compiled roscpp binary.
A couple of possible ways this might be implemented:
std::map
of constant names to int64_t
values, and any constants which can't be upcast to int64_t (eg, uint64_t) are out of luck.boost::any
values (we already depend on boost::shared_ptr
and boost::array
here, though depending on boost::any
would be new).Regardless of approach, none of this should have a binary-size cost since the unused function will just be optimized away. There will be some impact to compilation time (particularly if the boost::any
approach is chosen), but I wouldn't expect it to be significant— if there's concern about this, I can do some measuring in order to put a number on it.
Would a PR for this change be welcome? Preferences on approach to take?
I was having an issue with compiling when using the message-filter sync policies with custom messages that all contain std-msgs/Header fields. Poking around further, it became clear that the .h file generated for my custom messages do not have HasHeader templates. Cutting and pasting the HasHeader() template from Sensor-msgs/Image.h and changing the names, my code compiles. Look like this is a bug in gencpp for hydro???
The Python generation code contains logic to append with underscore any fields that match a Python keyword:
However, there's no such thing in the gencpp code, so we got tripped up when we had a message with established Python usage that had class
as a field name, and then got used in C++ and wouldn't compile.
For now we've simply renamed our field to class_
, but it would be great to see this transformation happen in gencpp itself, as it does in genpy.
Consider the following message spec:
time[] foo
The C++ code generated for this message generates a warning which concerns me, as it indicates invalid code (the actual warning is much longer, cf. instructions below to reproduce):
/usr/lib64/ros/include/ros/serialization.h:451:13: warning: ‘void* memcpy(void*, const void*, size_t)’
writing to an object of non-trivially copyable type ‘__gnu_cxx::__alloc_traits<std::allocator<ros::Time>,
ros::Time>::value_type’ {aka ‘class ros::Time’}; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
memcpy(&v.front(), stream.advance(data_len), data_len);
It seems that some type trait is missing for such time arrays, such that the proper VectorSerializer is chosen.
You can find an example repository at https://github.com/timn/ros-timebug_msgs. I have tried this with ROS Kinetic. Once it is built in a workspace it prints the warning.
possible to separate into various headers, or maybe via
#ifndef ROSCPP_DISABLE_MESSAGE_SERIALIZATION
In #20, the copyright statement was removed from generated header files. However, this creates an ambiguity. We don't know whether the generated source code has the copyright of the msg file, or the copyright of gencpp (because gencpp creates it).
It would be helpful if the gencpp license statement could be extended to explicitly state what copyright the generated messages are under. Preferably, that should be the copyright of the input file, but BSD would also be acceptable.
Sorry if this seems overly picky, but you know, any ambiguity is bad in legal questions.
moved over from ros/actionlib#2
@dpinol
When compiling in gcc with -Wall -Wextra a file generated I get tons of warnings because of unused parameters in the files generated at the msg_gen/cpp/include/ folder.
template<class ContainerAllocator> struct Serializer< ::face_detector::FaceDetectorGoal_<ContainerAllocator> >
{
template<typename Stream, typename T> inline static void allInOne(Stream& stream, T m)
{
}
ROS_DECLARE_ALLINONE_SERIALIZER;
}; // struct FaceDetectorGoal_
} // namespace serialization
} // namespace ros
namespace ros
{
namespace message_operations
{
template<class ContainerAllocator>
struct Printer< ::face_detector::FaceDetectorGoal_<ContainerAllocator> >
{
template<typename Stream> static void stream(Stream& s, const std::string& indent, const ::face_detector::FaceDetectorGoal_<ContainerAllocator> & v)
{
}
};
Follows #32 .
What about adding MY_PKG_MESSAGE_MYVECTOR3_PLUGIN_FREE_FUNCTIONS
that would be at (or near) the very end of the header file? That'd allow adding more traits and such things.
@dirk-thomas commented
Depending on what you mean with free functions you might be able to just put them into the
<pkgname>/plugin/<msgname>.h
file.
But this file is included before the message definition file, so you cannot use the defined class or typedefs in the plugin file...
If the msg proto ends without a newline, genpy (IMO correctly) generates the message definition also without this ending newline. On the other hand, gencpp always adds a newline to the last line of definition. This results in different message definitions between gencpp- and genpy- generated files.
See yourself e.g. in geometry_msgs
. Vector3
has no ending newline in the proto, and this is what genpy and gencpp generate:
gencpp: "float64 z\n"
genpy: float64 z"""
I think the difference is caused by this line of code:
Line 111 in e85a185
The question is - can this be fixed in the already released ROS 1 versions? Or would that be an API-break? Regarding the definitions stored in e.g. rosbags, they already differ depending on whether the publisher was a rospy or roscpp one. So I guess removing or adding the ending newline doesn't actually break anything.
The dreaded serialization bugs attack again. Ref http://answers.ros.org/question/71107/pandaboard-alignment-trap-when-using-tf/
My platform is a linaro ubuntu precise 12.10 on an odroid xu. The other person with the issue is on the Pandaboard. Note that I don't get this error on my Pandaboard with 12.04 and Fuerte.
Backtrace:
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xb1aff420 (LWP 14419)]
0xb6f65294 in void ros::serialization::VectorSerializer >, std::allocator > >, void>::readros::serialization::IStream(ros::serialization::IStream&, std::vector >, std::allocator > > >&) () from /opt/ros/groovy/lib/libtf.so
(gdb) bt
#0 0xb6f65294 in void ros::serialization::VectorSerializer >, std::allocator > >, void>::readros::serialization::IStream(ros::serialization::IStream&, std::vector >, std::allocator > > >&) () from /opt/ros/groovy/lib/libtf.so
#1 0xb6f65592 in ros::SubscriptionCallbackHelperTboost::shared_ptr<tf::tfMessage_<std::allocator<void > const> const&, void>::deserialize(ros::SubscriptionCallbackHelperDeserializeParams const&) ()
from /opt/ros/groovy/lib/libtf.so
#2 0xb6f0035e in ros::MessageDeserializer::deserialize() () from /opt/ros/groovy/lib/libroscpp.so
#3 0xb6efa376 in ros::SubscriptionQueue::call() () from /opt/ros/groovy/lib/libroscpp.so
#4 0xb6ec4070 in ros::CallbackQueue::callOneCB(ros::CallbackQueue::TLS*) () from /opt/ros/groovy/lib/libroscpp.so
#5 0xb6ec500e in ros::CallbackQueue::callAvailable(ros::WallDuration) () from /opt/ros/groovy/lib/libroscpp.so
#6 0xb6f618f8 in tf::TransformListener::dedicatedListenerThread() () from /opt/ros/groovy/lib/libtf.so
#7 0xb6f61654 in boost::detail::thread_data, boost::_bi::list1boost::_bi::value<tf::TransformListener* > > >::run() () from /opt/ros/groovy/lib/libtf.so
#8 0xb6165602 in thread_proxy () from /usr/lib/libboost_thread.so.1.46.1
#9 0xb6c3ded2 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#10 0xb62aaf18 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#11 0xb62aaf18 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Originally filed by @icoderaven ros/geometry#39
The current serialization of ROS messages as generated by the stream operators is not YAML compliant for arrays:
https://github.com/ros/gencpp/blob/indigo-devel/scripts/msg.h.template#L248
If there is no special reason for this, I think this should be changed. This way the output will be the same as provided by rostopic echo
and it can be directly written to a .yaml file.
I was surprised when I needed this and it wasn't there. It's brittle to test fields manually in my user code and relatively easy to support it here.
I made my own msg file by using catkin_make. But my IDE shows an error after include new_msg.h.
In file included from sketch/example_header.h:8:0,
from /home/zeta/Arduino/my_project/my_project.ino:23:
/home/zeta/Arduino/libraries/ros_lib/my_msg/new_msg.h:9:10: fatal error: string: No such file or directory
#include
Code like this:
int foo = <condition> ?
diagnostic_msgs::DiagnosticStatus::OK :
diagnostic_msgs::DiagnosticStatus::ERROR;
Produces this warning:
/home/mpurvis/test_ws/src/test/src/main.cpp: In function ‘int main()’:
/home/mpurvis/test_ws/src/test/src/main.cpp:5:94: warning: enumeral mismatch in conditional expression: ‘diagnostic_msgs::DiagnosticStatus_<std::allocator<void> >::<anonymous enum>’ vs ‘diagnostic_msgs::DiagnosticStatus_<std::allocator<void> >::<anonymous enum>’ [-Wenum-compare]
int a = false ? diagnostic_msgs::DiagnosticStatus::OK : diagnostic_msgs::DiagnosticStatus::ERROR;
Which seems to happen because OK and ERROR come from different anonymous enums. There's a lot of chatter about this warning on the googles:
https://www.google.ca/search?q=Wenum-compare
But it does seem that moving all message constants into a shared enum would provide a simple fix.
Hello,
I hope gencpp generates the headers based on service files and the issue is in the right repo.
I use ros indigo ubuntu 14.04:
When I generate a service file and define it like:
int8 <tab> test1
int8 <tab> test2
---
int8 <tab> test3
This does result in a compilation error.
If I define it like:
int8 .. test1
int8 .. test2
---
int8 .. test3
With "." representing "space", the compilation works without an error regarding the service file definition.
Is this intended behaviour?
Best,
Chris
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.