[Rd] .C() vs .Call() (was Re: R-devel and not R-help (was 'using "= matrix (...)" in .C calls')

[Prof Brian Ripley]

On Fri, 18 Jun 2004, Tony Plate wrote:

> At Friday 02:17 AM 6/18/2004, Martin Maechler wrote:
> 
> >[snip]  Even though we (R core) would like to promote the use
> >of .Call() as much as possible, for most R users, [snip]
> 
> Why does "R core" wish to promote the use of .Call() over .C()?
> 
> I see two advantages for .C():
> 
> (1) The interface is very straightforward and I don't need to go to the 
> trouble of using R macros and extractor functions in my C or C++ code in 
> order to get at the data -- the data is just passed in C vectors of 
> standard types, and I can return data the same way.  This means my C code 
> is simpler and consequently (on average) more maintainable and less prone 
> to bugs.  For example, consider the C functions 'convolve' (to be called by 
> .C()) and 'convolve2' (to be called by .Call()) that are in "Writing R 
> Extensions".  I am more confident that I can write correctly the R code for 
> type checking and coercion needed for the .C() call than I can write 
> correctly the corresponding C code (for example, because then I need to 
> think about things like stack imbalances in my calls to PROTECT/UNPROTECT).

That is a _very_ simple example.  In the original context (the main
function of rpart), I suspect the .Call equivalent would be much simpler,
and it would certainly be easier to maintain as the preallocation in the R
code is not needed.

> (2) .C() functions are easier to port between different implementations of 
> the S language.

Not necessarily true if the Rdefines macros are used.  In part true 
because the S4 internals are so sparsely documented, but there are some 
serious examples of code written for both systems.

> Am I missing advantages to using .Call() when .C() would suffice?  (i.e., 
> when the data that must be passed back and forth can be easily packed into 
> vectors.)

Many -

1) A lot less copying.

2) The ability to dimension the answer in the C code.

3) Access to other types, e.g. expressions, raw type and the ability to 
easily execute R code (call_R is a pain).

4) Access to the attributes of the vectors, for example the names.

5) The ability to handle missing values easily.

...

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595