Should Octave switch to C++17? If so, when?

Octave’s C++ codebase is largely in C++11. Last month, a C++17 polymorphic allocator feature was added (see octave: abb4823df535 and octave: 9b41aba64c12) to fix bug 61472 GNU Octave - Bugs: bug #61472, AddressSanitizer crash in MEX tests [Savannah]. That code has been made optional with a configure-time flag.

Currently there is bug report 61800 about using C++17 to shorten and simplify code pertaining to octave_value GNU Octave - Bugs: bug #61800, possible code simplification with... [Savannah]. It is perceived as too much effort to maintain two different versions of octave_value, favoring a single lane instead, so the following questions need to be discussed.

  • Should Octave raise its minimum C++ level from C++11 to C++17? This will affect minimum compiler versions and standard library versions to build Octave.

  • If so, starting from what Octave version? 8? 9? Beyond 9?

  • What are the consequences for package maintainers, oct files and mex files?

Some data:

The effect on packages or user C++ code depends on where we’d like to use the new language features. If we use them only internally, the effect on packages or user C++ code would probably be minimal.
If we’d like to use these features in the interfaces (API), packages and user C++ code must be compatible with C++17 and they also have to be compiled with that (minimum) version.
Most compilers support most C++17 features currently. However, there are quite a few Octave packages that compile with -std=c++11 or -std=gnu++11 in their build rules. Those packages would no longer compile if features that aren’t available in that standard version are used in Octave’s API. User code might also be affected similarly.

I don’t know if someone has checked in detail why those packages set -std=c++11 or -std=gnu++11 in their build rules. Maybe they need features that were introduced in C++11 (but are also available in later versions of the standard). Maybe, they need that specific version of the standard to work correctly (and won’t work correctly without modifications with newer standard versions)…

Edit: Both features you are hinting at make changes in Octave’s API IIUC.
Taking this into consideration, we should probably give notice sufficiently in advance to give developers time to adapt their code/build rules for this change in requirements. Maybe one or two major versions is enough time for that. I.e., if we decide now to give notification of that change with the release of Octave 7, we could maybe use those features in the API of Octave 8 or 9.

Edit 2: Depending on which features of the C++17 standard we’d like to use, the minimum GCC version might be GCC 8 (according to the above link). The minimum clang might be version 6.
For features that are implemented in the STL, the minimum version might be GCC 12 (libstdc++). Not all features are currently implemented in libc++ (clang or Apple clang).
See also Compiler support for C++17 -

1 Like

I will use this comment to make a list of action items as we go along. I’ll edit as new information comes in and hopefully it’ll help as we converge.

  • Action item for core maintainers: add a note to NEWS for Octave 7 that Octave will require C++17 to build starting from version _____ (to be decided in this discussion).

  • Action item for package maintainers: if your package currently requires -std=c++11 or similar flags, examine whether your package will build without them.

I don’t think [GNU Octave - Bugs: bug #61800, possible code simplification with... [Savannah]] in its current state changes the API, no data members are changed or added to octave_value, only member functions are added, no existing methods removed or changed.

Compiling octave on an old platform is not for the faint hearted anyway. I have recent experience on a RHEL 6.2, that came for instance with gcc 4.x, qt4.3. In order to built a fully functional recent octave version you will have to install (qt5.7 was the latest pre-built suitable for that platform) or build your own more recent versions of quite a few libraries. gcc 9 was the latest I built on that platform.

I guess anyone determined enough to attempt building a recent version of octave on such a platform can be expected to be able to build a c+±17 compatible environment.

If I read those changes correctly, ov.h will include AnyDiag.h which in turn includes <variant>. That header won’t be available with e.g. -std=gnu++11 (independent of the used compiler version). That means that some Octave packages won’t compile any longer. I’d consider that an API change…

I agree. Most compilers that are able to compile Octave should also be able to compile most C++17 features. That’s what I was trying to describe with using those features internally.
However, public facing headers are also included in other projects (mostly Octave packages or C++ user code). If newer features are used in those public facing headers, we should probably measure differently…

I propose requiring C++17 starting from Octave 8, the changeover to be made to the dev sources sometime after Octave 7.1 is released in the next several weeks.

I believe that will give enough time (a year or more) for package maintainers to switch if necessary, based on time intervals between major releases for recent releases.

Does anyone see anything wrong with adding C++17 for Octave 8?

IIRC, Qt6’s API requires C++17, too. Another possible timeframe could be to allow C++17 in Octave’s API when we start supporting Qt6.
That’s likely not going to happen before Qt6 is readily available on Debian based distributions though…
See also: Qt5.15 already unsupported upstream (except commercial license)?

1 Like