Skip to content

Cleanup __cplusplus checks based on C++11 availability #1370

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

Closed
Enchufa2 opened this issue Mar 24, 2025 · 6 comments · Fixed by #1371
Closed

Cleanup __cplusplus checks based on C++11 availability #1370

Enchufa2 opened this issue Mar 24, 2025 · 6 comments · Fixed by #1371

Comments

@Enchufa2
Copy link
Member

  • Remove paths that rely on older standards.
  • Include >= C++11 paths unconditionally.
  • Assess TODO in inst/include/Rcpp/sugar/functions/sapply.h:42
  • Then, RCPP_HAS_LONG_LONG_TYPES is defined unconditionally, remove checks.
@Enchufa2
Copy link
Member Author

Enchufa2 commented Mar 24, 2025

What to do with

#if __cplusplus >= 201103L
#if __cplusplus < 201703L
// deprecated by C++17, removed by C++2020, see https://en.cppreference.com/w/cpp/types/result_of
typedef typename ::std::result_of<Function(typename SugarExpression::stored_type)>::type type;
#else
// since C++17, see https://en.cppreference.com/w/cpp/types/result_of
typedef typename ::std::invoke_result<Function, typename SugarExpression::stored_type>::type type;
#endif
#else
// TODO this else branch can likely go
typedef typename ::Rcpp::traits::result_of<Function>::type type;
#endif
};

remains. We could remove the second branch as part of #1371, but I think that it would probably be better to remove the first branch, because I don't see how this is needed just here, and then a future improvement could be to reimplement ::Rcpp::traits::result_of using std stuff. It seems it is needed for lambdas, see #213. Then mapply and other functions won't work with lambdas either. So probably a separate issue dedicated to reimplementing result_of is indeed required.

@eddelbuettel
Copy link
Member

I think this #else is harmless and opted to keep it. If we decide to remove it I think we can/should also look into removing it definition -- ie ::Rcpp::traits::result_of<Function>::type.

@Enchufa2
Copy link
Member Author

I pushed a branch feature/result_of_function that rewrites result_of to generalize the fix proposed for sapply, so that also lapply, mapply and outer can work with lambdas. What do you think?

@eddelbuettel
Copy link
Member

That sounds like a good way forward.

@Enchufa2
Copy link
Member Author

Ok, then I'll rebase it when the current PR is merged, add more tests with lambdas, etc., and open a new PR for this.

@eddelbuettel
Copy link
Member

That sounds even better!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants