Exporting classes using `Rcpp::interfaces(cpp)` that are shared among multiple cpp files through header file about rcpp HOT 13 CLOSED

You don't have to use Rcpp::interfaces(cpp) if your header file is in inst/include.
Other package developers can include the header file if it's located in inst/include.

As far as I know, Rcpp::interfaces(cpp) is used to export class or function written in cpp file that is located in src.

from rcpp.

Correct. Anything placed in inst/include/ will be available from your installed package via a standard mechanism described (briefly) in Writing R Extensions, Section . Other R packages can access it via LinkingTo:.

from rcpp.

For another complete example of what I understand you want, consider my package qlcal:

• header inst/include/qlcal_types.h defines a class CalendarContainer
• by following the PACKAGENAME_types.h convention the header file is included in src/RcppExports.h
• the generated header inst/include/qlcal.h includes it too so it can be used by the exported functions
• the exported functions have an autogenerated interface via // [[Rcpp::interfaces(r, cpp)]]
• however the header file 'magic' we use here is automated behavior in Rcpp Attributes
• the key here may be use of header file named PACKAGENAME_types.h where one plugs in the package name

from rcpp.

@zhuxr11 I hope this answers your question. Feel free to reopen if things remain unclear; the mailing list is also a good place for 'how do I ...' style discussions.

from rcpp.

If you want to see a complete example consider my recent-ish package RcppInt64. It exports some helper functions via inst/include. There is also an entire example package using it included in inst/client/int64header. Note that it does not have or need a RcppExports.cpp.

Good to know that we can #include a header file from inst/include folder. Many thanks.

from rcpp.

For another complete example of what I understand you want, consider my package qlcal:

• header inst/include/qlcal_types.h defines a class CalendarContainer
• by following the PACKAGENAME_types.h convention the header file is included in src/RcppExports.h
• the generated header inst/include/qlcal.h includes it too so it can be used by the exported functions
• the exported functions have an autogenerated interface via // [[Rcpp::interfaces(r, cpp)]]
• however the header file 'magic' we use here is automated behavior in Rcpp Attributes
• the key here may be use of header file named PACKAGENAME_types.h where one plugs in the package name

This could be a more elegant solution to classes that need to be exported (and maybe also some functions that should go in the same way). Very clear explanation.

from rcpp.

If it is feasible to manually add a copy of the header file, it would not be easy to maintain the package, since I need to manually update this copy of header file if the header file is changed. This is at high risk of forgetting to do so.

from rcpp.

Not sure I follow what you do / do not do. Last time I used this facility was in package RcppSpdlog I added it two source files (here and here) and that works just fine. See the generated files in inst/include/ -- a bit of 'buyer beware' because I complicated that a little further later with package spdl in order to have the 'interface' from R and C++.

In short, the line

// [[Rcpp::interfaces(r, cpp)]]

should just work but I am with you that this woefully underdocumented. I too go hunting each time I use this.

from rcpp.

If what you are aiming for is the other way around -- i.e. you have a header file and what it used / exported -- then maybe all you need is the inst/include/NAMEOFPACKAGE_types.h file to export your header for use in RcppExports.cpp etc.

from rcpp.

If you want to see a complete example consider my recent-ish package RcppInt64. It exports some helper functions via inst/include. There is also an entire example package using it included in inst/client/int64header. Note that it does not have or need a RcppExports.cpp.

from rcpp.

Sorry to comment / add a question on a closed issue, but I think there are related interesting questions that have been left unanswered, and this isse is starting to looks like a good FAQ entry...

If I understand well, Rcpp::interfaces(cpp) allows using exported functions from another package. Now imagine than in my (fictious) package snark, I defined a class (named snark) in inst/include/snark.h, and that I have a file src/snark2int.cpp which defines a function int snark2vec(snark x); I think I can't export this simply, unless I let Rcpp know how to build a snark from a SEXP, which is not a simple task, I assume? is it possible to define Rcpp::traits::input_parameter::type somewhere, and how? Obvious solutions would be to turn this function into a template, or using an XPtr to a snark instead of a snark. Is there a simpler, direct solution to this situation?

Second question, what if my class is not header-only? For example, one of the constructors of snarks could be, for good reasons, outside of snark.h, in src/snark.cpp, or could use extern C functions defined somewhere in src/. I can't export snark::snark() to R, so this is a generalization of the previous question, with, this time, no obvious solution as far as I can see.

Does anyone have pointers for a couple of packages that deal with this kind of situation?

Thank you for your time!

from rcpp.

It's all been done before, and documentation exists, if scattered. That said

i) I think you have the direction wrong. Rcpp::interfaces(cpp,r) declares functions to be exported for use by the same or package other packages. This can be from R (usually the same package, but others too if you export via NAMESPACE) and Cpp (often other packages, via direct C level calls). My RcppSpdlog package does that, other packages then use its C level functions. Note that this does not automagically write new SEXP converters for you. How to convert data is a different (if related in the context) question.

ii) Having a function body outside a header is no detriment. RcppSpdlog is again an example (if a complex / confusing one).

It may be best to start with a new and simple issue rather than piling into an old and closed issue. And one question per issue allows for more focus. Also consider the mailing list.

from rcpp.

Via grep in some of the repos I have checked, packages qs and extradist also make use of this as does my package qlcal.

from rcpp.