Can't use std::shared_ptr in Rcpp R 4.3 beta, Rcpp 1.0.10, using (specifically) C++23 about rcpp HOT 17 CLOSED

For posterity, I just gave this a try on my Windows machine and everything worked fine (built in RStudio).

==> Rcpp::compileAttributes()

* Updated src/RcppExports.cpp

==> Rcmd.exe INSTALL --preclean --no-multiarch --with-keep.source testing

* installing to library 'C:/R/R-4.3.0beta/library'
* installing *source* package 'testing' ...
** using staged installation
** libs
using C++ compiler: 'G__~1.EXE (GCC) 12.2.0'
using C++23
g++  -std=gnu++2b -I"C:/R/R-4.3.0beta/include" -DNDEBUG  -I'C:/R/R-4.3.0beta/library/Rcpp/include'   -I"C:/rtools43/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall -gdwarf-2 -mfpmath=sse -msse2 -mstackrealign  -c rcpp_hello.cpp -o rcpp_hello.o
g++ -shared -static-libgcc -o testing.dll tmp.def rcpp_hello.o -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib -LC:/R/R-4.3.0beta/bin/x64 -lR
installing to C:/R/R-4.3.0beta/library/00LOCK-testing/00new/testing/libs/x64
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (testing)

rcpp_hello.cpp has the same contents as in your example, e.g.

#include <memory>

auto foo() {
  return std::make_shared<char>();
}

When did you install Rtools43? The toolchain has been updated and tweaked a bit over time, so it's possible there was some issue that's been fixed in the latest releases.

from rcpp.

I tried running your example -- installation does work for me too:

devtools::install()
── R CMD build ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
* checking for file 'C:\SPB_Data\testrcpp/DESCRIPTION' ... OK
* preparing 'testrcpp':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
Removed empty directory 'testrcpp/R'
* building 'testrcpp_0.0.0.9000.tar.gz'

Running "c:/PROGRA~1/R/R-43~1.0BE/bin/x64/Rcmd.exe" INSTALL "C:\Users\johnr\AppData\Local\Temp\Rtmpik6Yj0/testrcpp_0.0.0.9000.tar.gz" --install-tests 
* installing to library 'C:/Users/johnr/AppData/Local/R/win-library/4.3'
* installing *source* package 'testrcpp' ...
** using staged installation
** libs
using C++ compiler: 'G__~1.EXE (GCC) 12.2.0'
using C++23
g++  -std=gnu++2b -I"c:/PROGRA~1/R/R-43~1.0BE/include" -DNDEBUG  -I'C:/Users/johnr/AppData/Local/R/win-library/4.3/Rcpp/include'   -I"C:/rtools43/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c clinical_code.cpp -o clinical_code.o
g++ -shared -s -static-libgcc -o testrcpp.dll tmp.def clinical_code.o -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib -Lc:/PROGRA~1/R/R-43~1.0BE/bin/x64 -lR
installing to C:/Users/johnr/AppData/Local/R/win-library/4.3/00LOCK-testrcpp/00new/testrcpp/libs/x64
** help
No man pages found in package  'testrcpp' 
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (testrcpp)

I think the key difference is the -O2 flag, which is probably optimising away the offending definition. Either way, this is really useful info (that optimised compilation works), so thanks for pointing it out! Since this is clearly some kind of toolchain issue (not Rcpp) I won't do any more digging. Thanks for all your help.

from rcpp.

Seems like this could be an issue with the toolchain itself -- would be worth checking if this can be reproduced independently of Rcpp.

from rcpp.

There are a number of things going on here.

First, you use rtools, given to you by R Core. We (as in "team Rcpp") have no control over it. I would strongly suggest trying (on another platform where you have choice) g++-13 and clang++-16 on this too (to avoid any issues with rtools) as C++23 is really just completed as a standard and implementations of course always lag -- and g++-12 is not most current. Also note that r-devel prints this even when we use C++17:

* checking C++ specification ... OK
  Not all R platforms support C++17

Second, as an aside and notwithstanding the popularity of it in certain circles, Rcpp never mentions devtools anywhere. So I would consider it polite if you used our tools such as Rcpp::Rcpp.package.skeleton() to create a package or Rcpp::sourceCpp(). CRAN doesn't use it either so we could be stubborn and just ignore it ...

Thjrd, your example is also points at the wrong repo because

In file included from c:/PROGRA~1/R/R-43~1.0BE/include/R.h:71,
                 from C:/Users/johnr/AppData/Local/R/win-library/4.3/Rcpp/include/Rcpp/r/headers.h:66,
                 from C:/Users/johnr/AppData/Local/R/win-library/4.3/Rcpp/include/RcppCommon.h:30,
                 from C:/Users/johnr/AppData/Local/R/win-library/4.3/Rcpp/include/Rcpp.h:27,
                 from code.cpp:1:
c:/PROGRA~1/R/R-43~1.0BE/include/R_ext/Complex.h:65:12: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
   65 |     struct {
      |            ^

as the path clearly shows, Complex.h is an R file. Not an Rcpp file. There was some talk just recently about this on the R mailing lists regarding the complex type and a rust user had issues -- maybe follow up there?

Fourth, we can easily construct a counter example to your claim with what is exactly a valid Rcpp file (yours wasn't even).

So using

#include <Rcpp/Light>

// [[Rcpp::plugins(cpp23)]]
//
// [[Rcpp::export]]
Rcpp::NumericVector doubleMe(Rcpp::NumericVector x) {
  return x + x;
}

/*** R
doubleMe(c(21,22))
*/

and calling in verbose mode to see the standard set I have

> Rcpp::sourceCpp("/tmp/rcpp23.cpp", verbose=TRUE, rebuild=TRUE)

Generated extern "C" functions 
--------------------------------------------------------


#include <Rcpp.h>
#ifdef RCPP_USE_GLOBAL_ROSTREAM
Rcpp::Rostream<true>&  Rcpp::Rcout = Rcpp::Rcpp_cout_get();
Rcpp::Rostream<false>& Rcpp::Rcerr = Rcpp::Rcpp_cerr_get();
#endif

// doubleMe
Rcpp::NumericVector doubleMe(Rcpp::NumericVector x);
RcppExport SEXP sourceCpp_1_doubleMe(SEXP xSEXP) {
BEGIN_RCPP
    Rcpp::RObject rcpp_result_gen;
    Rcpp::RNGScope rcpp_rngScope_gen;
    Rcpp::traits::input_parameter< Rcpp::NumericVector >::type x(xSEXP);
    rcpp_result_gen = Rcpp::wrap(doubleMe(x));
    return rcpp_result_gen;
END_RCPP
}

Generated R functions 
-------------------------------------------------------

`.sourceCpp_1_DLLInfo` <- dyn.load('/tmp/Rtmp4sgyoH/sourceCpp-x86_64-pc-linux-gnu-1.0.10.3.2/sourcecpp_2fad67179db502/sourceCpp_13.so')

doubleMe <- Rcpp:::sourceCppFunction(function(x) {}, FALSE, `.sourceCpp_1_DLLInfo`, 'sourceCpp_1_doubleMe')

rm(`.sourceCpp_1_DLLInfo`)

Building shared library
--------------------------------------------------------

DIR: /tmp/Rtmp4sgyoH/sourceCpp-x86_64-pc-linux-gnu-1.0.10.3.2/sourcecpp_2fad67179db502

/usr/lib/R/bin/R CMD SHLIB --preclean -o 'sourceCpp_13.so' 'rcpp23.cpp' 
ccache g++ -I"/usr/share/R/include" -DNDEBUG   -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/tmp"   -std=c++23 -fpic  -g -O3 -Wall -pipe -pedantic   -c rcpp23.cpp -o rcpp23.o
ccache g++ -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -o sourceCpp_13.so rcpp23.o -L/usr/lib/R/lib -lR

> doubleMe(c(21,22))
[1] 42 44
> 

In conclusion, I do not think we have an Rcpp issue here so I will close this. Please do not hesitate to re-open if you do find another issue related to this that is not in fact toolchain related (as @kevinushey already pointed out while I prepared this reply).

from rcpp.

Also for completeness the fifth point I meant to make -- using R-devel here (from four days ago) it also builds and runs fine albeit with a warning which is not an error:

> Rcpp::sourceCpp("/tmp/rcpp23.cpp")
using C++ compiler: ‘g++ (Ubuntu 12.2.0-3ubuntu1) 12.2.0’
using C++23
In file included from /usr/local/lib/R-devel/lib/R/include/R.h:71,
                 from /usr/local/lib/R-devel/lib/R/library/Rcpp/include/Rcpp/r/headers.h:66,
                 from /usr/local/lib/R-devel/lib/R/library/Rcpp/include/RcppCommon.h:30,
                 from /usr/local/lib/R-devel/lib/R/library/Rcpp/include/Rcpp.h:27,
                 from /usr/local/lib/R-devel/lib/R/library/Rcpp/include/Rcpp/Rcpp:21,
                 from /usr/local/lib/R-devel/lib/R/library/Rcpp/include/Rcpp/Light:25,
                 from rcpp23.cpp:2:
/usr/local/lib/R-devel/lib/R/include/R_ext/Complex.h:65:12: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
   65 |     struct {
      |            ^

> doubleMe(c(21,22))
[1] 42 44
> getRversion()
[1] ‘4.4.0’
> 

So this really points at rtools and I think you know who to talk to. Thanks for trying tools early and pre-release, this is the only way to iron out bugs. Maybe it is too close now to R 4.3.0 which will come out later this month though.

from rcpp.

Thanks very much for the quick response, I will look into all these points.

from rcpp.

Thanks for that. I should have done 4.3-pre-release too but I don't currently have it handy. (Should only be a container away.)

from rcpp.

Thanks @kevinushey, that makes me think I've done something silly. I installed both rtools43 and the R 4.3beta release on the day I opened this issue, to try to avoid submitting something out of date, but I didn't run my example from rstudio. When I get to my computer, I will try to reproduce your working version.

from rcpp.

(Thirty year user of gcc and g++ here: No I don't think -O2 has anything to do with it. Maybe you have gotten caught in the R 4.3.0 pre-release mixing R (on Windows) with a mismatched Rtools.)

(Edit: And @kevinushey is thankfully more thorough and has an actual Windows machine ... Thanks for that!)

from rcpp.

It looks like you might be right; I was able to reproduce with -O0 as well.

==> Rcmd.exe INSTALL --preclean --no-multiarch --with-keep.source testing

* installing to library 'C:/R/R-4.3.0beta/library'
* installing *source* package 'testing' ...
** using staged installation
** libs
using C++ compiler: 'G__~1.EXE (GCC) 12.2.0'
using C++23
g++  -std=gnu++2b -I"C:/R/R-4.3.0beta/include" -DNDEBUG  -I'C:/R/R-4.3.0beta/library/Rcpp/include'   -I"C:/rtools43/x86_64-w64-mingw32.static.posix/include"     -g -O0 -c rcpp_hello.cpp -o rcpp_hello.o
g++ -shared -static-libgcc -o testing.dll tmp.def rcpp_hello.o -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib -LC:/R/R-4.3.0beta/bin/x64 -lR
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: c:/rtools43/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/12.2.0/libstdc++.a(tinfo.o):(.text$_ZNKSt9type_infoeqERKS_+0x0): multiple definition of `std::type_info::operator==(std::type_info const&) const'; rcpp_hello.o:c:/rtools43/x86_64-w64-mingw32.static.posix/lib/gcc/x86_64-w64-mingw32.static.posix/12.2.0/include/c++/typeinfo:194: first defined here
collect2.exe: error: ld returned 1 exit status
no DLL was created
ERROR: compilation failed for package 'testing'
* removing 'C:/R/R-4.3.0beta/library/testing'
* restoring previous 'C:/R/R-4.3.0beta/library/testing'

Exited with status 1.

Still though; feels like an issue in the toolchain / compiler rather than Rcpp itself. It might be worth a bug report for the R Core team.

from rcpp.

😮

from rcpp.

OK, sounds good, I'll look into submitting it to R Core. Thanks very much for your help.

from rcpp.

Sure. Please keep in mind that this seems to be changing / is being looked at by them too. So if / when you do. make sure you refresh to the then newest.

We also didn't touch on one meta question: why C++23? Are you sure you need it?

from rcpp.

Yep will do. Regarding C++23 -- no, I don't need it. I am currently using C++20 (the one I do need), with all going well until the other day, when I tried to build on windows (I had been developing the code on linux) and it didn't compile.

I turns out that I am using the new behaviour of std::join_view as defined by P2328R1 (for details, see the examples at the end of the reference page). This was working fine on Ubuntu 22.04, where I was building with cmake (outside Rcpp) and passing the flag -std=c++20). It turns out however, that the P2328R1 behaviour change is not available with the -std=gnu++2a which gets passed when you specify CXX_STD=CXX20 in Makevars. The issue isn't the gnu, it's the 2a -- as described here, this flag was present in GCC 9, and even though we're on to gcc 12, I'm assuming that for backwards compatibility reasons they kept the old PR2328R1 behaviour. I haven't checked on Ubuntu, but I have no reason to think -std=c++2a also doesn't work there specifically with regard to this issue.

So that was how I ended up on the whole C++23 thing, because I thought that was the easiest fix! Since then however, I've also realised I can just pass -std=c++20 via PKG_CXXFLAGS. This feels a bit hacky, because it puts -std=c++17 at the front and then appends -std=c++20 later, but gcc takes the latest one so it works fine.

I did wonder if maybe something could be modified to make std=c++20 (or -std=gnu++20) work via CXX_FLAGS if you have a recent enough compiler (i.e. gcc 10 I think, see here)? I saw in this pr that the logic for the 2b was to cover more compilers, which I get -- however, the -std=gnu++20 flag would fix my underlying problem. Happy to provide further details if this isn't too small (or open a new issue) -- otherwise, I have a solution for now so I'm all good!

from rcpp.

Thanks for context. I just wanted to be sure "you are aware".

On Windows, rtools is all there is. Ten-plus years ago we could not even do C++11 (fully, its standard library was incomplete), and were really ham-struck on a g++-4.9.5 instance for ever. Thanks to more or less two years of work by Jeroen this jumped to g++-8, we since (thanks to Tomas) made it to 10 and soon 12 R 4.3.*. But no further. And macOS effectively also has prescribed tools by whatever Simon does.

So simply by hoping "well this exists on Linux and is a language standard" you won't get too far. We do not control what compiler builder roll out when and where. Or worse, how far behind some users are.

I am in similar situation: at $work we will soon switch to C++20 internally (for a fairly large library) but will aim to keep it at C++17 in the interface (for a example in the R package I maintain at CRAN). Note that when you use C++17 (six years old!!) even r-devel now prints a message stating 'C++17 support not uniformaly available' and that is entirely true!

I maintain a few handful of packages on CRAN and I can assure you that even C++17 can be a pain because it gets you a constant drip of users still on RHEL/CentOS 7 and unaware of devtoolset.

Lastly, CRAN Policy also says that language standards should be passed as CXX_STD=...., not via PKG_*FLAGS. That way R can sort it out as best as it can.

Anyway, long story short: We all established now this never was a Rcpp. You are pushing it with build requirements, Rcpp is a tool in your arsenal but your real constraints are the R tools.

from rcpp.

Actually specifically about my point above: I just tried putting CXX_STD=CXX20 in Makevars just now and it worked (added -std=gnu++20)! I have no idea what is different to my other computer (my current computer is R 4.3.0 alpha and I think the other was R 4.3.0 beta, both rtools43 from the last few days) -- but perhaps there is no problem in the new R 4.3.0. Either way my code is back compiling so I'm happy! Thanks for all your help.

(edit: fixed typo, changed CXX_FLAGS to CXX_STD)

from rcpp.

Sure, of course "it works" as R and make faithfully bring it to the compiler.

But Writing R Extensions and CRAN Policy firmly ask you do to it via CXX_STD (and optionally also via SystemDependencies).

For an internal package you are all set: it works. If you ever were to upload it to CRAN, not so much. No more no less.

from rcpp.