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

Add a RCPP_NO_RTTI define? #997

Closed
eddelbuettel opened this issue Oct 11, 2019 · 11 comments
Closed

Add a RCPP_NO_RTTI define? #997

eddelbuettel opened this issue Oct 11, 2019 · 11 comments

Comments

@eddelbuettel
Copy link
Member

@eddelbuettel eddelbuettel commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Member Author

@eddelbuettel eddelbuettel commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@kevinushey kevinushey commented Oct 11, 2019

Sounds like a good idea to me as well.

@coatless

This comment has been minimized.

Copy link
Contributor

@coatless coatless commented Oct 11, 2019

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 comment has been minimized.

Copy link
Member Author

@eddelbuettel eddelbuettel commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@kevinushey kevinushey commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@rstub rstub commented Oct 11, 2019

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

@eddelbuettel

This comment has been minimized.

Copy link
Member Author

@eddelbuettel eddelbuettel commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Member Author

@eddelbuettel eddelbuettel commented Oct 11, 2019

@kevinushey and I are exactly on the same page.

@coatless

This comment has been minimized.

Copy link
Contributor

@coatless coatless commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@kevinushey kevinushey commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Member Author

@eddelbuettel eddelbuettel commented Oct 12, 2019

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

eddelbuettel added a commit that referenced this issue Oct 13, 2019
support -fno-rtti via define (closes #997)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.