From duncan at wald.ucdavis.edu  Fri Oct  9 17:55:52 2009
From: duncan at wald.ucdavis.edu (Duncan Temple Lang)
Date: Fri, 9 Oct 2009 08:55:52 -0700
Subject: [Rd] R_CallMethodDef: 'type' and 'style' fields?
In-Reply-To: <25821291.post@talk.nabble.com>
References: <25803313.post@talk.nabble.com> <4ACEAE33.8020903@wald.ucdavis.edu>
	<25821291.post@talk.nabble.com>
Message-ID: <20091009155552.GA12220@wald.ucdavis.edu>

Steve Jaffe wrote:
> 
> 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()? 

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).

 
> 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*). 

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.

> 
> Thanks for your help.
> 
> 
> Duncan Temple Lang wrote:
> > 
> > 
> > 
> > Steve Jaffe wrote:
> >> 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).
> > 
> > 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;
> > 
> 
> -- 
> View this message in context: http://www.nabble.com/R_CallMethodDef%3A-%27type%27-and-%27style%27-fields--tp25803313p25821291.html
> Sent from the R devel mailing list archive at Nabble.com.
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
"There are men who can think no deeper than a fact" - Voltaire


Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
4210 Mathematical Sciences Bldg.  fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20091009/60507654/attachment.bin>


[Rd] R_CallMethodDef: 'type' and 'style' fields?
Duncan Temple Lang