Moving to C++14

[SergioRAgostinho]

Just aggregating the points we've discussed at the hackfest.

• enable C++14flags
• remove dependency on boost-thread and move to STL
• remove dependency on boost-iostream (? @nizar-sallem will need to confirm this)

[awilliamson]

👍+1 for removing boost dependency.

[nznobody]

+1! Would make portability easier again (I know boost is super portable too...)

[giacomodabisias]

+1!

[VictorLamoine]

I think we should also replace boost smart pointers with std ones.
Most C++ compilers now have C++11 support right?

[taketwo]

Easier to say than to do. It's true that most compilers support C++11, it will even become the default in GCC soon. Nevertheless, not everyone wants (or can) compile their code in C++11 mode. And if we switch to STL smart pointers, that will force all code that uses PCL to be compiled in C++11 mode. For a concrete example of how this can lead to problems, refer to this thread.

[giacomodabisias]

Just set a flag in the cmake file so that you can choose if you want to use std or boost shared pointers.
Even something like this would be enough

#pragma once
#ifdef WITH_STD_SHARED_PTR
    #include <memory>
    using std::shared_ptr;
    using std::make_shared;
    using std::static_pointer_cast;
    using std::dynamic_pointer_cast;
#else
    #include <boost/shared_ptr.hpp>
    #include <boost/make_shared.hpp>
    #include <boost/pointer_cast.hpp>
    using boost::shared_ptr;
    using boost::make_shared;
    using boost::static_pointer_cast;
    using boost::dynamic_pointer_cast;
#endif

[taketwo]

This is indeed possible. But do we actually gain anything?

[giacomodabisias]

I already had issues with that. Every other library which wants to build on top of PCL or wants to use PCL inside has to use boost shared pointers even if it wants to use std shared pointers inside. Also it is an unnecessary dependency which you will always have. I think that sticking to the standard is always the best way to remain portable and open, so I would say its not mandatory but strongly recommended.

[taketwo]

But both std and boost pointers can co-exist. It's true that the PCL-related objects (i.e. point clouds, octrees, etc.) have to be managed by boost pointers, but everything else in your program/library is free to adhere to the standard.

Even if we get rid of boost smart pointers completely, we will still need other modules of Boost, so this dependency will never be dropped.

I also prefer standard solutions and have been using C++11 where ever possible for more than five years now. But my feeling is that if we can not make a wholesale jump to C++11 just yet, it does not make much sense to implement partial conversions and maintain them.

[giacomodabisias]

Yeah they can co-exist, thats true, but since the standard moved I think PCL should catch up. Else you are forcing users to use boost also in their libraries if they want to use pcl

[taketwo]

As I said, even without it's smart pointers, Boost is a cornerstone dependency of PCL. We rely on many other Boost modules that are not in the standard, so the PCL users are doomed to use Boost anyway.

[feliwir]

couldn't be there a version without boost usage? Something stripped down. It's pretty much the largest dependency of PCL by far

[taketwo]

couldn't be there a version without boost usage? Something stripped down.

No, impossible. Boost MPL library is essential in "common" module for point types definitions. Everything else depends on this.

It's pretty much the largest dependency of PCL by far

Isn't VTK larger? But why is this a problem anyway? Boost is not a random shady third-party library, it's one of the most popular and well-maintained C++ libraries, packaged for all possible OSes and distributions.

[SergioRAgostinho]

Continuing the discussion from #1565 (comment)

Clang guys are now discussing moving clang to support C++14 by default [1]. By the end of the thread, that's he general feeling. It means till it gets adopted it should take around a year or so and then it still takes time till Apple merges it into it's own version of clang.

[1] - http://clang-developers.42468.n3.nabble.com/Setting-default-dialect-to-C-11-td4055489.html

[denix56]

It will be really useful to have the ability to use c++11 standard. I see some optimizations, that I could do in visualization module, but the code will be more complicated and less understandable without c++11 features.

[BrannonKing]

+1 for c++14 now and no boost dependencies. Boost on Windows is a pain.

[SergioRAgostinho]

Release schedule for clang 6 aimed for March 2018 with the confirmation of the default dialect set to 2014 (don't be fooled by the thread title).

Further confirmation: http://prereleases.llvm.org/6.0.0/rc2/tools/clang/docs/ReleaseNotes.html#id1

[giacomodabisias]

I can work on it a bit during weekends. Do we have a thread where to discuss this further?

[taketwo]

There is a GitHub project for this topic, though it's not particularly active.

[SergioRAgostinho]

The new clang is out and it defaults to c++14. I'm planning to start working on this after the next release.

[BhargavaRamM]

@SergioRAgostinho @taketwo is there a road map to see when new releases will be out?

[taketwo]

I'm afraid we don't have enough manpower to make releases, leave alone writing roadmaps :)
But the 1.9.0 release will hopefully happen sometime this summer.

[frozar]

That's a sad news...

Do eventually think about recruiting new people to maintain PCL?
(I would be really really interested! 😸)

[taketwo]

As was discussed and agreed before, we will start merging C++14 stuff right after the 1.9.0 release. From my side, the main blocker for the release is #2100. So for all those who want to see C++14 support sooner than later and are willing to help, that is an issue to focus upon.

[fferroni]

@feliwir are you still working on removing boost dependency and move to stl? do you need help / manpower?

[feliwir]

@fferoni i am currently not working on this. I am afraid another PR will just get rejected aswell since the requirements aren’t clear. My initial PR removed tons of boost stuff, but it was too large. Splitting it into small packages is pretty difficult due to dependency chains. I‘d like to finish this, but i won’t do it when i am not sure wether or not it gets merged.

[SergioRAgostinho]

Keep things idle for now. We'll call out for help once we can start merging things.

[feliwir]

So this got delayed even further? To 1.10?

[fferroni]

@SergioRAgostinho OK, that's a shame. With modern STL boost seems a bit unnecessary, since it's using things like threading and filesystem mainly.

[SergioRAgostinho]

While wrapping up 1.9.0 we realized that the project needs a serious CMake rework. See discussions in #2425, #2446 or the more comprehensive open project on the topic. In my mind I considered this to be more important short term and (in the shadows) targeted a 1.9.1 release just to fix cmake stuff, hence moving C++14 to 1.10.0.

This is not settled. I have not requested people to voice their opinion and of course, no one did. We're all users and ultimately it makes sense to guide our needs by the most pressing needs of the majority. We're a little understaffed (for reviewing purposes) so I would prefer to focus on one major goal per release.

I understand our release cycle is very slow and pushing things to the next release may sound despairing, but I've been actively working in addressing these problems (see #2396 and #2410), so I want to believe that won't be a problem this time.

Now, you're all invited to voice your opinion on the topic. The usual process would be to discuss these things on the development mailing list but that's currently down (see #2415). Ping @PointCloudLibrary/maintainers, @svenevs and @claudiofantacci .

For the time being I'll work on closing the release (missing this #2396 (comment)) and once that's done we'll see where to go.

[claudiofantacci]

I'm here to help and discuss 👍
I've never followed the development mailing list before and following #2415 is undergoing a migration to Google groups. I guess there will be an announcment when it will be back up and running 😄 Otherwise, if you already have an (even temporary) alternative for that, please add me in 👍

[taketwo]

To be honest, I'm not convinced by the idea of fixating on having 1.9.1 with only CMake rework. No doubt, the new tools for release automation reduce friction, but we can volunteer only limited time and our contributors are on and off, so it's hard to estimate how much time this rework might take. Thus this will delay moving to C++14 by unknown (and potentially large) amount of time. Which would frustrate many people, since switching to modern C++ is arguably the most anticipated feature.

Why not simultaneously merging PRs for C++14 and CMake fixes as soon as they pop up?

[svenevs]

so it's hard to estimate how much time this rework might take

I think this is a very important consideration. All that really needs to happen to enable both to be worked on in independently is

cmake_minimum_required(VERSION 3.1.3 FATAL_ERROR)
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

Doing that at the beginning of the root CMakeLists.txt will help alleviate potential friction. As far as I know, compiling the existing code base with -std=c++14 like this has basically zero chance for error. The newer standard may change some definitions / symbol names etc, but I doubt there are many if any things in the current code base that will not work. The goodies for C++14 are what we're ultimately after, such as constexpr glory and whatnot. But just using the standard, I don't believe anything actually has to change.

This has the added benefit that (as far as I understand it), newer versions of MSVC will not support earlier than C++14, so if that's true it's high time to switch that.

As a side note I'm not 100% sure when CMAKE_CXX_STANDARD was actually released, 3.1.3 is a very conservative estimate -- that's the first place it shows up in the docs.

We can discuss this elsewhere, but there are ways to go about setting this so that (in non-CUDA land at this point in time) users can just -DCMAKE_CXX_STANDARD=17 if they want PCL compiled as such. Basically, perform the absolute minimum change needed to make it so that people can use C++14 code to link with PCL. The different standards are not ABI compatible, so people will stop using PCL if they can't use a later standard.

[claudiofantacci]

To be honest, I'm not convinced by the idea of fixating on having 1.9.1 with only CMake rework. No doubt, the new tools for release automation reduce friction, but we can volunteer only limited time and our contributors are on and off, so it's hard to estimate how much time this rework might take. Thus this will delay moving to C++14 by unknown (and potentially large) amount of time. Which would frustrate many people, since switching to modern C++ is arguably the most anticipated feature.

Why not simultaneously merging PRs for C++14 and CMake fixes as soon as they pop up?

I agree with you. Wasn't there some ongoing work on supporting C++14, that by my understanding is to allow new standard features while also removing unnecessary boost dependency?
Where is it? I found this repo from @feliwir.

I'm quite new about this topic in PCL, so forgive me if I make some mistakes.
Switching to C++14 and removing some boost dependency is not an easy task and I don't know if it can happen with small PR merged on master branch. If there was a devel (unstable) branch, we could probably organize the transition while accepting bugfixes on master branch. Maybe we can start a devel branch starting from the next release to focus on this particular change.

@svenevs, sorry but I don't understand your point of the last post 😅

[svenevs]

@claudiofantacci sorry. Re-word: the cmake snippet I gave is the code for checklist item 1 to add C++14 flags. We can later decide on cmake things that may relate to how cxx_standard is actually set in code / by user on a different thread.

Remaining checklist items to replace boost dependencies takes more work, but can be worked on in individual PRs at the same time as cmake patches.

[claudiofantacci]

@svenevs thanks for the clarification.

In order to do this, in parallel, we could make an action plan and understand where to open PR that may be partial and breaking.

[SergioRAgostinho]

Why not simultaneously merging PRs for C++14 and CMake fixes as soon as they pop up?

I have no strong argument against it. All the arguments everyone posted are compelling and it seems to be the general desire from the participants here. If we were an organized full-time team, it would be one thing, but as you correctly stated, we are not.

As a side note I'm not 100% sure when CMAKE_CXX_STANDARD was actually released, 3.1.3 is a very conservative estimate -- that's the first place it shows up in the docs.

The idea is to jump to 3.5 until 16.04 EOL support. We'll bump it as required. See https://github.com/PointCloudLibrary/pcl/projects/2#card-13291886 for more info.

Switching to C++14 and removing some boost dependency is not an easy task and I don't know if it can happen with small PR merged on master branch. If there was a devel (unstable) branch, we could probably organize the transition while accepting bugfixes on master branch. Maybe we can start a devel branch starting from the next release to focus on this particular change.

See the discussion from here onwards #2382 (comment)

[claudiofantacci]

Why have no strong argument against it. All the arguments everyone posted are compelling and it seems to be the general desire from the participants here. If we were an organized full-time team, it would be one thing, but as you correctly stated, we are not.

I agree with you all that contributors (including myself) are on/off-committed. The problem, to me, is that it is quite difficult to move from Boost dependencies to C++14 without braking anything, while CMake issues can be addressed with some PRs. What I fear is that we need to "freeze" PCL until we make a full switch, so it does make sense fix CMake first and then address C++14. The point then is how to proceede with releases.

The idea is to jump to 3.5 until 16.04 EOL support. We'll bump it as required. See https://github.com/PointCloudLibrary/pcl/projects/2#card-13291886 for more info.

Yes. 👍

See the discussion from here onwards #2382 (comment)

Great thanks! I'll have a read asap.

[taketwo]

The problem, to me, is that it is quite difficult to move from Boost dependencies to C++14 without braking anything [...] What I fear is that we need to "freeze" PCL until we make a full switch

I mentioned this on couple occasions before, we don't expect to drop Boost dependency. At the very least, its MPL and preprocessor libraries are used extensively in the PCL core. Standard library (even the latest standard) does not have these things, so Boost is here to stay.

Generally, I agree with @svenevs idea of beginning the process with just the addition of a few lines to CMakeLists. Then we can merge separate PRs that swap certain Boost classes to standard alternatives (e.g. boost::thread -> std::thread).

[claudiofantacci]

I mentioned this on couple occasions before, we don't expect to drop Boost dependency. At the very least, its MPL and preprocessor libraries are used extensively in the PCL core. Standard library (even the latest standard) does not have these things, so Boost is here to stay.

Forgive my inaccuracy in writing move from Boost dependencies to C++14, where I meant to replace only those part covered by the standard and not to remove Boost altogether.

Anyway, my point is that I forsee breaking changes with the PRs (I don't know if there is a compatibility layer between future changes) and with a single stable master branch there might be some problem. Having said this, considering that I am also an on/off contributor, I'm willing to help and sicuss to improve PCL. If we can set up even some partial organization with these tasks in mind we can a reasonable pace toward future releses 👍

[taketwo]

I forsee breaking changes with the PRs

Do you have something specific in mind? Breaking in which way? ABI will change, of course, but that's not a problem. Except to the pointer type change I hope that API will also remain stable.

[claudiofantacci]

Do you have something specific in mind? Breaking in which way? ABI will change, of course, but that's not a problem. Except to the pointer type change I hope that API will also remain stable.

I mean within PCL itself while we work on it.
I'm not sure whether it is possible to start changing some of the Boost code into standard one, while still be able to compile and run the code with mixed code without adding more code to work as a compatibility layer. Again, I'm not sure, because the only times I had to make such changes I made them in one shot 😃.

[SergioRAgostinho]

1.9.0 is out. We will activate the c++14 flags asap.

[taketwo]

OK, I'll try to recollect all the important points related to C++14 activation:

• Raise CMake required version to 3.1.3 (for now, but will probably go to 3.5.1 soon)
• Default to 14, but somehow allow user to select 17 if needed Moving to C++14 #1638 (comment)
• Add a #error in one of main headers to check if 14 is activated, this is to solve the last item mentioned here: [WIP] Moving to C++ 14 #2382 (comment)

@svenevs can you comment on the second point? Are you sure that simply passing -DCMAKE_CXX_STANDARD=17 the user will override our setting?

[feliwir]

You‘ll also want to set CMAKE_CXX_STANDARD_REQUIRED to true. So an error during configuration stage is produced.

[claudiofantacci]

Are you sure that simply passing -DCMAKE_CXX_STANDARD=17 the user will override our setting?

@taketwo, only if you use

set(CMAKE_CXX_STANDARD 14 CACHE STRING "Some description of the variable")

then the user will be able the overwrite the option with -DCMAKE_CXX_STANDARD=17.

[taketwo]

Closing this issue because we have moved to C++14 and got rid of most of Boost dependencies. There are a number of things left to be done; they are tracked in this project.