On Fri, Oct 4, 2019 at 12:45 PM Zhuo Peng <bril...@gmail.com> wrote: > > > > On 2019/10/04 17:05:00, Antoine Pitrou <anto...@python.org> wrote: > > > > Le 04/10/2019 à 19:01, Zhuo Peng a écrit : > > > > > > backports are cool for internal use, but probably not so if a public API > > > accepts it? (because you vendor the headers in (i.e. namespace, symbol > > > names unchanged), they might clash with headers that a client uses). > > > > This is true unfortunately. > > > > >>> And btw, was -std=gnu++11 an intentional choice? what gnu extensions > > >>> does the library rely on? > > >> > > >> None, AFAIK. Arrow compiles on MSVC fine. Where is -std=gnu++11 added? > > > https://github.com/apache/arrow/blob/3129e3ed90219ecfffe2a25ce5820eec8cc947d0/cpp/cmake_modules/SetupCxxFlags.cmake#L33 > > > > > > https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html > > > > Right, so this is a CMake decision. I think we require only plain C++11 > > (but we may enable additional features on some compilers, provided > > there's a fallback). > Extensions can be disabled through: > set(CMAKE_CXX_EXTENSIONS OFF) > > https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_EXTENSIONS.html > > Is that something more desirable than the current state?
Yes, I think so, I don't think we need to be relying on GNU gcc extensions, but we should open a JIRA issue about disabling it in case some tests break because of something we didn't realize we were depending on. As far as C++14/17 upgrading, it seems like it will be at least 2 years before we could upgrade to C++17 given the state of compiler support across the spectrum. Using C++17 would mean requiring at least VS 2017 on Windows, since at least in the Python world I think everything is on VS 2015. Are there ways we could create defines to switch between backports and STL things (like string_view, optional, etc.) so that developers using the Arrow library in a C++17 application can use the built-in types? > > > > Regards > > > > Antoine. > >
