You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently build all our C++ code with C++14 (#152). At some point we will want to move to C++17.
Unlike C++11/14, which are effectively backward compatible with correctly-written C++98/03, C++17 removes a few features. Here are the major ones that matter to our code:
Unfortunately, MMCoreJ currently uses exception specifiers, which are mapped to Java throws caluses by SWIG. While SWIG has alternative ways to specify this information, we will need to figure out a way to ensure that the MMCoreJ Java API does not change as we migrate. Also, we probably want to be using SWIG 4 before even getting started with this (see #37).
For this reason, I propose that we postpone a bulk switch to C++17 for the time being. If we successfully transition to individual C++ projects as outlined in micro-manager/micro-manager#1392, it will become trivial to enable C++17 (or even C++20) for individual projects as needed. (If absolutely needed, we might also be able to enable it for a particular device adapter under the current build systems, though it would be nice to avoid that if possible. Probably slightly better to make MMCoreJ the exception in that case.)
The text was updated successfully, but these errors were encountered:
Note: The Visual Studio 2019 toolset (v142) that we currently use defaults to C++14 without an explicit /std:c++17 set in the project files. For macOS/Linux, the default C++ version is set in the configure.ac files.
We currently build all our C++ code with C++14 (#152). At some point we will want to move to C++17.
Unlike C++11/14, which are effectively backward compatible with correctly-written C++98/03, C++17 removes a few features. Here are the major ones that matter to our code:
std::auto_ptr
needs to be removed (replace withstd::unique_ptr
, plus fixes if the pointer is copied) Eliminate deprecated std::auto_ptr #177Unfortunately, MMCoreJ currently uses exception specifiers, which are mapped to Java
throws
caluses by SWIG. While SWIG has alternative ways to specify this information, we will need to figure out a way to ensure that the MMCoreJ Java API does not change as we migrate. Also, we probably want to be using SWIG 4 before even getting started with this (see #37).For this reason, I propose that we postpone a bulk switch to C++17 for the time being. If we successfully transition to individual C++ projects as outlined in micro-manager/micro-manager#1392, it will become trivial to enable C++17 (or even C++20) for individual projects as needed. (If absolutely needed, we might also be able to enable it for a particular device adapter under the current build systems, though it would be nice to avoid that if possible. Probably slightly better to make MMCoreJ the exception in that case.)
The text was updated successfully, but these errors were encountered: