Skip to content

R_CallMethodDef: 'type' and 'style' fields?

5 messages · Steve Jaffe, Duncan Temple Lang

Original
Steve Jaffe
# 
In Writing R Extensions it is said that R_CallMethodDef has two optional
fields, 'type' and 'style' (where 'style' is said to distinguish
in/out/inout arguments). But it doesn't give the possible values for
'style'. Looking at the header Rdynload.h (version 2.9.2) it appears that
R_CallMethodDef  does not have these extra two fields. 

Were they removed at some point? If so, what is the best way to call a C
function without the overhead of copying the inputs?

Thanks
Duncan Temple Lang
#
Steve Jaffe wrote:
Can you point us to the particular section and line that says
this. I think it is for the R_CMethodDef structure, not the
R_CallMethodDef.


Indeed, in Rdynload.h

typedef enum {R_ARG_IN, R_ARG_OUT, R_ARG_IN_OUT, R_IRRELEVANT} R_NativeArgStyle;

/*

 These are very similar to those in  unix/dynload.c

 but we maintain them separately to give us more freedom to do

 some computations on the internal versions that are derived from

 these definitions.

*/
typedef struct {
    const char *name;
    DL_FUNC     fun;
    int         numArgs;

    R_NativePrimitiveArgType *types;
    R_NativeArgStyle         *styles;

} R_CMethodDef;
The enum above does.
The types is described in the help file for .C or .Call, i.e.
?.C
See above.
The .Call() interface does not copy the R objects that it passes to the
C routine which accepts SEXP type objects (and returns a SEXP object also).

 D.
Steve Jaffe
# 
Thanks. I did misread the documentation, which says on p 68:

Routines for use with the .C and .Fortran interfaces are described with
similar data structures [referring to R_CallMethodDef],
but which have two additional fields for describing the type and ?style? of
each argument

So it is R_CMethodDef which has the 'type' and 'style' fields. Just to
confirm, if I specify a 'style' of R_ARG_IN does this suppress the copying
when using .C()? 

Actually, having now re-thought what I'm trying to do, it seems simpler just
to use DUP=False in the .C call. In which case it would seem to be a good
idea for me to make the signature of my  C function declare the non-output
arguments to be const (eg  const int* rather than int*). 

Thanks for your help.
Duncan Temple Lang wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Temple Lang
    

    

      
      #
    

  


  

      
Steve Jaffe wrote:

            

      
      
      
    

        
Good, glad that the manual is not erroneous. Thanks for confirming that.

At present, a style of R_ARG_IN does not avoid duplicating the object.
That could easily be activated and that was the intent, coupled with
parameters being declared const. It is highly desirable to have that
explicitly checked by the compiler rather than just stated in the declarations.
And the idea is that all this meta information can be determined programmatically
by examining the C code (e.g. with the RGCCTranslationUnit package).

            

      
      
      
    

        
Yep. They are good things to declare when true.
Do be careful with DUP = FALSE, as the help page says.
Presumably there will be some parameters of your C function
that are not const so that you can modify them and return
results. (Unless of course the C routine is only of interest
for its side effects such as writing to a file.)

 D.

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Steve Jaffe
    

    

      
      #
    

  


  

      
Hmm, I should have read the .C documentation more carefully still. I can't
use DUP=FALSE when passing character vectors. In that case, since specifying
the style doesn't suppress copying I guess my only option is to use the more
complicated .Call API, which I naturally was hoping to avoid.

        
Duncan Temple Lang wrote: