libraries shouldn't write to stdout
ibtaylor opened this issue · 6 comments
ros_type_introspection/src/deserializer.cpp
Lines 163 to 166 in 81fd041
stderr would be better, but I don't want to be forced to see that either.
If this is about the buffer being too small and so it only partially parsed, that seems like possibly desirable behavior, so a warning is kind of annoying.
Maybe it would be better to return the required array_size instead? Possibly return bool regarding whether it was completely processed or not.
buildRosFlatType(...., array_size, &required_array_size);
// at least the user can control the output now
LOG_IF(WARNING, required_array_size > array_size) << "buffer too small, results will be truncated";
For instance, I'm mostly interested in only parsing the Header and not the entire message.
I agree with you.
A possible solution is that we add one more argument to that function as std::ostream
std::ostream might output to null, std::cout, std::cerr or a std::string, so the user can choose.
Does it make sense in your opinion?
Take a look to this change. Does it make sense in your opinion?
For instance, I'm mostly interested in only parsing the Header and not the entire message.
I would say that there is no way to do this. You should implement your own version of buildRosFlatType to do that
I'm not sure yet. Can you explain the reason for max_array_size? Is it intended to purposefully ignore certain large arrays or something?
Exactly. The main reasoning is that the key/value storage will create a pair for each BuiltIn element.
if someone pass an Image with 1M pixels, the result would be 1M key-value pairs.
Most of the time you want to ignore this very large vectors. You can also use an arbitrarily large number, of course.
if you want to SAVE only a part of the message, for example the Header, you can actually do it, but you need to implement a recursive function very similar to buildRosFlatType.
I introduced a solution in the PR 11