we release a new version.)
>
> If users and downstreams have problems with Apache Arrow C++
> that requires C++17, they will still use old Apache Arrow
> C++ that requires C++11 because they can't use our official
> packages that are built with C++17. They will update their
> c
ges that are built with C++17. They will update their
codebase and required Apache Arrow C++ whenever they want.
Thanks,
--
kou
In
"Re: DISCUSS: [C++] Switch to C++17" on Wed, 17 Aug 2022 08:45:34 -0500,
Neal Richardson wrote:
> I have no opinion about the benefits of upgrading to C
+1 (non-binding)
>From having previously run a large C++ project that migrated from C++11 to
C++17, there was a huge quality of life improvement for developers and it
made attracting new developers much easier.
One potential pitfall, C++17 wasn't supported by NVIDIA compilers until
CUDA Toolkit 1
+ 1
After Antoine implemented a work around for an issue with optional::value
[1][2], we were able to successfully build cpp standalone (cpp_build.sh)
and the R package [3] on the 10.13 runner that is setup to match the CRAN
builder. (The run has an R test failure but that is most likely unrelated)
Le 17/08/2022 à 16:52, Weston Pace a écrit :
Sorry for a "one more thing email" but I had one more thought
regarding R 3.6 support for Windows. I think those users should
continue to be able to use Arrow 10.0.0.
Any particular reason why this should be 10.0 and not 9.0 for example?
(is due t
Sorry for a "one more thing email" but I had one more thought
regarding R 3.6 support for Windows. I think those users should
continue to be able to use Arrow 10.0.0. So this would only be an
issue if we detected a critical bug in 10.0.0 (which we could backport
if it was bad enough) or if they w
+1. I'm very much in favor of upgrading to C++17. I am lucky to
often get to work with people that are new to the Arrow C++ code base
and a common feedback is that the code is quite complex. While I do
not think moving to C++17 will solve this problem by itself I'm pretty
confident that being ab
I can definitely vouch for the benefits of upgrading to C++17, it makes
general development significantly more enjoyable!
On that end, I second Neal's suggestion for deployment, that's roughly
the same plan we used in my past experience when performing a compiler
upgrade on a very large codeba
I have no opinion about the benefits of upgrading to C++17. From the R
perspective, there are a handful of packages on CRAN that require C++14 or
C++17. Last year, when I asked other R package maintainers why they hadn't
upgraded to newer C++ standards, the reasoning was that because many
packages
Le 17/08/2022 à 10:48, Jacob Wujciak a écrit :
I am generally in favour of this proposal but would like to mention that we
have to be able to build on MacOS 10.13 for the R package due to CRAN using
it.
The CRAN builder comes with:
Apple LLVM version 10.0.0 (clang-1000.10.44.4); GNU Fortran (GC
I am generally in favour of this proposal but would like to mention that we
have to be able to build on MacOS 10.13 for the R package due to CRAN using
it.
The CRAN builder comes with:
Apple LLVM version 10.0.0 (clang-1000.10.44.4); GNU Fortran (GCC) 8.2.0
Antoine Pitrou schrieb am Mi., 17. Aug.
Hello,
We are in 2022 and Arrow C++ still strives to be compatible with C++11.
Maintaining compatibility has caused us growing pains since third-party
libraries have begun requiring C++14 or later. Boost is warning that it
will soon require C++14
(https://issues.apache.org/jira/browse/ARROW
12 matches
Mail list logo
