search

libMesh / libmesh

libMesh github repository
http://libmesh.github.io
GNU Lesser General Public License v2.1
654 stars 287 forks source link

Upgrade C++ standard support #2635

Open roystgnr opened 4 years ago

roystgnr commented 4 years ago

Much discussion on Slack with @lindsayad and @jwpeterson seems to boil down to:

  1. In the short term, we need --enable-cxx14 and --enable-cxx14-required arguments, working the way their cxx11 equivalents currently do, so MOOSE can make it easier for its users to identify the problem and recover if their upcoming C++14 code runs into a user's environment which lacks (and/or requires compiler flags for) C++14 support

  2. We ought to be generalizing this in the long term. Something like e.g. --enable-cxx-maximum c++20 --enable-cxx-minimum c++14 if we want configure to try to enable C++20 but to settle for C++17 or C++14 if that's all that's supported. With no maximum argument we'd just use our current behavior, where we let the compiler defaults rule except when we find that our minimum standard requirement is unsupported without an explicit compiler argument.

  3. At that point we ought to have a simple --enable-cxx-std for people who want to tersely set the same minimum and maximum: i.e. use the exact std we specify or scream and die.

  4. Modern C++ compilers (especially g++/clang++) are pretty good about not half-supporting core language features unless you specifically request a still-under-development standard, so we can probably get away with testing a few features (and possibly the __cplusplus macro) and calling a passed result "C++XX support" for any XX newer than 11.

  5. Modern C++ standard libraries (even libstdc++/libc++) seem to get more piecemeal support, so for those we might have to do what we did with C++11, adding more tests as we or our users rely on more library features.

  6. C++14 doesn't seem quite tempting enough to make it a minimum requirement for libMesh even when MOOSE upgrades.

  7. C++17 has some syntactic sugar which is very tempting, so we may want to upgrade libMesh directly to that once we're comfortable that we won't be leaving any users out in the cold, but that's not going to be in the near future.

roystgnr commented 3 years ago

A quick update on (7):

One of my reasons for wanting to stick with C++11 for so long was that I know we had users stuck on RHEL7 and derivative systems, for which GCC 4.8.x was the standard and there was no C++14 support out of the box.

But, RHEL8 came out mid-2020, it has GCC 8 (which supports all of the C++17 language improvements and most of the standard library improvements) by default, and it makes GCC 9 (which supports it all) an easy install, so unless there are other widely used environments with "C++14 but not C++17" support, I think "just jump to C++17" really ought to be our plan, I'd say by the end of this year or early next.