<div dir="ltr">My point regarding the clang parser is that one really shouldn't have to write any R or Rcpp wrappers at all.<div><br></div><div>If one directly parses the c++ class then both the R6/RefClass/List (or whatever implementation one chooses to use) and the C wrappers (which we will still need as we can't expose the c++ class directly to R; we still need .Call) can be generated directly from parsing the class w/ clang.</div><div><br></div><div>Rcpp modules uses chaining to do this, but one still has to write this code:</div><div><div><br></div><div> Rcpp::class_<Redis>("Redis") </div><div> .constructor("default constructor") </div><div> .constructor<std::string>("constructor with host port") </div><div> .constructor<std::string, int>("constructor with host and port") </div><div> .constructor<std::string, int, std::string>("constructor with host and port and auth") </div><div> .constructor<std::string, int, std::string, int>("constructor with host and port, auth, and timeout") </div><div> .method("exec", &Redis::exec, "execute given redis command and arguments")<br></div><div>...</div><div><br></div><div><br></div><div>richfitz/RcppR6 uses some yaml to generate the bindings, which one has to provide and keep it synchronized w/ the class.<br></div><div><div><br></div><div>circle:</div><div> constructor:</div><div> args: [radius: double]</div><div> methods:</div><div> area:</div><div> return_type: double</div><div> active:</div><div> circumference:</div><div> name_cpp: circumference</div><div> name_cpp_set: set_circumference</div><div> access: member</div><div> type: double</div><div> radius: {access: field, type: double}</div></div><div><br></div><div><br></div><div>we should be able to extract all that from the class itself w/ clang. That's the point.</div><div><div><br></div><div><div>-Whit<br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 30, 2016 at 5:49 AM, Christian Gunning <span dir="ltr"><<a href="mailto:xian@unm.edu" target="_blank">xian@unm.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Whit,<br><br></div>I see that this could be useful in similar situations where Rcpp modules excels (generating R bindings to existing C++ classes). Language preference aside, it's less clear to me what advantage this approach (or Rcpp modules) offers average users over RefClasses + Rcpp functions, where the RefClass holds state, and the Rcpp functions operate on the state using by-reference semantics.<span class="HOEnZb"><font color="#888888"><br><br>-Christian<br></font></span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Nov 29, 2016 at 5:33 AM, Whit Armstrong <span dir="ltr"><<a href="mailto:armstrong.whit@gmail.com" target="_blank">armstrong.whit@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span class="">
<div dir="ltr">Have a look at this project:
<div><a href="https://github.com/richfitz/RcppR6" target="_blank">https://github.com/richfitz/Rc<wbr>ppR6</a><br>
</div>
<div><br>
</div>
</div>
</span><div class="gmail_extra"><br>
<div class="gmail_quote"><div><div class="h5"><div><div class="m_593310690471735300h5">On Mon, Nov 28, 2016 at 11:40 PM, Christian Gunning <span dir="ltr">
<<a href="mailto:xian@unm.edu" target="_blank">xian@unm.edu</a>></span> wrote:<br>
</div></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div><div class="m_593310690471735300h5">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Dear List,<br>
<br>
</div>
The following is a general request for advice / comment on modern Rcpp development best-practices for package & class development. I looked over the Rcpp gallery, and didn't see anything obvious that answers my questions - perhaps this discussion could serve
as a prototype for a new post?<br>
</div>
<br>
</div>
<div>## Background<br>
<br>
</div>
I've used Rcpp modules for several projects where in-place modification was required for performance reasons. I like the interface - it encourages clean code, and yields a nice mix of performance and encapsulation.<br>
<br>
In the past, the lack of serialization has been a minor annoyance. Honestly, it's not something I need, but I dislike having invalid objects in the work-space after a quit/restart. I've spent a little time thinking about work-arounds, which essentially boil
down to moving back and forth from an R list object.<br>
<br>
</div>
<div>Looking towards the future, I also looked at the recent Rcpp dev history. It looks like modules has had some maintenance issues - for example, the last edits there (i..e, PR 454) were reverted due to Windows toolchain issues (i.e.,
<a href="https://github.com/RcppCore/Rcpp/issues/463" target="_blank">https://github.com/RcppCore/Rc<wbr>pp/issues/463</a>). From my outside perspective, it appears that the modules code is A) hard, and B) not a current dev priority.<br>
</div>
<div><br>
</div>
<div>## A possible alternative: RefClass<br>
</div>
<div><br>
I'm able to achieve similar behavior (in-place modification using named methods, relatively tidy code) using a combination of R RefClasses and Rcpp attributes. This solves the issue of serialization, and yields reasonably clean code. This has the added benefit
of allowing easy mixing of R and C++ code in class methods. <br>
<br>
>From a user perspective, RefClass methods are a nice place for Rcpp functions that modify args in-place, since RefClass implies side-effects. And, in terms of style, if all C++ method functions return void, and have const-correct arglists, then the C++ function
signatures provide something of a interface spec.<br>
<br>
</div>
<div>Minimal example: <br>
<a href="https://gist.github.com/helmingstay/17d5d9f241c4170a29d1681db0111065" target="_blank">https://gist.github.com/helmin<wbr>gstay/17d5d9f241c4170a29d1681d<wbr>b0111065</a><br>
<br>
<div><br>
## Summary of observations:<br>
</div>
<div><br>
* RefClass + attributes achieves similar outcomes to Rcpp modules, with somewhat better support (serialization, documentation, future?).<br>
</div>
<br>
* Unique to Rcpp modules is the ability to auto-magically generate RefClass-like R bindings for existing C++ class-based code.<br>
<br>
* For "mere mortals", Rcpp modules now look less attractive for routine use, given available alternatives (i.e. for anything but binding auto-generation)<br>
<br>
<br>
</div>
<div>## Questions: <br>
<br>
</div>
<div>A) Any obvious problems with the above observations?<br>
</div>
<div><br>
B) Are there any *gotchas* with using Rcpp "modify-in-place" functions inside RefClass methods?<br>
</div>
<div><br>
C) Is anyone else doing this? Any suggested improvements on the above?<br>
<br>
</div>
<div>Thanks much,<br>
</div>
<div>Christian Gunning<span class="m_593310690471735300m_-8455004219172470727HOEnZb"><font color="#888888"><br>
-- <br>
<div class="m_593310690471735300m_-8455004219172470727m_-2760036368781318549gmail_signature">A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!</div>
</font></span></div>
</div>
</div>
</div>
<br></div></div></div></div><span class="">
______________________________<wbr>_________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-pro<wbr>ject.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-projec<wbr>t.org/cgi-bin/mailman/listinfo<wbr>/rcpp-devel</a><br>
</span></blockquote>
</div>
<br>
</div>
</div>
</blockquote></div><br><br clear="all"><span class=""><br>-- <br><div class="m_593310690471735300gmail_signature" data-smartmail="gmail_signature">A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!</div>
</span></div>
</blockquote></div><br></div>