[Rd] Transferring ownership of R-managed buffer
hpages at fredhutch.org
Wed Mar 29 20:12:46 CEST 2017
On 03/29/2017 11:04 AM, Hervé Pagès wrote:
> Hi Tim,
> On 03/29/2017 08:24 AM, Tim Keitt wrote:
>> I have a use case where I would like to create an SEXP around an existing
>> buffer that is managed by R, thus avoiding a copy operation.
> What to you mean exactly by "an existing buffer managed by R"?
>> If I have
>> something like:
>> void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n)));
>> ... additional maniupulation ...
>> SEXP x = somefunc(SXPTYPE, n, p); // ????
>> Is there a "placement" constructor available?
> What's a "placement" constructor?
>> (I have arranged for the
>> corresponding UNPROTECT.) I've looked at and experimented with
>> and allocVector3, but can't quite get it right. I know this is odd,
>> but it
>> makes sense for my use case.
> Not sure I follow what you are trying to do. Note that an SEXP is a
> pointer to a C struct called SEXPREC. I think that trying to point an
> SEXPREC struct to data pointed to by an existing SEXPREC struct is very
> likely to lead to a disaster.
> Note that if the existing buffer managed by R is an SEXP (e.g. b) and
> your code has access to this SEXP then you don't need to create another
> SEXP around its data. Since SEXPs are pointers doing
> SEXP x = b;
> is fine and doesn't generate any copy.
> And if your code only has access to a "naked" pointer to the buffer
> managed by R (e.g. to RAW(b) is the buffer is actually in an SEXP)
> then why would you need to wrap it inside an SEXP?
>> Thanks for any pointers.
>> [[alternative HTML version deleted]]
>> R-devel at r-project.org mailing list
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages at fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
More information about the R-devel