On 2/12/24 01:35, Simon Urbanek wrote:
Just to include the necessary details: macOS CRAN build uses Apple clang-14, so
you cannot assume anything higher. Also the target is macOS 11 SDK.
That said, LLVM does not support the special math functions at all according to
the status report (see Mathematical Special Functions for C++17 at
https://libcxx.llvm.org/Status/Cxx17.html) so Boost is your best bet.
BTW: this is not a Mac thing - you can replicate it on any other system, eg. in
Linux:
$ clang++-17 -std=c++17 -stdlib=libc++ bes.cc
bes.cc:11:49: error: no member named 'cyl_bessel_k' in namespace 'std'
11 | std::cout << "K_.5(" << x << ") = " << std::cyl_bessel_k(.5, x) <<
'\n'
| ~~~~~^
bes.cc:13:35: error: no member named 'cyl_bessel_i' in namespace 'std'
13 | << (pi / 2) * (std::cyl_bessel_i(-.5, x)
| ~~~~~^
bes.cc:14:25: error: no member named 'cyl_bessel_i' in namespace 'std'
14 | - std::cyl_bessel_i(.5, x)) / std::sin(.5 * pi) <<
'\n';
| ~~~~~^
3 errors generated.
And on Windows with LLVM 17, the experimental build of Rtools43 for
Windows/aarch64.
Tomas
Cheers,
Simon
On 10/02/2024, at 8:04 AM, Marcin Jurek <marcinjurek1...@gmail.com> wrote:
All this makes sense, thanks for your tips, everyone!
Marcin
On Fri, Feb 9, 2024 at 9:44 AM Dirk Eddelbuettel <e...@debian.org> wrote:
On 9 February 2024 at 08:59, Marcin Jurek wrote:
| I recently submitted an update to my package. It previous version relied
on
| Boost for Bessel and gamma functions but a colleague pointed out to me
that
| they are included in the standard library beginning with the C++17
| standard.
There is an often overlooked bit of 'fine print': _compiler support_ for a
C++ standard is not the same as the _compiler shipping a complete library_
for that same standard. This can be frustrating. See the release notes for
gcc/g++ and clang/clang++, IIRC they usually have a separate entry for C++
library support.
In this case, can probably rely on LinkingTo: BH which has been helping
with
Boost headers for over a decade.
Writing R Extensions is also generally careful in reminding us that such
language standard support is always dependent on the compiler at hand. So
package authors ought to check, just like R does via its extensive
configure
script when it builds.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
