Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit Rcpp:: in the initalize method for C++ classes wrapped inside modules #980

Merged
merged 1 commit into from Jul 21, 2019

Conversation

@riccardoporreca
Copy link
Contributor

riccardoporreca commented Jul 21, 2019

Otherwise the Rcpp functions are unknown when objects are initialized, unless Rcpp is attached.

inc <- '
class World {
public:
    World() {};
    std::string greet() { return "hello"; };

};
RCPP_MODULE(yada){
    using namespace Rcpp ;
    class_<World>("World")
    .constructor()
    .method("greet", &World::greet)
    ;
}
'
fx <- inline::cxxfunction(signature(), plugin = "Rcpp", include = inc)
yada <- Rcpp::Module("yada", inline::getDynLib(fx))
new(yada$World)$greet()
#> Error in cpp_object_initializer(.self, .refClassDef, ...): could not find function "cpp_object_initializer"
library(Rcpp)
new(yada$World)$greet()
#> [1] "hello"

Created on 2019-07-21 by the reprex package (v0.3.0)

Session info
devtools::session_info()
#> ─ Session info ──────────────────────────────────────────────────────────
#>  setting  value                       
#>  version  R version 3.6.1 (2019-07-05)
#>  os       Ubuntu 18.04.2 LTS          
#>  system   x86_64, linux-gnu           
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_US.UTF-8                 
#>  ctype    en_US.UTF-8                 
#>  tz       Europe/Zurich               
#>  date     2019-07-21                  
#> 
#> ─ Packages ──────────────────────────────────────────────────────────────
#>  package     * version date       lib source                        
#>  assertthat    0.2.1   2019-03-21 [1] CRAN (R 3.6.0)                
#>  backports     1.1.4   2019-04-10 [1] CRAN (R 3.6.0)                
#>  callr         3.3.1   2019-07-18 [1] CRAN (R 3.6.1)                
#>  cli           1.1.0   2019-03-19 [1] CRAN (R 3.6.0)                
#>  codetools     0.2-16  2018-12-24 [4] CRAN (R 3.5.2)                
#>  crayon        1.3.4   2017-09-16 [1] CRAN (R 3.6.0)                
#>  desc          1.2.0   2018-05-01 [1] CRAN (R 3.6.0)                
#>  devtools      2.1.0   2019-07-06 [1] CRAN (R 3.6.1)                
#>  digest        0.6.20  2019-07-04 [1] CRAN (R 3.6.1)                
#>  evaluate      0.14    2019-05-28 [1] CRAN (R 3.6.0)                
#>  fs            1.3.1   2019-05-06 [1] CRAN (R 3.6.0)                
#>  glue          1.3.1   2019-03-12 [1] CRAN (R 3.6.0)                
#>  highr         0.8     2019-03-20 [1] CRAN (R 3.6.0)                
#>  htmltools     0.3.6   2017-04-28 [1] CRAN (R 3.6.0)                
#>  inline        0.3.15  2018-05-18 [1] CRAN (R 3.6.1)                
#>  knitr         1.23    2019-05-18 [1] CRAN (R 3.6.1)                
#>  magrittr      1.5     2014-11-22 [1] CRAN (R 3.6.0)                
#>  memoise       1.1.0   2017-04-21 [1] CRAN (R 3.6.0)                
#>  pkgbuild      1.0.3   2019-03-20 [1] CRAN (R 3.6.0)                
#>  pkgload       1.0.2   2018-10-29 [1] CRAN (R 3.6.0)                
#>  prettyunits   1.0.2   2015-07-13 [1] CRAN (R 3.6.0)                
#>  processx      3.4.1   2019-07-18 [1] CRAN (R 3.6.1)                
#>  ps            1.3.0   2018-12-21 [1] CRAN (R 3.6.0)                
#>  R6            2.4.0   2019-02-14 [1] CRAN (R 3.6.0)                
#>  Rcpp        * 1.0.2   2019-07-21 [1] Github (RcppCore/Rcpp@84c787f)
#>  remotes       2.1.0   2019-06-24 [1] CRAN (R 3.6.0)                
#>  rlang         0.4.0   2019-06-25 [1] CRAN (R 3.6.0)                
#>  rmarkdown     1.14    2019-07-12 [1] CRAN (R 3.6.1)                
#>  rprojroot     1.3-2   2018-01-03 [1] CRAN (R 3.6.0)                
#>  sessioninfo   1.1.1   2018-11-05 [1] CRAN (R 3.6.0)                
#>  stringi       1.4.3   2019-03-12 [1] CRAN (R 3.6.0)                
#>  stringr       1.4.0   2019-02-10 [1] CRAN (R 3.6.0)                
#>  testthat      2.1.1   2019-04-23 [1] CRAN (R 3.6.0)                
#>  usethis       1.5.1   2019-07-04 [1] CRAN (R 3.6.0)                
#>  withr         2.1.2   2018-03-15 [1] CRAN (R 3.6.0)                
#>  xfun          0.8     2019-06-25 [1] CRAN (R 3.6.0)                
#>  yaml          2.2.0   2018-07-25 [1] CRAN (R 3.6.0)                
#> 
#> [1] /home/mirai/R/x86_64-pc-linux-gnu-library/3.6
#> [2] /usr/local/lib/R/site-library
#> [3] /usr/lib/R/site-library
#> [4] /usr/lib/R/library

This occurs when modules are created explicitly via Module(), both inline (see above) and in packages. The latter case can be seen e.g. using Rcpp.package.skeleton() and replacing loadModule("yada", TRUE) with yada <- Module("yada") and running new(yada$World)$greet() after installing and loading the package.
This not an issue for the common case of using loadModule() in packages, where typically import(Rcpp) is in the NAMESPACE, otherwise we would observe the same behavior.

The effectiveness of using Rcpp:: can be tested by re-running the example above after intalling Rcpp from the branch

remotes::install_github("riccardoporreca/Rcpp", "fix-module-initialize")

The object can now be created even prior to Rcpp being attached.

…e modules.

* Otherwise the Rcpp functions are unknown when objects are initialized, unless Rcpp is attached.
* This is relevant for classes inside of modules created via Module(), both inline and in packages, but is not an issue when loadModule() is used for packages.
@eddelbuettel

This comment has been minimized.

Copy link
Member

eddelbuettel commented Jul 21, 2019

That looks rather useful. I'll try to look into it later today.

Copy link
Contributor

kevinushey left a comment

LGTM!

@eddelbuettel eddelbuettel merged commit 1bad53b into RcppCore:master Jul 21, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@riccardoporreca riccardoporreca deleted the riccardoporreca:fix-module-initialize branch Jul 21, 2019
eddelbuettel added a commit that referenced this pull request Jul 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.