Luke, 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 macros/functions. Thanks, Vadim > -----Original Message----- > From: Luke Tierney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 16, 2005 11:08 AM > To: Vadim Ogranovich > Cc: r-devel@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[0]); > > > > 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 > modification? > > 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 > > > -- > 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: [EMAIL PROTECTED] > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > ______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel