I opened https://issues.apache.org/jira/browse/ARROW-6800.
On Fri, Oct 4, 2019 at 3:42 PM Wes McKinney <wesmck...@gmail.com> wrote: > > On Fri, Oct 4, 2019 at 3:18 PM Zhuo Peng <bril...@gmail.com> wrote: > > > > > > > > On 2019/10/04 19:43:04, Wes McKinney <wesmck...@gmail.com> wrote: > > > 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. > > sg. I'll create one then. > > > > > > 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? > > This is dangerous unless they build the Arrow library from source with > > C++17. if libarrow takes arrow::string_view but the user gives it a > > std::string_view, it's UB. > > > > If we are talking about allowing users to build Arrow with C++17 and > > support transparently the new STL types in the public APIs, the ABSL[1] > > library could be something to consider.. > > absl::{string_view,optional,variant} becomes their std:: counterparts when > > compiled under C++17, e.g. [2]. > > > > Yes, the presumption would be a monotoolchain environment, and Arrow > would need to have some CMake options to build in C++17 mode > > > And inline namespaces are used [3] to make sure different libraries can > > depend on different version of absl. > > > > [1] https://abseil.io/ > > [2] > > https://github.com/abseil/abseil-cpp/blob/25597bdfc148e91e27678ec30efa52f4fc8c164f/absl/strings/string_view.h#L38 > > [3] > > https://github.com/abseil/abseil-cpp/blob/aa844899c937bde5d2b24f276b59997e5b668bde/absl/strings/string_view.h#L38 > > > > > > > > > > > > > Regards > > > > > > > > > > Antoine. > > > > > > > >
