[Rd] silent extern error (PR#898)

bellis@hsph.harvard.edu bellis@hsph.harvard.edu
Sun, 8 Apr 2001 08:48:24 +0200 (MET DST)


On Sun, 8 Apr 2001, Prof Brian D Ripley wrote:

> On Sat, 7 Apr 2001 bellis@hsph.harvard.edu wrote:
> 
> > Full_Name: Byron Ellis
> > Version: 1.2.2
> > OS: all
> > Submission from: (NULL) (140.247.105.95)
> >
> >
> > R_ext/Arith.h
> >
> > #ifdef MAIN
> > #define extern
> > #endif
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > these two should be reversed. Its never a problem because builds aren't done
> > against C++ compilers, but its still an error (just a low priority one).
> 
> Sorry, but as __MAIN__ (not MAIN) is only defined in one C module internal
> to R, why is it an error?  It would be an error if there ever was an
> intention that module was to be in C++, but there is not.  The #ifdef
> __cplusplus constructs are only there to allow the header files to be used
> in C++ addons, and defining __MAIN__ is *not* part of the API.
> 
> In short, those two #ifdef's are mutually exclusive, so their order is
> immaterial.  How can one order be an error?

Okay, then it was a simple misunderstanding on my part in the event that
you will never attempt to compile R under a compiler in C++ mode and you
don't have to worry about it any more.


> 
> 
> > also, you could change that to
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> > #ifdef __MAIN__
> > #define extern
> > #elif _MSC_VER
> > #define extern __dllspec(dllimport)
> > #endif
> >
> > with the corresponding change to the #undef region. This would allow people to
> > develop for R using MSVC++ more easily.
> 
> However, *that* would be an error.  _MSC_VER may well be defined during the
> actual compilation of R, and __MAIN__ is only defined in the compilation of
> main.c.  So compilation would fail under VC++ (and other compilers which
> define _MSC_VER).
> 
> (It is also possible for _MSC_VER to be defined but not have a value, so is
> the test what you really meant?)

I personally can't think of a VC++ compiler I've used where _MSC_VER is
defined but __declspec(dllimport) is unavailable, except maybe VC++ 1.5
where its been such a long time I can't recall. (Of course, VC++ 1.5
doesn't even RUN under Win2K let alone compile anything :-)) If suppose
you could change it to something like #if _MSC_VER >= 1100 if there is
such a compiler and that would work as well.


> 
> If we intended to make compilation for other C compilers easier we would
> need to add lines like that to lots of the header files, and for more than
> one compiler system.  However, we don't particularly want to make the use
> of Arith.h under VC++ easier, as VC++ does not handle IEEE arithmetic
> correctly!   In short, using Arith.h in addons compiled with VC++ is
> likely to give incorrect results.

Welp, just the two (and putting it above the __cplusplus def) in
R_ext/Arith.h and Rinternals.h. If you also toss a __cplusplus statement
after the #include's in Rinternals.h it also works in C++ mode (which is
missing things like that nasty sizeof() bug). 

> 
> (We know from past experience that R can be compiled with VC++ (6.0sp3, to
> be precise) but then fails make check, giving incorrect results in the
> arithmetic tests and elsewhere.)

Yes, fortunately I'm not using the IEEE arith code--- I'm actually writing
non-numerical support libraries and GUI embedding code. I mostly just like
to do my development using VC++ (probably because I'm getting lazy, but
whatever). Out of curiosity has this been tested with SP4 or 7beta?

> 
> -- 
> Brian D. Ripley,                  ripley@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 272860 (secr)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
> 
> 


Byron Ellis (bellis@hsph.harvard.edu)




-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._