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