Recently, FCL 0.5 was released which is compatible with octomap 1.8. MoveIt! switched to FCL 0.5 for kinetic. However, FCL 0.5 also switched to
std::shared_ptr instead of
geometric_shapes::OcTree was still using
boost::shared_ptr. Converting between the two perfectly is not possible. Basically, there were three options:
geometric_shapesand moveit to
std::shared_ptrfor compatibility with FCL 0.5. This violates REP 003 by using C++11 features in the public API and requires all packages using
geometric_shapesto enable C++11 support. The advantage here is that if something breaks the compiler will complain loud and clear.
Copy the underlying object into a new
std::shared_ptr. This is potentially expensive (OcTrees can be big) and means changes to the original OcTree are not reflected in the copy held by FCL. Personally I wouldn’t consider this as a viable alternative, but for completeness it is listed anyway.
std::shared_ptrmanaging the same
boost::shared_ptrwith a special deleter. This breaks the semantics of the accompanying
weak_ptrsubtly. The advantage here is that only code actually using FCL and Octomaps needs to be updated, but the disadvantage is that if a broken
weak_ptrcauses problems, there is no compiler diagnostic and the problem will be very difficult to track down.
Option 1 was actually done, but the discussion does not seem over. So the first question is, was this decision right or should we go for another option?
A second question if we stick with option 1: do we export the
-std=c++11 flags from
geometric_shapes or not?
Exporting the flag has the advantage that other packages not using octomap will probably just work ™. A disadvantage is that compiling with C++11 can introduce subtle errors when linking with non-C++11 code, and it complicates matters for people who want to use a different compatible standard (
gnu++14 for example). It would also mean that multiple packages might export conflicting standards and suddenly the order of declaring your dependencies becomes important. Personally I would prefer not exporting the flag, even if we stick with option 1.