Re: [Rcpp-devel] Rcpp and ExternalPtr
You are looking for XPtr.
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/XPtr.h
It is a template class whose first parameter is the class of the raw pointer
you are dealing with, let’s call it T.
You can create an external pointer using something like :
XPtrT xp( new T(...) ) ;
This registers the default finalizer (which calls delete) to be executed when R
garbage collects the R object. So you can send xp back to the R side.
Then you can grab it back on the C++ side, e.g. as a parameter to a function:
// [[Rcpp::export]]
void foo( XPtrT xp ){
// here you can treat xp as a raw pointer, e.g. do xp-foo( ... ) ;
}
You can also set the finalizer yourself with a bit more work if you wanted to
do something different than the default, e.g.
void my_finalizer( T* obj ){
// whatever you need to do
}
typedef XPtrT, PreserveStorage, my_finalizer Bar ;
If you deal with a pointer that you don’t own, i.e. you don’t handle its
finalization for some reason, you can set the second parameter of the XPtr
constructor from
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/XPtr.h#L84
XPtrT xp( raw_ptr, false ) ;
Romain
Le 5 déc. 2014 à 08:45, Jeroen Ooms jeroen.o...@stat.ucla.edu a écrit :
Does Rcpp provide some elegant way to let the R user manage persistent
c++ objects that have no R type (e.g. internal handles or sessions of
some sort)?
In C, I would use R_MakeExternalPtr to create a ptr SEXP that the user
can pass from one R function to another. This also makes it easy to
add a finalizer with R_RegisterCFinalizerEx so that the garbage
collector will automatically clean up the session/handle whenever user
deletes the R object.
Most Rcpp examples I have seen use function arguments with standard
data types that are automatically mapped to R types. Does Rcpp have
any special mechanics for managing external objects (pointers) from R
which do not map to a SEXP type? Or do I have to fall back on
Rinternals for this?
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp and ExternalPtr
I think the XPtr class is what you are looking for: http://www.r-bloggers.com/external-pointers-with-rcpp/ On Fri, Dec 5, 2014 at 2:45 AM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote: Does Rcpp provide some elegant way to let the R user manage persistent c++ objects that have no R type (e.g. internal handles or sessions of some sort)? In C, I would use R_MakeExternalPtr to create a ptr SEXP that the user can pass from one R function to another. This also makes it easy to add a finalizer with R_RegisterCFinalizerEx so that the garbage collector will automatically clean up the session/handle whenever user deletes the R object. Most Rcpp examples I have seen use function arguments with standard data types that are automatically mapped to R types. Does Rcpp have any special mechanics for managing external objects (pointers) from R which do not map to a SEXP type? Or do I have to fall back on Rinternals for this? ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Returning an arma vec
Le 04/12/2014 17:57, Romain François a écrit :
Something like this:
template typename T
inline wrap( const arma::subview_coldouble x ){
return wrap( arma::MatT( x ) ) ;
}
Interesting. If I do
inline SEXP wrap( const arma::vec x ) {
return wrap(Rcpp::NumericVector( x.begin(), x.end()));
}
then wrap(v) returns a vector to R, not a matrix n x 1
(v is a vec here) but wrap(v+1) still returns a matrix.
Is there a more universal way to say that any expression
resulting in vec should return a vector?
Serguei.
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Returning an arma vec
I had something simpler in mind. I'll send a pull request when I've
finished testing (This package has many dependencies!)
Martyn
On Thu, 2014-12-04 at 17:57 +0100, Romain François wrote:
Something like this:
template typename T
inline wrap( const arma::subview_coldouble x ){
return wrap( arma::MatT( x ) ) ;
}
(untested)
This would still wrap it as a matrix though as this is what subview_col
conceptually gives.
The only downside is that this is somewhat inefficient as it would have to
allocate memory for a arma::mat first and then copy that across to an
Rcpp::Matrix …
Romain
Le 3 déc. 2014 à 22:41, Martyn Plummer plumm...@iarc.fr a écrit :
You just need to put a new template specialization of wrap for the
subview_col class in RcppArmadilloWrap.h based on the existing one for the
subview class. And throw in one for subview_row for good measure.
Martyn
From: rcpp-devel-boun...@lists.r-forge.r-project.org
[rcpp-devel-boun...@lists.r-forge.r-project.org] on behalf of Dirk
Eddelbuettel [e...@debian.org]
Sent: 03 December 2014 19:25
To: Romain Francois
Cc: rcpp-devel@lists.r-forge.r-project.org
Subject: Re: [Rcpp-devel] Returning an arma vec
On 3 December 2014 at 18:30, Romain Francois wrote:
| 2. If we replace the lines marked // x with
|
|return wrap(x.subvec(1, 2));
|
| then it fails with a compiler error.
|
| error: cannot convert 'const arma::subview_coldouble' to 'SEXP' in
| initialization
|
| This should be easy/trivial to fix for someone with the right skills.
Sure. Maybe Gabor wants to give it a try.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
---
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify
the sender and delete it. Since its integrity cannot be guaranteed,
its content cannot involve the sender's responsibility. Any misuse,
any disclosure or publication of its content, either whole or partial,
is prohibited, exception made of formally approved use
---
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
