C++14 #236
C++14 #236
Conversation
This commit requires C++14 support, but compiles for C++17 if supported
The Mac compiler accepts a std=c++17 flag, but there are still some features that don't work (like std::clamp). C++-14 is safe.
Also removed all the linker warnings, as they are almost certainly a local issue and not a project one.
|
As for the new commit about gluProject moved to glm:project, I hope you can remove from README.macos the warning about HUDRenderer.cxx |
| fi | ||
|
|
||
| # C++14 is the minimum standard. C++17 isn't widely available | ||
| #AX_CXX_COMPILE_STDCXX([11], [noext]) |
There was a problem hiding this comment.
If we're moving to C++14 being the new minimum, do we need C++11 commented out?
There was a problem hiding this comment.
I left it for comparison but I’m happy to remove it.
There was a problem hiding this comment.
I don't feel strongly either way about this, I was more so curious about its purpose
There was a problem hiding this comment.
It was there in the first place because I wanted to verify that it compiled that way (C++11) vs the old config as a sanity check. As evidenced by the branch name, I intended to go all the way to C++17, but I found the Mac compiler (at least) has insufficient C++17 support). At one time I had flags for all 3 versions. As I tested, I dropped down to just the one. Say the word and this comment is gone.
There was a problem hiding this comment.
Looks like it builds correctly with c++14 flags via CLI on macOS.
BZFlag 2.5.3 configured on 2019-12-31 with the following:
Prefix: /usr/local
Binaries: /usr/local/bin
Plugins: /usr/local/lib/bzflag
Manual pages: /usr/local/share/man
BUILD_DATE = 2019-12-31
CC = gcc
CXX = g++ -std=c++14
...
Also builds fine on Xcode and can confirm the only two remaining deprecation warnings are those listed in the macOS README.
There was a problem hiding this comment.
Other than the changes to README.macOS, this looks fine to me. As far as whether we actually want to change our C++ standard, that's a decision I'd like to see more discussion about, along with some data on operating system and compiler support. Keep in mind that we haven't even had an official release that fully utilizes C++11, yet.
|
who fixed all the glu warnings? I fixed only the gluProject |
They were suppressed in 82ced1b. It requires running premake again for this to take effect, though. |
I figured this PR would be a forcing function for any discussion, if needed. What form would you like this discussion to take? As to support, clang 10 (MacOS), g++ 4.9, and VS 2017 all support C++14. |
|
It looks like some parts of C++14 need gcc 5 (or maybe even a newer version?). Even in 4.9, some features of C++11 were added, such as support for (see under "Runtime Library (libstdc++)"). I imagine the situation is the same with other compilers. So maybe the conversation should be around which features of newer C++ standards we want to use (not just a blanket "C++14" or "C++17") and which platforms we need to compile on (such as Debian Buster, Visual Studio 2017, macOS 10.13 w/ Xcode 10.1, etc). |
Exactly. Sort of. Rather than getting into a pick-and-choose feature set (although, for what it's worth CMake makes specifying these features easy), I think it is better to choose a minimum compiler version. I would note that our DEVINFO does say that extensions should not be used, so we should require standards conformance and allow developers to write to the standard. We specify versions of things required to build this game (SDL2, for example). We require people to install things (like an alpha version of premake5). We can specify minimum supported compiler. gcc is up to version 9.2; the last 4.9 release was over 3 years ago. Debian Buster has a gcc-7 (7.4) package. Windows VS 2017 supports the C++14 flag (VS 2019 is out). MacOS 10.13 XCode 10.1 clang 10 claims full C++14 compliance. Actually, this page is probably the most useful, with respect to compliance. I guess the question is, for a development head (master) do we really need to lock into the lowest common denominator at this point? I'm not sure I see any reason to avoid adopting a 5-year old standard, but maybe I'm missing something? |
This PR updates our minimum language compliance to C++14, with optional support for C++17.