-
-
Notifications
You must be signed in to change notification settings - Fork 211
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
Add a RCPP_NO_RTTI define? #997
Comments
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... |
Sounds like a good idea to me as well. |
This feels like we're slowly moving in the direction of splitting Does anyone have any knowledge on whether the base R packages are finally migrating to a higher C++ spec than 98? |
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.
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. |
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. |
For what its worth, specifying C++98 for a package is deprecated in 3.6.1-patched and was deleted in devel. |
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. |
@kevinushey and I are exactly on the same page. |
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. |
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. |
Reverse-depends passsed fine, cf RcppCore/rcpp-logs@62cadd1, so will PR this now. |
support -fno-rtti via define (closes #997)
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 impliedRCPP_NO_MODULES
). This is probably worth it. Any reason not to?The text was updated successfully, but these errors were encountered: