Use std::shared_ptr for compatibility with FCL 0.5.

[de-vri-es]

FCL 0.5 uses std::shared_ptr (and std::weak_ptr) in their public API. To allow using geometric_shapes with FCL 0.5, this PR changes the relevant shared_ptrs to std. This change does affect the public API of geometric_shapes.

See also moveit/moveit_core#315

One question: should we hunt down other shared_ptrs as well? In any case, for compatibility with ROS messages, those types should continue to use boost::shared_ptr until roscpp switches (if that ever happens).

I suppose the pragmatic approach for now is to only switch to std::shared_ptr where required by external libraries, but I also wouldn't mind updating more to std::shared_ptr (where possible).

[davetcoleman]

I'm going to hold off on merging any of these PRs until all of MoveIt! Kinetic builds again, that way Travis won't be failed for too long

[de-vri-es]

Makes sense.

[davetcoleman]

I suppose the pragmatic approach for now is to only switch to std::shared_ptr where required by external libraries, but I also wouldn't mind updating more to std::shared_ptr (where possible).

Can you open an issue for this in moveit_core as an API change for kinetic?

[davetcoleman]

The set of C++11 changes required for FCL 0.5 discussed here are now passing in Kinetic in this test environment. Note that the kinetic branch will continue not to work without installing from source the latest Octomap and FCL, but these will soon be released. Merging all related PRs.

Thanks @de-vri-es for helping migrate MoveIt!

[de-vri-es]

My pleasure, and thanks for all the help :)

[de-vri-es]

Can you open an issue for this in moveit_core as an API change for kinetic?

Issue opened at moveit/moveit_core#319

[jonbinney]

Using -std=c++11 in the public API of geometric_shapes violates REP 0003, right? According to that REP, for kinetic "the API of the packages included in desktop-full will not use any C++11-specific feature."

[davetcoleman]

I thought that must be a mistake in the REP because for Kinetic it says: "Minimum Requirements: C++11". But it was on purpose

It seems though violating it is unavoidable since octomap already violated it

[jonbinney]

Where does Octomap use std::shared_ptr in its (public facing) API? In geometric shapes, the problem isn't that it uses std::shared_ptr, just that it uses it in a public function that gets used by other ROS packages (https://github.com/ros-planning/geometric_shapes/blob/1a020ba1969b7de8d7772e2a82693411733cad65/include/geometric_shapes/shapes.h#L254). At least for geometric_shapes, couldn't that constructor take a boost::shared_ptr and convert it to an std::shared_ptr if needed for passing to octomap?

[davetcoleman]

Ok, it looks like FCL is what requires octree to be wrapped in a std::shared_ptr. Hopefully you're right and we can keep the public facing APIs using boost, I'm sure @de-vri-es has a better understanding of this

[jonbinney]

What is the dependency chain between FCL and geometric_shapes? FCL doesn't directly use geometric shapes (or vice versa), right?

[davetcoleman]

I believe its:

FCL depends on octomap
geometric_shapes depends on octomap
moveit_core depends on FCL and geometric_shapes

[de-vri-es]

I'm on holiday right now, so I can't do a whole lot until I'm back. Regarding wrapping one shared pointer type in the other: it will introduce subtle errors in the behaviour of weak pointers, which will be very difficult to debug. At the moment fcl is already using weak pointers, so we'd have to make sure that doing so doesn't break the current behaviour. Worse though, any future use of weak pointer in the external library could break because they're rightfully expecting weak pointers to work normally.