So, there has been some discussion about C++11ifying the moveit API. It would make sense to do that for the Kinetic release, or we're stuck with the old API for another 4 years until the next long-term support platform.
As far as I can see, C++11ifying the API basically comes down mainly to replacing boost types with the equivalent std types from C++11. From the top of my head the most likely changes here would be:
- Switch from boost to C++11 smart pointer.
- Switch from
boost::function to std::function
- Switch from
boost::chrono types to std::chrono types.
- Switch from boost synchronisation types to C++11 equivalents (
std::mutex and friends)
- Possibly use
std::tuple instead of boost equivalents (probably not needed)
- Use
enum class instead of old enums.
There are some more changes possible which are unlikely to affect the public API:
- Switch from boost to
std::bind
- Switch from boost to
std::thread
- Use the new random number generator facilities
- Simplify things internally using C++11 features (lambdas, range based for loops, etc...)
Some shared_ptr types will be forced by the ROS API, but those are generally used through typedefs like sensor_msgs::JointStatePtr. Those would be left alone of course.
@davetcoleman also suggested seeing what clang-tidy comes up with, which seems like a good idea.
So, I would like to undertake a project like this on the short term (on time for Kinetic which shouldn't be delayed too long I think). But before doing anything like that of course I'd like to know what other people think about C++11ifying the API.
So, there has been some discussion about C++11ifying the moveit API. It would make sense to do that for the Kinetic release, or we're stuck with the old API for another 4 years until the next long-term support platform.
As far as I can see, C++11ifying the API basically comes down mainly to replacing
boosttypes with the equivalentstdtypes from C++11. From the top of my head the most likely changes here would be:boost::functiontostd::functionboost::chronotypes tostd::chronotypes.std::mutexand friends)std::tupleinstead of boost equivalents (probably not needed)enum classinstead of old enums.There are some more changes possible which are unlikely to affect the public API:
std::bindstd::threadSome shared_ptr types will be forced by the ROS API, but those are generally used through typedefs like
sensor_msgs::JointStatePtr. Those would be left alone of course.@davetcoleman also suggested seeing what clang-tidy comes up with, which seems like a good idea.
So, I would like to undertake a project like this on the short term (on time for Kinetic which shouldn't be delayed too long I think). But before doing anything like that of course I'd like to know what other people think about C++11ifying the API.