Add a RCPP_NO_RTTI define?

[eddelbuettel]

The recent RCPP_NO_MODULES define was clever.

We can build on top of that and also allow -fno-rtti with very minimal changes (and an implied RCPP_NO_MODULES). This is probably worth it. Any reason not to?

[eddelbuettel]

FWIW I put this in this branch and am running reverse depends now. Should do no harm as it is an opt-in feature nobody uses right now...

[kevinushey]

Sounds like a good idea to me as well.

[coatless]

This feels like we're slowly moving in the direction of splitting Rcpp into subpackages. I think this was proposed ~5 years back.

Does anyone have any knowledge on whether the base R packages are finally migrating to a higher C++ spec than 98?

[eddelbuettel]

This feels like we're slowly moving in the direction of splitting Rcpp into subpackages.

Not at all.

It is simply a very C++-ish "do not pay for something you do not use". I am rather fond how performant our compilation at $WORK is where the build is heavily customized and at the speed of C rather than C++. Think build of a C package (no time) rather than a complex template-heavy C++ package. Optionally turning off Modules moves that way. Optionally turning off RTTI goes a tiny bit further. Certain parts we need to keep (exceptions, template meta-programming, etc pp) but this was a low-hanging fruit.

In short, I think you speculated way far beyond what was reasonable, and got it wrong. It happens.

Does anyone have any knowledge on whether the base R packages

Base R contains no C++.

AFAIK r-devel defaults to C++11 now in the sense that you need to make a use for C++98 explicit. See the svn logs or rss feed of the changes. Not that it matters to us.

[kevinushey]

I might've felt differently before, but now I would much rather have Rcpp remain a single package that can be configured in different ways as required by the user.

As a package author, maintaining compatibility between a variety of sub-packages (and teaching users how to use them properly) is not worth the overhead.

I much prefer the "turn features on and off" approach rather than the "divide features into separate packages" approach.

[rstub]

For what its worth, specifying C++98 for a package is deprecated in 3.6.1-patched and was deleted in devel.

[eddelbuettel]

Thanks for the correction. There were some back-and-forth changes over a few days and I got lost too. In any event, it still has nothing to do with us, or the new branch.

[eddelbuettel]

@kevinushey and I are exactly on the same page.

[coatless]

To reiterate, I'm a huge fan of a single package and faster compile times. Just trying to figure out what the overarching plan is. There isn't a roadmap anywhere and we live in the "here be dragons" area.

[kevinushey]

There isn't really a roadmap because (at least, as far as I know) there aren't any big plans for over-arching changes right now.

Most of the work is around ensuring Rcpp continues to work as new versions of R, OSes and compilers are released. We should also try to take advantage of new features of these systems when possible and appropriate.

This does saddle Rcpp with a fair amount of requirements for backwards compatibility, but IMHO this is necessary as many clients of Rcpp move very slowly as well. For example, I suspect there are still a substantial number of Rcpp users out there stuck with gcc 4.9.x, or even older.

Likely, the most important thing we could do for Rcpp right now is figure out a way to respect (or take advantage of) ALTREP with newer releases of R, but my gut says that will be very challenging.

[eddelbuettel]

Reverse-depends passsed fine, cf RcppCore/rcpp-logs@62cadd1, so will PR this now.