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. > > > > > >
