ibaned
commented
7 years ago Just to add an anecdote, I spent some time this week porting C++11 code back to C++98 for #1371, so for one thing that is an example of C++98 support costing us time. I'd also like to list the C++11 features that stood out the most as being missed:
-
Extended initializer lists. I didn't think this would be number one, but in retrospect it is (it was being used heavily to concisely build complex data structures):
void foo(std::vector<std::string> const& v); foo({"one", "two", "three"}); -
Move semantics. This includes
std::move, support for instd::vector::resize, and theemplacemethods ofstd::containers. The closest alternative in C++98 is what I'll call "swap semantics", which is less intuitive, more error prone, and has less support inside the STL itself (std::vector::resizecould still be much slower than with C++11). -
Range-based for loops:
std::set<std::string> myset; for (auto& str : myset) std::cout << str << '\n'; -
autodeclarations -
std::shared_ptrandstd::unique_ptrfor memory management.
The code in question didn't leverage templates very much, but if it did then <type_traits> such as std::is_same would be high on the list (and auto would be higher).
There is one more feature which is at the heart of this particular library, and that is std::any from C++17. Currently we have to use a custom implementation (Teuchos::any), but this is all the more reason to keep up with newer standards.
This all affects the design of the API itself, so it has long-lasting consequences.
bartlettroscoe
hkthorn
jwillenbring
nmhamster
mhoemmen
briadam
etphipp
rppawlo
CC: @trilinos/framework, @trilinos/teuchos, @trilinos/thyra, @trilinos/nox, @maherou
Description:
The requirement to maintain C++98 support for older packages like Teuchos, Thyra, NOX and others that are still being developed and need much more development in the near future, is creating a major capability and productivity impediment for projects like ATDM. (For example, the refactoring of Thyra to improve the design, usage, and performance of RTOps will require C++11.) But we can't use C++11 in these packages because there are still some Trilinos customers that still require that these packages build with GCC 4.4.7 and C++11 turned off. And just the usage of
autoalone will significantly improve the development and maintenance of templated code. (And then there is the performance improvements of using move constructors and assignment operators, etc.)To address this problem we could either, for example:
1) Require all Trilinos customers to upgrade their compilers to GCC 4.9.3 or newer to allow C++11 to be used in all Trilinos packages from Teuchos on down the dependency chain.
or:
2) Create a fork of Trilinos for C++98 packages needed by these customers and then allow the main Trilinos 'develop' and 'master' branches require C++11 for all packages from Teuchos on down the dependency chain. (This would require the Trilinos development team to continue to provide patches, releases, and address other issues on this fork, so this fork could not be completely static but it should see very little development.)
But eventually every Trilinos customer will have a C++11 compiler so eventually we will be going with option-1 so going with option-2 in the short-term may not be too bad.