[R] Problem with .C

[Jan van der Laan]

Quoting Uwe Ligges <ligges at statistik.tu-dortmund.de>:


>>
>> I don't agree that it's overkill -- you get to sidestep the whole `R
>> CMD SHLIB ...` and `dyn.load` dance this way while you experiment with
>> C(++) code 'live" using the inline package.
>
>
> You need two additional packages now where you have to rely on the fact
> those are available. Moreover, you have to get used to that syntax, and
> part of it seems to be C++ now? At least I do not know why the above
> should work at all, while I know the simple C function does.

OK, I agree that switching to Rcpp/C++ might be a bit of overkill in
this example although in a lot of other example I find the Rcpp syntax
much more readable than the c-code when dealing with .Call .

The example could also have been writen in C using inline removing the
need of Rcpp and looking more like the original example:

library(inline)

test <- cfunction(signature(b = "numeric", l = "integer") , '
		 for(int i=0; i < *l; i++) b[i] += i;
      ', convention=".C")

I find that the advantage of using inline (especially in case of
simple functions like this) is that
1. I no long need to compile and load the shared library manually,
which can sometimes be frustrating when windows locks the dll.
2. Inline performs typechecking and casts variables to the right type.  
You can now type test(1:10,10) without needing as.numeric or  
as.integer. Reducing the amount of r code and the probabiliry of  
screwing things up by passing the wrong type.


Jan


>
> Uwe
>
>
>> It's really handy.
>>
>>> Just make the original source
>>>
>>>
>>> void test(double *b, int *l)
>>> {
>>>     int i;
>>>     for(i=0; i<  *l ; i++) b[i] += i;
>>> }
>>>
>>>
>>> which you would have know after reading the Wriiting R Extensions manual.
>>
>> I agree that this step is unavoidable no matter which avenue (Rcpp or
>> otherwise) one decides to take.
>>
>> -steve
>>