[Rd] New package test results available

[Prof Brian Ripley]

On Sat, 7 Feb 2009, Thomas Petzoldt wrote:

> Prof Brian Ripley schrieb:
>> We've added a column at
>> 
>> http://cran.r-project.org/web/checks/check_summary.html
>> 
>> of test results using the Sun Studio compiler: it is intended that these 
>> will be updated weekly.
>> 
>> The Sun Studio compiler is that used on Solaris: these runs were on the 
>> Linux version.  All the other platforms are using gcc 4, so this provides 
>> an opportunity for checking for use of gcc-specific features and also 
>> standards conformance (the Sun compilers have a long-time reputation for 
>> close conformance to the language standards).
>> 
>> There are known problems where packages use C++ or JNI interfaces (e.g. 
>> rgdal and EBImage) as the libraries and JVM were compiled under gcc's 
>> conventions (even though a Sun JVMi is used).  About half the packages 
>> using rJava segfault, which seems to a JNI issue.
>> 
>> Some packages use gcc-specific compiler flags:
>>
>>   LogConcDEAD Matching amap geometry memisc taskPR
>> 
>> but the vast majority of the errors reported are C++ errors.  One class 
>> that may not be immediately obvious is the use of C headers in C++: you are 
>> supposed to write e.g.
>> 
>> #includd <cmath>
>> 
>> NOT
>> 
>> #include <math.h>
>> 
>> Symptoms of this can be seen for packages
>>
>>   BayesTree EMCC MCMCfglmm MarkedPointProcess Matching Matrix
>>   RQuantlib RandomFields Rcpp SoPhy compHclust dpmix igraph minet
>>   mixer modeest monomvm multic pcaPP rgenoud robfilter segclust
>>   simecol subselect
>
> The reason can also be including <R.h> (as done in simecol) that includes 
> <math.h>

As I said (R.h is a C header).

> Do I understand it correctly that this means that including <R.h> is 
> wrong in C++? I read "Writing R extensions" several times, but was 
> not aware that this was a mistake. If I replace <R.h> by <cmath> 
> then it works on my systems, but I want to be certain that there are 
> no other side effects.

Hmm, I think you missed

   Most @R{} header files can be included within C++ programs, and they
   should @strong{not} be included within an @code{extern "C"} block
   (as they include C++ system headers).  It may not be possible to include
   some @R{} headers as they in turn include C header files that may
   cause conflicts---if this happens, define @samp{NO_C_HEADERS} before
   including the @R{} headers, and include the appropriate headers
   yourself.

Allowing R heeaders to be used in C++ was an afterthought: had it been 
preplanned I expect R.h would have included far fewer C headers.  The 
issues have got worse as C++ has evolved (and diverged from C), and 
until recently g++ has been well behind (g++ 4.3.x was a large step 
forward towards C++ standards conformance).

Including unneeded headers often comes back to bite you (another area 
is where the contents are controlled by macros such as __GNU_SOURCE__ 
and so order matters).

We did at one time experiment with R.h using cmath not math.h if 
included into C++, but that too was not 100% portable.

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