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

C++11 trailing return types not supported for exported functions #727

Closed
klmr opened this issue Jul 4, 2017 · 5 comments
Closed

C++11 trailing return types not supported for exported functions #727

klmr opened this issue Jul 4, 2017 · 5 comments

Comments

@klmr
Copy link

klmr commented Jul 4, 2017

When using C++11 trailing return types on a function marked with [[Rcpp::export]], compilartion fails. Trailing return types work for non-exported functions.

Here’s an MWE (rcpptest.cpp):

// [[Rcpp::plugins(cpp11)]]

#include <Rcpp.h>

auto impl() -> int { return 42; }

// [[Rcpp::export]]
auto test() -> int { return impl(); }
Rcpp::sourceCpp('rcpptest.cpp')
rcpptest.cpp:13:1: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
auto test();
^
1 error generated.
make: *** [rcpptest.o] Error 1
clang++ -std=c++11 -I/usr/local/Cellar/r/3.3.2/R.framework/Resources/include -DNDEBUG  -I/usr/local/opt/gettext/include -I/usr/local/opt/readline/include -I/usr/local/opt/openssl/include -I/usr/local/include  -I"/Users/konrad/.R/packages/Rcpp/include" -I"/Users/konrad/tmp"   -fPIC  -g -O2 -c rcpptest.cpp -o rcpptest.o
Error in Rcpp::sourceCpp("rcpptest.cpp") :
  Error 1 occurred building shared library.

By changing the definition of test (but not impl!) to use conventional return types, the code compiles:

// [[Rcpp::export]]
int test() { return impl(); }
@jjallaire
Copy link
Member

jjallaire commented Jul 4, 2017

Good find. We're unlikely to fix this though as we have an ad-hoc parser for C++ that was developed some years ago. Modifying it for this alternate way of expressing return types carries cost and risk that IMO aren't warranted.

One related undertaking we've considered is to allow parsing to optionally use libclang (when available). That's not on the short term roadmap but would also remedy this issue.

@klmr
Copy link
Author

klmr commented Jul 4, 2017

I suspected as much from the error message.

👍 for libclang support, in the long run.

@marimeireles
Copy link

Any plans for implementing this?
Thanks.

@eddelbuettel
Copy link
Member

No, I think that was addressed in the comments above from 2017 (indicating likely side effects to a core functionality) so I should probably just close this.

Or do you have any new insights to share?

@github-actions
Copy link

github-actions bot commented Aug 7, 2021

This issue is stale (365 days without activity) and will be closed in 31 days unless new activity is seen. Please feel free to re-open it is still a concern, possibly with additional data.

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

No branches or pull requests

4 participants