GeezerVison is showing github.com — C++11 as minimum supported standard · Issue #1365 · RcppCore/Rcpp
C++11 as minimum supported standard #1365Closed 3 / 33 of 3 issues completedClosed 3 / 33 of 3 issues completed DescriptionMeta-issue for discussion and to keep track of all the individual changes required to achieve this goal.
It may be helpful to define three classes of tasks and an ordering as DE sees it
- First order: establish C++11 as the baseline allowing variadic templates (and the 'can use C++11' define) to reduce to unconditional code which, as a major side effect and first order goal, leads to removal of all the pre-C++11 autogenerated code. Other cleanups below inst/include and in src/ happen basically as a side effect
- Second order, by a wide margin: cleanup below inst/ and removal of old helpers or illustrations which does not really affect anyone
- Third order, and possibly tied with or marginally ahead of the previous point: cleanup of R helper functins
Tasks
- Clean up
inst/include/Rcpp/platform/compiler.h. Ancient tests and defines that are not required anymore.
"Spring cleaning" of some ancient pre-processor directives #1363
Header cleanup with C++11 as a baseline #1364
- Review
HAS_VARIADIC_TEMPLATES checks and remove carefully, also cleaning up inst/include/Rcpp/generated stuff. (DE: I expect this to be one single careful PR)
Remove use of HAS_VARIADIC_TEMPLATES #1366
Use variadic templates unconditionally #1367
- Review
RCPP_USING_CXX11 checks and remove carefully. RInside uses this macro (see this search). Then, the definition could be removed. (DE: Thanks for the heads-up. I can take this.)
Remove RCPP_USING_CXX11 which is now implicit #1369
- Find remaining
if __cplusplus < 201103L and assess removal
Cleanup __cplusplus checks based on C++11 availability #1370
Cleanup __cplusplus checks #1371
- Review
RCPP_USING_UNORDERED_* checks and remove carefully. Review RCPP_UNORDERED_* types and just replace with the appropriate std::unordered_* type.
Remove macros for unordered maps/sets #1372
- Remove branch in
inst/include/Rcpp/sugar/functions/sapply.h:41 (see TODO there). (DE: Unsure about this one, lesser priority for me. To be determined...). (IU: Maybe the other way around: maybe we should just remove the first branch, the one that uses the std library. Then ::Rcpp::traits::result_of could (or could not) be reimplemented based on the std library.)
Enable lambdas in all sugar functions #1373
- Reach out packages jiebaR, fwsim,
diveRsity (removed from CRAN), which use RCPP_UNORDERED_MAP and RCPP_UNORDERED_SET (see this search) in order to replace those uses too. We can deprecate these definitions and remove them in a future release.
- Maybe implement more variadic templates if any missing, then clean up remaining
inst/include/Rcpp/generated stuff.
- Same for generated stuff under
inst/include/Rcpp/module.
- Same for generated stuff under
inst/include/Rcpp/sugar/block.
- Same for generated stuff under
inst/include/Rcpp/sugar/functions/mapply.
- Clean up
R/RcppLdpath.R. Functions that have been deprecated for ages. Some internal functions could just be dropped (also the inst/discovery script). The exported ones require some revdep checking. (DE: Sure but low priority as it has not bitten anyone. We could also chase packages still doing 'Depends: Rcpp' but ... to what payoff?)
- Clean up plugins in
R/Attributes.R. Particularly, cpp98, cpp0x, probably cpp11 too. (DE: Unsure. There will be old code snippets hanging around that have this. Just as with old LdFlags() calls we could just make them null-ops)
- Update vignettes accordingly.
@eddelbuettel Feel free to add/drop/edit/reorder above. Reacted by Dirk Eddelbuettel ActivityEnchufa2 commented on Mar 19, 2025 eddelbuettel commented on Mar 19, 2025 Yes trickier issue. "Eventually" we will make the same subsitution but we probably need to have a 'deprecated' period first where we warn. This is still a user-facing API. coatless commented on Mar 24, 2025 I'm thrilled to see the new baseline move to C++11 tis like watching The Flintstones discover electricity. 😉
Let me know if I can help with anything! Looks like it's split with DE + IU and Kevin reviewing. Major props. eddelbuettel commented on Mar 24, 2025 We're not there yet, but we are moving from wheels that are almost quadratic with their five sides to those with six. Almost a smooth ride now.
Kidding aside, many/most client packages have compilerd under C++11 or C++14 or C++17 (and some even C++20) for years. But the baseline is so safely aheard of C++98 that we can simply do the cleanup now. Fairly easily. eddelbuettel commented on Jul 2, 2025 With Rcpp 1.1.0 at CRAN this can now be closed. Reacted by James J Balamuta Reacted by James J Balamuta and Iñaki Ucar coatless commented on Jul 2, 2025 Bees knees. 🎉
Superb job folks! Reacted by Dirk Eddelbuettel and Iñaki Ucar
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|