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 boost::shared_ptr
, while geometric_shapes::OcTree
was still using boost::shared_ptr
. Converting between the two perfectly is not possible. Basically, there were three options:
-
Switch
geometric_shapes
and moveit tostd::shared_ptr
for compatibility with FCL 0.5. This violates REP 003 by using C++11 features in the public API and requires all packages usinggeometric_shapes
to 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. -
Create a
std::shared_ptr
managing the sameboost::shared_ptr
with a special deleter. This breaks the semantics of the accompanyingweak_ptr
subtly. The advantage here is that only code actually using FCL and Octomaps needs to be updated, but the disadvantage is that if a brokenweak_ptr
causes 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 (-std=gnu++11
, c++14
or 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.