See also the previous thread Is switching to C++14 considered? by @kparzysz
As we start to move to 0.7, we want to revive the discussion about C++14 requirement. It becomes more important because:
std::string_view(it was experimental in c++14) to support some of our container features without introducing a lot boilerplate.Please share your thoughts
I only worry about the runtime part. Many edge devices doesn’t have C++14 support, especially new features of standard library like string_view you mention.
I would like we keep our runtime part be C++11 currently or we could use macro to control whether we use C++14 feature. For example, like std::string_view, we could have tvm::string_view, if users compile runtime using C++14, we use std::string_view, otherwise we use our implementation.
It would be good to look into cxx14 coverage. We can certainly make sure runtime still compiles with cxx11.
For reference, the current related PR is here https://github.com/apache/incubator-tvm/pull/4628 which is still compatible with c++11, but will be slower(because we need to use the std hash of a string )
string view comes into std in c++17, but is available in compilers that support c++14 via std::experimental
From what we have seen, the requirement of c++14 comes with gcc-5 while the original c++11 support comes with gcc-4.8
I think it is fine. As GCC 4.8 is the default compiler of Ubuntu 14.04, whose life cycle ie ended at 4 / 30, 2019. Since Ubuntu 16.04, we have GCC 5 now.
Canonical reference that I use is here.
https://gcc.gnu.org/projects/cxx-status.html
GCC-5 should be good enough on Ubuntu16.04 and we should be able to switch over to c++14.
Ramana
Seems we are converging on switching. Thanks everyone for discussions so far. Leaving this thread for a few more days before we commit.
I’m in favor of switching the current reference compilers are incredibly old, and have limited 14 support, let alone 17 or 20. I’m ok using an older version for the runtime, but it would be nice to move the compiler into the modern age.
I agree that moving to C++14 is a good idea. As a measurement of the industry, TF stopped shipping packages compiled with GCC4.8 in the 1.15 and 2.0 releases
They are using GCC7.3, and the manylinux2010 package supports GCC8.1
Seems MXNet (which uses TVM as submodule) is still stuck on c++11?
There are two possibilities:
T1 is certainly more ideal in the long run, given the compiler situation(e.g. LLVM codebase switch ti c++14), it might be interesting to see whether the dependent packages would like to switch over. T0 is certainly doable, given that there are not a lot of new features in c++14.