Yarp: Collision between YARP and Casadi

[bemilio]

Describe the bug
When including both YARP and Casadi there is a redefinition of the operator
std::ostream& std::operator<<(std::ostream& os, const std::vector<T>& t)

here is the error that I get on compilation:

/home/emilio/Repositories/robotology-superbuild/build/install/include/yarp/os/LogStream.h:195:22: error: redefinition of ‘template<class T> std::ostream& std::operator<<(std::ostream&, const std::vector<T>&)’
 inline std::ostream& std::operator<<(std::ostream& os, const std::vector<T>& t)
                      ^~~
In file included from /usr/local/include/casadi/core/matrix.hpp:31:0,
                 from /usr/local/include/casadi/core/sx_elem.hpp:33,
                 from /usr/local/include/casadi/core/core.hpp:30,
                 from /usr/local/include/casadi/casadi.hpp:29,
                 from /home/emilio/Repositories/pinocchio-integration/main.cpp:5:
/usr/local/include/casadi/core/casadi_misc.hpp:323:12: note: ‘template<class T> std::ostream& std::operator<<(std::ostream&, const std::vector<T>&)’ previously declared here
   ostream& operator<<(ostream& stream, const vector<T>& v) {

To Reproduce
Compile the code:

#include <yarp/os/all.h>
#include "casadi/casadi.hpp"
int main(){}

Expected behavior
Correct compilation with both YARP and Casadi libraries available

Screenshots
NA

Configuration (please complete the following information):

• OS: Ubuntu 18.04
• yarp version: 3.2.0+11-20190716.9+gitd484fdcba
  
  
  
  • compiler: cmake + g++
  
  

Additional context
NA

[traversaro]

I suspect this is a bug in both Casadi and YARP, as extending the std namespace without using program-defined type is undefined behavior in C++ (see https://en.cppreference.com/w/cpp/language/extending_std). I think the correct way of doing this is to define the operator<<(std::ostream& os, const std::vector& t) in a non-std namespace, and use it in all the compilation unit in which you want to use it via a using directive.

[drdanz]

To be honest, I don't remember why this was here, it shouldn't be here at all... I suspect this is something I've been using for debugging when there was no LogStream, and the robotinterface was still in iCub.
I vote for removing it, and consider that this should have never been there, I don't think anyone should be using it...

Also this bug should also be reported in casadi...

[traversaro]

Also this bug should also be reported in casadi...

Yes, we wanted this issue on YARP to get some nice comments so we could link it from the casadi issue. :D

[traversaro]

As mentioned in https://github.com/robotology/yarp/issues/2067#issuecomment-516766845, the long term solution is just to remove that function from both YARP and Casadi . On the YARP side, I think that if someone could propose a PR to get rid of that function in master it would be great, so we would have solved this issue for the next YARP feature release @Giulero @GiulioRomualdi .

[GiulioRomualdi]

Unfortunately removing those lines causes this compilation error

/home/gromualdi/robot-code/robotology-superbuild/robotology/YARP/src/libYARP_robotinterface/src/yarp/robotinterface/experimental/Action.cpp: In function ‘std::ostream& std::operator<<(std::ostream&, const yarp::robotinterface::experimental::Action&)’:
/home/gromualdi/robot-code/robotology-superbuild/robotology/YARP/src/libYARP_robotinterface/src/yarp/robotinterface/experimental/Action.cpp:39:13: error: no match for ‘operator<<’ (operand types are ‘std::ostream {aka std::basic_ostream<char>}’ and ‘const ParamList {aka const std::vector<yarp::robotinterface::experimental::Param>}’)
         oss << t.params();
         ~~~~^~~~~~~~~~~~~

[traversaro]

Probably the function can be reintroduced just in that compilation unit for the ParamList type?

[GiulioRomualdi]

another way is to change the namespace. By the way, removing the function breaks the api so probably it cannot be done in yarp 3

[traversaro]

another way is to change the namespace. By the way, removing the function breaks the api so probably it cannot be done in yarp 3

I don't think that YARP follows semantic versioning if I am not wrong.

[drdanz]

I don't think that YARP follows semantic versioning if I am not wrong.

Actually we are trying to follow semantic versioning, with some exceptions for dev

[traversaro]

I don't think that YARP follows semantic versioning if I am not wrong.

Actually we are trying to follow semantic versioning, with some exceptions for dev

Ah ok, good to know. I wrote that because I remember that back when YARP 3.4 there were breaking changes w.r.t. 3.3, but YARP was not released as YARP 4. Just to clarify, does this means that if deprecated methods are removed in libYARP_os or libYARP_math, the following release would be YARP 4 ? I guess this applies just to API, while not for ABI?

[drdanz]

Yes, but you are right, we broke something in latest release... I think we are not completely strict on the rule yet :wink:
Let's say that whenever it is possible, we deprecate the things to be removed and remove them in the following major version.