[Rcpp-devel] Fwd: Re: Making objects in the C++ "side" persistent

Martin Jakt mjakt at z2.keio.jp
Thu Jun 19 09:51:52 CEST 2014

On Wednesday 18 Jun 2014 15:47:38 Martyn Plummer wrote:
> On Wed, 2014-06-18 at 09:09 +0900, Martin Jakt wrote:
> > On Tuesday 17 Jun 2014 19:34:59 Krzysztof Sakrejda wrote:
> > > On Tue, Jun 17, 2014 at 7:30 PM, Martin Jakt <mjakt at z2.keio.jp> wrote:
> > > >> if (identical(data_ptr, new('externalptr'))) return("No data
> > > >> available
> > > >> to retrieve.")
> > > > 
> > > > thanks. I think it would have taken me a long time to come up with
> > > > that
> > > > from the documentation. It seems curious there's no direct way.
> > > 
> > > Yes... so it comes with the caveat that I'm not sure if this is
> > > documented behavior
> > > and the R developers might decide to change it (?)  If this is somehow
> > > documented or if there is an Rcpp implementation which gets closer to
> > > documented behavior I would love to know.
> > 
> > that's a good point. Perhaps a question for the r-dev mailing group. I've
> > not registered for it, but seems like it might be a good idea.
> There is no R-level API for external pointers. You are expected to
> questions like "is it null?" on the C side.

thanks for the clarification. I can see the reasoning, as the C side should not 
do anything that can cause it to fall over, though it's a bit tricky when the 
code is generated for you by an external framework, and it does fall over.

(I did find that Rcpp::Modules tries to check for null pointer values in the R 
code using is.null(), which as far as I can see will always return FALSE).

In any case I'm now using Reference Classes to interface with the C++ code and 
that seems to be relatively easy to make safe. It still allows the user to 
crash the session by manually calling .Call() with an inappropriate external 
pointer. But that is perhaps acceptable (?).


> Martyn
> -----------------------------------------------------------------------
> 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
> -----------------------------------------------------------------------

Martin Jakt
Department of Systems Medicine
Mitsunada Sakaguchi Laboratory
Keio University School of Medicine

More information about the Rcpp-devel mailing list