To clarify, after closer inspection it appears that g++ follows the default parameter rule mentioned below. The discrepancy between MinGW/g++ and MSVC seems to be related to how they interpret the explicit qualifier. The patch where the last two parameters are assigned R_NilValue needs to be ifdef-ed for MSVC since it causes problems for g++.
On Sat, Jul 31, 2010 at 4:04 PM, Dominick Samperi <[email protected]>wrote: > On Wed, Jul 28, 2010 at 10:11 PM, Dirk Eddelbuettel <[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. 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 > >
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
