disRecord's profile - activity

It's relatively old bug. In Jessie kinetic OpenCv is compiled against Qt4 whereas MoveIt uses Qt5. http://answers.ros.or

MoveIt! is compiled against Qt5 according to kinetic conventions. But it depends on OpenCV3 which uses Qt4. It is relati

Maybe it is not a MoveIt! bug. It seems ros-kinetic-opencv3 in Jessie is compiled with Qt4 and MoveIt! depends on this library.

Thank you, but it seems it really hates my email address. I'll make github account and try to post an issue on github.

Well, it is. But I was unable to register on OROCOS forum (it does not like my email address). My friend was more lucky, but he has never received confirmation email. This behavour looks like a bug, but shared_ptr loop presents in code for too long to not be noticed.

This behavour can be reproduced by simple test

class MyService : public RTT::Service {
public:
    MyService(TaskContext* owner) : Service("myservice", owner)  {
         cout << "MyService constructor." << endl;    
    }

   ~MyService() {
        cout << "MyService destructor." << endl;
    }
};

and then load myservice in any component.

It seems to be caused by boost::shared_ptr loop in RTT::Service definition:

typedef std::map< std::string, shared_ptr > Services;
Services services;
...
shared_ptr parent;

What is cause of such design? Why should children owns it's parent? I can not imagine use case when we need preserve Service when coresponding component is being destructed.