Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

The next bi-monthly update in the 0.12.* series of Rcpp releases landed on CRAN early this morning. It was actually released on September 20, but I made a first cut (see #887 below) at a deprecation which CRAN and I decided to reverted for now, then CRAN was unusually busy and under an onslaught of false positives of a new checker, and finally we ran into a change in R-devel from the last two days. It is not easy as Rcpp is complex with over 1400 direct reverse dependencies so releases can take a moment. Hence, also releasing to the Rcpp drat repo as I did this time too may become the norm. In any event, and as usual, a big Thank You! to CRAN for all the work they do so well.

So once more, this release follows the 0.12.0 release from July 2016, the 0.12.1 release in September 2016, the 0.12.2 release in November 2016, the 0.12.3 release in January 2017, the 0.12.4 release in March 2016, the 0.12.5 release in May 2016, the 0.12.6 release in July 2016, the 0.12.7 release in September 2016, the 0.12.8 release in November 2016, the 0.12.9 release in January 2017, the 0.12.10.release in March 2017, the 0.12.11.release in May 2017, the 0.12.12 release in July 2017, the 0.12.13.release in late September 2017, the 0.12.14.release in November 2017, the 0.12.15.release in January 2018, the 0.12.16.release in March 2018, the 0.12.17 release in May 2018, and the 0.12.18 release in July 2018 making it the twenty-third release at the steady and predictable bi-montly release frequency (which started with the 0.11.* series).

Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 1452 packages on CRAN depend on Rcpp for making analytical code go faster and further, along with another 138 in the current BioConductor release 3.7.

A decent number of changes, contributed by a number of Rcpp core team members as well as Rcpp users, went into this. Full details are below.

#### Changes in Rcpp version 0.12.19 (2018-09-20)

• Changes in Rcpp API:

• The no_init() accessor for vectors and matrices is now wrapped in Shield<>() to not trigger rchk warnings (Kirill Mueller in #893 addressing #892).

• STRICT_R_HEADERS will be defined twelve months from now; until then we protect it via RCPP_NO_STRICT_HEADERS which can then be used to avoid the definition; downstream maintainers are encouraged to update their packages as needed (Dirk in #900 beginning to address #898).

• Changes in Rcpp Attributes:

• Added [[Rcpp::init]] attribute for registering C++ functions to run during package initialization (JJ in #903 addressing #902).
• Changes in Rcpp Modules:

• Improved exposeClass functionality along with added test (Martin Lysy in #886 fixing #879).
• Changes in Rcpp Documentation:

• Two typos were fixed in the Rcpp Sugar vignette (Patrick Miller in #895).

• Several vignettes now use the collapse argument to show output in the corresponding code block.

• Changes in Rcpp Deployment:

• The old LdFlags() build helper was marked as deprecated [but removed for release] (Dirk in #887).

• Dockerfiles for continuous integration, standard deployment and ‘plus sized’ deployment are provided along with builds (Dirk in #894).

• Travis CI now use the rcpp/ci container for tests (Dirk in #896).

This contains one new deprecation for using stricter R headers. I already emailed around sixty maintainers who need to either make (very small) changes, or set a new #define to skip this. Right now you can test by adding #define STRICT_R_HEADERS before including Rcpp.h, we want to make this the default come September 2019. See my email to Rcpp-devel for more.

A second deprecation may get started with the next release. A lot of packages still needlessly call Rcpp:::LdFlags() even though we have not needed linker options for five years now. I will try assess what the damage may be and hopefully activate the .Deprecated() function in a good year.

Thanks to CRANberries, you can also look at a diff to the previous release. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.