Write Barrier: was: [Rd] function-like macros undefined
vograno at evafunds.com
Wed Mar 16 20:32:23 CET 2005
My actual problem was with the RAW() macro, it is not available as a
function. I used INTEGER as an illustration because it was in the same
group of macros, I guess I shouldn't have.
Thank you for your other comments. I was confused, somehow I thought
that in 2.0.x ALL access, even to the atomic vectors, should be done via
> -----Original Message-----
> From: Luke Tierney [mailto:luke at stat.uiowa.edu]
> Sent: Wednesday, March 16, 2005 11:08 AM
> To: Vadim Ogranovich
> Cc: r-devel at stat.math.ethz.ch
> Subject: Re: Write Barrier: was: [Rd] function-like macros undefined
> Your original question was about macro-like functions.
> INTEGER is available to internal R code as a macro; it is
> also available as a function. Code in packages that uses
> standard hearders will see the function, which is declared as
> int *(INTEGER)(SEXP x);
> I have no idea why you wanted to check whether INTEGER is a
> macro or not. The value returned is a pointer to the raw int
> data which you can (ab)use like any other such pointer.
> On Wed, 16 Mar 2005, Vadim Ogranovich wrote:
> > Hi,
> > Thank you to Duncan Murdoch for pointing to
> > http://www.stat.uiowa.edu/~luke/R/barrier.html.
> > I have a couple of questions in this regard:
> > * suppose that inside a C function I have a SEXP vector x
> of integers
> > and I want to increment each element by one. I understand that
> > int * xIPtr = INTEGER(x);
> > int i;
> > for (i=0; i<LENGTH(x); ++i)
> > SET_VECTOR_ELT(x, i, xIPtr[i]+1);
> The declaration of SET_VECTOR_ELT is
> SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v);
> Your compiler had better complain about your third argument.
> > is the recommended way of doing it. However it seems that only the
> > very first call to SET_VECTOR_ELT, i.e. the one that corresponds to
> > i=0, is strictly necessary. For example, and this is my
> question, the
> > following should be perfectly safe:
> > SET_VECTOR_ELT(x, 0, xIPtr);
> > for (i=0; i<LENGTH(x); ++i)
> > ++xIPtr[i];
> > Admittedly this looks a bit odd and breaks if LENGTH(x) is
> zero, but
> > it illustrates the point.
> > * Now, if the above variation is safe, maybe there is a macro that
> > simply marks atomic SEXP-s, i.g. integers and doubles, for
> Vectors of non-SEXP objects are not a problem--that is why
> REAL, INTEGER, etc are available as functions to access the
> raw data pointers. Only vectors of SEXP's (i.e. generic and
> character vector
> objects) need to go through the write barrier.
> > * The "Write Barrier" document has a section "Changing the
> > Representation of String Vectors". Is this something which is in
> > works, or planned, for future versions? It would be great
> if it were,
> > this should give R considerable speed boost.
> This was considered at the time but is not on the table now.
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics and Fax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: luke at stat.uiowa.edu
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
More information about the R-devel