Le 31/07/10 22:04, Dominick Samperi a écrit :
On Wed, Jul 28, 2010 at 10:11 PM, Dirk Eddelbuettel <[email protected]
<mailto:[email protected]>> wrote:

    ... you missed entry 2.7 in the FAQ which I quote here with the
    mark-up; see
    the pdf version on my site or the nearest CRAN mirror:

       \subsection{Can I use \pkg{Rcpp} with Visual Studio}

       Not a chance.

       And that is not because we are meanies but because \proglang{R}
    and Visual
       Studio simply do not get along. As \pkg{Rcpp} is all about extending
       \proglang{R} with \proglang{C++} interfaces, we are bound by the
    available
       toolchain.  And \proglang{R} simply does not compile with Visual
       Studio. Go complain to its vendor if you are still upset.

    So in short: no VC++.


It is possible to build Rcpp using VC++, but it is not easy, and getting the
DLL's to work properly is difficult. Furthermore, VC++ is not supported by
CRAN so packages that depend on VC++ will have to be built using the
MinGW tool chain before they can be released to CRAN. It should also
be noted that VC++ Express does not officially support 64bit builds (though
this is possible with some work, at least with the 2008 version).

That said, it can be helpful to test using different compilers because the
GNU compilers tend to be lenient (though the latest versions are advertised
to follow the standards more closely).

For example, here is an issue that was picked up by the VC++ compiler but
not by other compilers. On Line 171 of XPtr.h there is a template
function definition
where one of the parameters is given a default value, but two trailing
parameters
are not.

This was definitely an omission, thanks for picking it up.

I've set "prot" and "tag" to R_NilValue in the svn version, as this was the intention.

The C++ standard says if one parameter is given a default
value, then all
parameters after this one must also be given default values. I don't
know of any
rule that says this does not apply to template functions, maybe there is
one,
in which case this is a problem with VC++.

The easy fix is to set the default value R_NilValue for the last two
parameters.
This results in errors due to ambiguous calls that end up calling the wrong
constructor. This occurs on Line 240 of Module.cpp, and on Line 200 of
RcppCommon.cpp. A simple work-around is to replace
clxp(cl) with clxp(cl,true) in the first case, and p(v) with p(v,true) in
the second. I have not checked the logic to see if this might cause other
problems.

Besides this issue, the changes needed (in Rcpp 0.8.5)
to compile using VC++ are as follows:

1. Date.cpp: replace include of <unistd.h> with:

//#include <unistd.h>        // for read and close on Solaris
#ifdef _MSC_VER
// POSIX open,read,write deprecated as of VC++ 2005.
// Use ISO conformant _open,_read,_write instead.
#include <io.h>
#define open _open
#define write _write
#define close _close
#define read _read
#define snprintf _snprintf
#else
#include <unistd.h> // for Solaris, e.g.
#endif

2. RcppDatetime.cpp: redefine snprintf as follows for MSVC:

#ifdef _MSC_VER
#define snprintf _snprintf
#endif

3. Insert missing header file stdint.h into Rcpp/inst/include (attached).

Dominick

I don't have bandwidth right now to test any of this. As you say VC++ is not supported by CRAN anyway.

Have you tried building client packages with VC++, as this is more likely to start getting problematic at that stage. Due to templates lazyness, most of the code of Rcpp is not actually compiled in Rcpp, but if/when needed by the client code.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/aAyra4 : highlight 0.2-2
|- http://bit.ly/94EBKx : inline 0.3.6
`- http://bit.ly/aryfrk : useR! 2010

_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to