[jira] [Comment Edited] (ARROW-17110) [C++] Move away from C++11

["H. Vetinari (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARROW-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568066#comment-17568066 ] 

H. Vetinari edited comment on ARROW-17110 at 7/18/22 3:38 PM:
--------------------------------------------------------------

> We still have to support down to GCC 4.8 (for some older R versions at least) 

Where is the lower bound of R support defined (and how/why)? I tried looking but couldn't find anything. I think it'd be a good idea to define some sort of support policy (note, we did this in scipy over the last year or so, allowing us to move from 4.8 to 6.x and [now|https://github.com/scipy/scipy/pull/16589] to 8.x).

> And even then I think C++14 will be the highest attainable version

Barring some progress on the lower bounds for compilers, you'll then be limited from upgrading abseil beyond 20220623.0 (and that's already working more or less by accident since 20211102 on unix is compiled with C\+\+17 in c-f. Unless we introduce multiple builds per CXX version in conda-forge, this problem will only get worse, because once vc142 becomes the minimum toolchain in the not too distant future, c-f can move to C\+\+17 also on windows globally).


was (Author: h-vetinari):
> We still have to support down to GCC 4.8 (for some older R versions at least) 

Where is the lower bound of R support defined (and how/why)? I tried looking but couldn't find anything. I think it'd be a good idea to define some sort of support policy (note, we did this in scipy over the last year or so, allowing us to move from 4.8 to 6.x and [now|https://github.com/scipy/scipy/pull/16589] to 8.x).

> And even then I think C++14 will be the highest attainable version

Barring some progress on the lower bounds for compilers, you'll then be limited from upgrading abseil beyond 20220623.0 (and that's already working more or less by accident since 20211102 on unix is compiled with C++17 in c-f. Unless we introduce multiple builds per CXX version in conda-forge, this problem will only get worse, because once vc142 becomes the minimum toolchain in the not too distant future, c-f can move to C++17 also on windows globally).

> [C++] Move away from C++11
> --------------------------
>
>                 Key: ARROW-17110
>                 URL: https://issues.apache.org/jira/browse/ARROW-17110
>             Project: Apache Arrow
>          Issue Type: Task
>          Components: C++
>            Reporter: H. Vetinari
>            Priority: Major
>
> The upcoming abseil release has dropped support for C++11, so {_}eventually{_}, arrow will have to follow. More details [here|https://github.com/conda-forge/abseil-cpp-feedstock/issues/37].
> Relatedly, when I [tried|https://github.com/conda-forge/abseil-cpp-feedstock/pull/25] to switch abseil to a newer C++ version on windows, things apparently broke in arrow CI. This is because the ABI of abseil is sensitive to the C++ standard that's used to compile, and google only supports a homogeneous version to compile all artefacts in a stack. This creates some friction with conda-forge (where the compilers are generally much newer than what arrow might be willing to impose). For now, things seems to have worked out with arrow [specifying|https://github.com/apache/arrow/blob/897a4c0ce73c3fe07872beee2c1d2128e44f6dd4/cpp/cmake_modules/SetupCxxFlags.cmake#L121-L124] C\+\+11 while conda-forge moved to C\+\+17 - at least on unix, but windows was not so lucky.
> Perhaps people would therefore also be interested in collaborating (or at least commenting on) this [issue|https://github.com/conda-forge/abseil-cpp-feedstock/issues/29], which should permit more flexibility by being able to opt into given standard versions also from conda-forge.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)