[arcuru]

Closes #189

This change updates CMakeLists.txt files, Travis CI, and the docs so that the track requires C++14 instead of C++11. As much as I would like to just jump to C++17, it's better to support students that are running older OSes. The students doing that are often the same students that would have trouble installing a newer compiler outside of their OS's standard installation methods.

As I explained in a comment in #189, it makes sense to do this now since even the latest Ubuntu LTS version (18.04 bionic) has a default compiler that supports C++14. The new required minimum compiler versions are what ships with that version (clang 6 and gcc 7).

[KevinWMatthews]

@patricksjackson I think this should be fine. Our minimum required CMake version, v3.1.3, supports C++14 so we shouldn't need to bump that unless you want to. Probably safer to make that a separate PR if you do?

[arcuru]

Ah, I didn't even think of CMake compatibility. It looks like the CI uses v3.5.1, so we might have missed that if it didn't work.

I don't think we should bump the CMake version unless we're actually using something from a newer version. The Standard change gives us something (newer standards for the students and here) but a CMake bump wouldn't buy us anything AFAIK. Does that make sense?

If there is some useful thing we can get in CMake by bumping up to ~3.10 then I'm all for it.

[KevinWMatthews]

I can't think of any modern features that we require, but it'd be good to test CMake v3.1 just to be sure.

I know that module support tends to improve significantly (FindDoxygen, FindBoost, etc) but we don't have need of them. Well, we do still use Boost for two exercises, right?

It looks like C++17 support landed in v3.8, so we'll want to upgrade when we bump the C++ standard to 17.

[arcuru]

Actually, while trying to check how to test with CMake 3.1 I noticed that we might actually have all the requirements to jump to C++17.

C++17 support is in:

• CMake 3.8. Ubuntu LTS has 3.10.
• GCC 7 (with only 1 small change in GCC8). Ubuntu LTS has 7.3.
• Clang ~6 (except for std::filesystem) Ubuntu LTS has Clang 6.
• Visual Studio 2017 (already a requirement).
• Macs have Homebrew, which will install the latest toolchains easily.

Basically it's the same requirements as this change already, there might be a few minor breakages but that's it. What do you think?

[KevinWMatthews]

Hmmm, I hesitate to raise the minimum requirement too high. It'd be a shame to force a user to upgrade a supported LTS distro just to compile our C++ exercises.

Ubuntu 16 LTS is supported at least until 2021 and that ships with CMake 3.5.1. :/

My home laptop is running Linux Mint 18.3 (one behind the latest), which is supported until 2021. This also ships with CMake 3.5.1. I guess I'd have to upgrade....

Maybe we can make it a CMake option to select the C++ standard? It can default to 14 but allow the user to select 17 (or 11?). I can make an example of an option list/drop-down menu in ccmake/cmake-gui.

[arcuru]

TL;DR - Ok, let's make the min versions match Ubuntu 16.04/Linux Mint 18. Those all support C++14. Clang 3.8, GCC 5.3, CMake 3.5.1. I'll update this PR with those changes and get those specific versions running on Travis.

There's been pushback about making it an option before. The mentors very often download and run the code locally, so mentors would have a different requirement than students, and there would often be different advice if the student was trying to use C++17. I would want to just do that, but I think it complicates the mentoring process too much.

I see, Linux Mint 18.X is based off Ubuntu 16.04, so that's the same problem. My thinking has always been that if you really want to develop on an LTS release, especially LTS-1, you have to know how to install an updated toolchain on it. Whether a distro will support a release has little to do with being able to develop on it. But I get that people on older LTS versions are also often students who wouldn't know how to, like if they're using a school provided distro. It almost makes me want to just provide a container for everyone.

The problem then is really that we'd need to maintain very good instructions for updating your toolchain on older distros, and I'm not really prepared for that.

[arcuru]

@KevinWMatthews can you confirm this branch builds on your Linux Mint 18 machine? I had to install the updated gcc libs to get clang to compile (it uses libstdc++ by default on these old builds, so it was failing because the travis build is on 14.04 and had libstdc++ 4.8 installed), but that updated version should be already installed on Ubuntu 16.04.

Also had to fix the same issue we hit in #287 (comment)

[KevinWMatthews]

@patricksjackson Works for me. I can build this branch patricksjohnson/cpp14 fine with my Linux Mint's deafult gcc 5.4.0 and CMake 3.5.1.

I see what you mean about an option; the mentor wouldn't know what the student actually built without extra feedback.

I agree that if you want to develop seriously one will need to learn how to install the correct build tools. As a student, however, it's yet another hurdle that can keep you from getting started.

I actually use a container for most of my development, including for exercism. It's a very useful tool but might a bit overwhelming for a beginning student.

[arcuru]

Yea, I dredge up impractical solutions (in this case containers) when I get a bit frustrated. I know it's not feasible, but wouldn't it be nice :)

Also, I'll mention here that I manually tested this on Visual Studio as well with no issues.

@KevinWMatthews I think this is done. If you agree feel free to merge :)

I'll probably mention it on the Slack channel once it goes in at least. Some people have been asking for this update.

[KevinWMatthews]

@patricksjackson we missed circular-buffer. Will open a new PR for this.