We're already building on some platforms with C++17, so I don't think we'll need to do any code updates. The goal is to make future coding easier by
1) Removing string_view and ink_std_compat.h 2) Enable use of C++17 headers like string_view and file_system. 3) Have a single consistent C++ standard (instead of the 11/14/17/ mix). On Tue, May 8, 2018 at 10:12 AM, Phil Sorber <sor...@apache.org> wrote: > On Tue, May 8, 2018 at 8:43 AM Leif Hedstrom <zw...@apache.org> wrote: > > > > > > > > On May 7, 2018, at 4:10 PM, Phil Sorber <sor...@apache.org> wrote: > > > > > > On Mon, May 7, 2018 at 9:07 AM Bryan Call <bc...@apache.org> wrote: > > > > > >> I would like to propose that we move to C++17 for ATS 8.0.0. This > would > > >> require us to move to gcc 7, clang 5, and icc 18 as minimum versions > for > > >> C++17 support. > > >> > > >> > > > What does this move our minimum EL distro to? Can we still use 6? > > > > > > > > Also, since we went to C++11 a while ago, we already had to give up on > the > > CentOS6 native tool chain (so, for the last year or so, we’ve already > > required Devtoolset to be used). This > > > Yeah, this seems fine to me. > > > > change would force us to update to devtoolset-7 on RHEL platforms, and > > might make some older debian platforms impossible to support in any > > reasonable way (which I’m ok with). > > > > > How do the debian package maintainers feel about that? > > Do we plan to have concerted efforts to go through the code and update to > C++17 paradigms? Or is this to make the new coding work easier? > > I plan on writing some instructions for getting toolchains setup for the > > platforms where it is possible. > > > > +1 from me btw. > > > > Cheers, > > > > — Leif > > > > >
