On Jun 8, 2011, at 12:08 PM, oliver wrote:
> On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
>> On Tue, 7 Jun 2011, Duncan Murdoch wrote:
>>
>>> On 07/06/2011 9:08 AM, oliver wrote:
>>>> Hello,
>>>>
>>>> following an advice here from the list I looked into sources of other
>>>> packages (xts) and found the TYPEOF() macro/function, which really is
>>>> helpful.
>>
>> It is documented, of course, but actually better alternatives are
>> described in 'Writing R Extensions'.
>>
>> We would urge you to study the R sources rather than copy bad habits
>> from randomly chosen package sources.
> [...]
>
> Hmhh, it was not randomly chosen, it was, what I got as a hint here on the
> list.
>
It was not provided to you to look at how it checks arguments. For basic usage
it's better to look at the R code. The coding styles vary a lot in packages
(and so does the quality of packages) - some of them are really bad, but you
have to remember that most people write packages in their free time and are not
programmers...
>
>>
>>>> I iused the follwong code snippet:
>>>>
>>>>
>>>> switch( TYPEOF( filename_sexp ) )
>>>> {
>>>> case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
>>>> break;
>>>>
>>>> default: error("filename argument must be a string");
>>>> break;
>>>> }
>>>>
>>>>
>>>> Here, filename is of type char*
>>>> and one function opens a file with that name.
>>>> So it is purely intended to just grab out the char* from the
>>>> String-Expression.
>>>>
>>>> Am I doing something wrong here, or is it ok, but I have somehow
>>>> to say the extracting macros/functions, that it is really intended
>>>> to throw away information and that a warning is not necessary?
>>>
>>> The result of calling CHAR should be a "const char *". You are
>>> not allowed to touch the string it points to.
>>
>> Note too that isString() exists for this purpose,
> [...]
>
> OK, I also sometimes used that (maybe I threw it out or used it in other
> modules).
>
>
>
>> and there is no
>> check in that code that LENGTH(filename_sexp) > 0 (or == 1). In the
>> R sources you will often see things like
>>
>> if(!isString(sfile) || LENGTH(sfile) < 1)
>> error("invalid '%s' argument", "description");
> [...]
>
> If it's a vector, I can just pic the first element.
Yes, but only if it's not a vector of length zero - hence the necessary check.
> Or does LENGTH(sfile) give the length of the string itself
> (like strlen(3))?
>
No.
> If the latter, then my file-opeing operation would faile with an error.
> Of course I check if my fopen() gibves back NULL.
>
>
>
>>
>> Then, reading on,
>>
>> file = translateChar(STRING_ELT(sfile, 0));
>
> translateChar is explained on page 120 of the extension writing do.
>
> I'm not in this point of the documentation.
>
> And I often need to look around, when I want to find a function,
> as they are documented/explained somewhere during the flow of the text.
>
> Something like a API description that is brief would help.
>
> For example something like in the manuals of the OCaml language:
>
> http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html
>
>
> That's very brief.
>
> Chapter 6 of the "Writing R Extensions" is rather in this style
> and gives a good overview.
> Something like that for the macros would be helpful.
>
>
>>
>> for you cannot (in general) assume that the character vector passed
>> is in the native encoding.
>
> I try to do some coercions (e.g. as.integer())
> when I need integer in the C-code and then
> in the C-part rigidly check on integer.
>
It's usually more efficient to use coerceVector() on the C side since that
guarantees no copy is made for matching types (this matters for passing data,
not so much for passing arguments). You can do either - check on R side or
check on C side, usually you don't need both (but you certainly can).
Cheers,
Simon
> About the char-encodings I have not thought much.
>
>
> Ciao,
> Oliver
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
