Transition to standard smart pointers

[taketwo]

Now that PCL compiles with C++14 by default, it's high time to make a transition from Boost to standard smart pointers. This transition should not break source code level compatibility with previous releases. In other words, users should be able to compile their downstream projects with both PCL 1.9 and PCL master.

Grepping for shared_ptr in PCL code base I find well over a thousand matches. We can divide these in two groups: where it is a part of public API and where it is not. For the second group the transition is straightforward. For the first group... it depends. As far as I can see, not all shared pointers in API are hidden behind typedefs. This is bad. We will need to think about it and come up with a good strategy how to smoothly convert these.

In the meantime, as a first step I propose to take care of the non-API shared pointers. I think it's not purely mechanical change and we'd always need to carefully double check the context. So I see this as a series of medium-sized PRs. This way it's a) not as daunting a task to do actual changes b) and to review; c) plus we'll have fewer conflicts with other PRs, especially the modernization ones that tend to produce large scattered diffs.

I can (slowly) start with this. @SunBlack your help would surely be appreciated if you are interested. We'll need to orchestrate our efforts to avoid conflicts and double work.

[SergioRAgostinho]

As far as I can see, not all shared pointers in API are hidden behind typedefs. This is bad. We will need to think about it and come up with a good strategy how to smoothly convert these.

Other than lack of consistency and ease of migration, I'm failing to grasp the motive behind your increased concern. What's the failure case you have in mind?

Other than that the plans sounds good.

[SunBlack]

I can (slowly) start with this. @SunBlack your help would surely be appreciated if you are interested. We'll need to orchestrate our efforts to avoid conflicts and double work.

I still don't reached my target to cleanup code this far, that I can cleanup CMake code. So maybe I will replace only small parts of boost, but not the big things.

In general it could be hard to be fully compatible to 1.9.1.
Example: Try to replace boost::mt19937 with std::mt19937. In most cases no one will notice. But sometimes this class is used header files, so in case someone is inherits from a class like this, ... And typedef is not enough, because usage is a bit other in std than in boost (variate_generator was only part of tr1, but not of final). And I don't know if it is worth to have hundreds of #ifdef in code just to handle this.
Maybe it is a compromise to say: Signature of public function should be not be changed (just CMake flag for std vs boost), but protected function and members can be changed without a deprecation release.

[taketwo]

Other than lack of consistency and ease of migration, I'm failing to grasp the motive behind your increased concern. What's the failure case you have in mind?

No, I don't have other concerns besides migration. So by "this is bad" I rather meant "this is bad when it comes to migration". Consider this public API method:

pcl/surface/include/pcl/surface/surfel_smoothing.h

Lines 96 to 99 in 99a5b28

	void
	extractSalientFeaturesBetweenScales (PointCloudInPtr &cloud2,
	NormalCloudPtr &cloud2_normals,
	boost::shared_ptr<std::vector<int> > &output_features);

It uses boost::shared_ptr explicitly. Somewhere in downstream project we will find the following usage:

boost::shared_ptr<std::vector<int>> output_features(new std::vector<int>);
obj.extractSalientFeaturesBetweenScales(cloud, normals, output_features);

Now suppose we switch to std. The user will need to rewrite his code as well. Result: it's not possible to build user project against new and old PCL without ugly #if/#else guards. This is something I absolutely want to avoid.

I still don't reached my target to cleanup code this far, that I can cleanup CMake code.

I was not talking about CMake here, only code.

Example: Try to replace boost::mt19937 with std::mt19937.

Also not other Boost classes. Let's keep this issue focused on smart pointers.

[SergioRAgostinho]

Thanks for the clarification.

For cases like the one you mentioned. I would opt to simply do the breaking transition without a deprecation cycle because I really do not want to have if/else guards all around.