Write Barrier: was: [Rd] function-like macros undefined

[Luke Tierney]

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:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu