c++14 upgrade

[aautushka]

The project extensively uses C++11 features and compiles with C++11 support. But it's 2018 now and I frankly don't see why not upgrade at least to C++14 (or even C++17). And it's quite easy to do: change a couple of cmake files and perhaps a few compiler warnings. The real question: are there any serious enough reasons to stick to C++11?

We can do the upgrade and testing ourselves, if the community agrees and provides the list of desired platforms/compilers.

[abitmore]

@aautushka see #618 for more discussion.

[abitmore]

We can gather some info first, to see how requiring C++14 or even C++17 will affect people involved, and how to solve the issues (update documents).

Platform/tools I'm using:

• Ubuntu 16.04 with shipped GCC, boost 1.58 and other libs
• Windows 10 with VS2015 update 1, for building windows binaries. The binaries will be run in Windows 7 or Windows 10.

If these tools support C++14, I'm totally fine. If not, need to make a document about how to upgrade.

[aautushka]

GCC 5.4 from Ubuntu 16.04 does support C++14.
VS2015 seems to support some of the C++14 features (according to Microsoft's documentation, not sure though how true is that).
Additionally, I think we should be totally fine with Apple, since the current Xcode provides a C++17 compatible compiler.

Personally, I am working mostly with Debian 9/GCC 6.3/GCC7.2/Boost 1.63, understandably my setup works perfectly with C++14.

As far as Windows goes, we could go to some lengths ensuring its continuing operation, but hey how important is Windows for the community? Any benefits to using Windows? Just interested.

[abitmore]

Windows is important

• Aex.com exchange is using our pre-built windows binaries.
• many Chinese users run node by their own in Windows machines to reduce load on public API servers.

[pmconrad]

The real question: are there any serious enough reasons to stick to C++11?

The other real question is: what reasons are there to move to C++14?

[abitmore]

The other real question is: what reasons are there to move to C++14?

Perhaps there are new features writing in C++14 already or planed to be written, that are wanted to be merged into the code base?

[aautushka]

The other real question is: what reasons are there to move to C++14?

Firstly, C++14 allows for cleaner code and better coding practices. Secondly, we use it extensively in our development and want to keep using it, including possible future contributions. Besides, updating the standard is not a rocket science really, just a tiny fix, so why not?

[pmconrad]

so why not?

For a blockchain, decentralization is an important goal. We should therefore make it easy to build and run the code on a wide variety of systems, even on old ones.

if the community agrees and provides the list of desired platforms/compilers.

Good question. I think linux systems can be expected to have gcc-5 or newer. Don't know about Mac/Windows compilers.

[jmjatlanta]

As soon as a C++14 feature is used (or in the case of many '14 changes, a certain behavior is expected), we have to draw a line and say if you want to compile version y, you must have a C++14 compliant compiler (or at least one that includes the features we need).

When we draw that line, it will often exclude a segment of the "market". The longer we wait, the smaller that market is.

I would guess that it is safe to say that the majority of mac users are at or near the latest releases of the OS and its compilers (they're free, why not?).

Windows users are a different story, and to be honest I haven't been keeping up over the last 3 years. I do know that I've had trouble compiling Bitshares with VS2017 due to how the compiler handles templates. I've heard that VS2015 doesn't have the same problem, but it is not fully C++14 compatible. So mandating some C++14 features may cause all Windows users to wait until the template problem is sorted before they can use the product.

[pmconrad]

The other real question is: what reasons are there to move to C++14?

Found one: C++14 can move-capture stuff in a lambda-expression.

[ryanRfox]

I'm going to add this into To do on our existing sprint so we invest some time into discussions about C++ 17 (or C++ 14).

[jmjatlanta]

PRs are done to implement this, but there is no consensus as to if we should, and to what degree. I will unassign myself to this ticket and wait for consensus.

[pmconrad]

We're going to discuss (and hopefully decide) this after Easter.

[xloem]

I'd like to add a note that the installed headers don't compile on c++17 atm. There are symbol clashes with the std:: namespace. Building with c++17 would catch things like that.

[jmjatlanta]

BitShares Core will now support c++14 features. The build scripts will be adjusted, probably in the release following 3.2.0.

[pmconrad]

@jmjatlanta Nathan is going to bump fc with the c++14 changes in #1737 - are there any changes required in core for this?

[pmconrad]

There are references to c++11 still in both CMakeLists.txt and libraries/fc/CMakeLists.txt.

[jmjatlanta]

There are references to c++11 still in both CMakeLists.txt and libraries/fc/CMakeLists.txt.

I will fix those as part of #1668

[jmjatlanta]

Note for Visual Studio 2019: This newly released compiler only works with Boost 1.70, as its compiler profile was not included in Boost version 1.69.

Boost 1.70 causes problems with BitShares Core on all platforms (mainly around websocketpp).

Therefore, if you want to use Visual Studio 2019 before we work out the issues with Boost 1.70, you must compile Boost 1.69 on an older compiler that is binary-compatible with Visual Studio 2019. Visual Studio 2017 seems to work. Afterwards, everything else can be compiled with Visual Studio 2019.

Based on the above, I believe we need to document that until the above is fixed, the maximum supported version of Visual Studio is Visual Studio 2017, and the maximum version of Boost is 1.69.

[abitmore]

As mentioned in previous message, docs are needed before closing this.

[abitmore]

Will bump FC in #1695 .

[abitmore]

Bumped FC in #1695.

Docs are still needed for closing this issue:

we need to document that ... the maximum supported version of Visual Studio is Visual Studio 2017, and the maximum version of Boost is 1.69.

[abitmore]

Docs updated. Closing.