To clarify, after closer inspection it appears that g++ follows the default<br>parameter rule mentioned below. The discrepancy between MinGW/g++<br>and MSVC seems to be related to how they interpret the explicit<br>qualifier. The patch where the last two parameters are assigned R_NilValue<br>
needs to be ifdef-ed for MSVC since it causes problems for g++.<br><br><div class="gmail_quote">On Sat, Jul 31, 2010 at 4:04 PM, Dominick Samperi <span dir="ltr"><<a href="mailto:djsamperi@gmail.com">djsamperi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Wed, Jul 28, 2010 at 10:11 PM, Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
... you missed entry 2.7 in the FAQ which I quote here with the mark-up; see<br>
the pdf version on my site or the nearest CRAN mirror:<br>
<br>
\subsection{Can I use \pkg{Rcpp} with Visual Studio}<br>
<br>
Not a chance.<br>
<br>
And that is not because we are meanies but because \proglang{R} and Visual<br>
Studio simply do not get along. As \pkg{Rcpp} is all about extending<br>
\proglang{R} with \proglang{C++} interfaces, we are bound by the available<br>
toolchain. And \proglang{R} simply does not compile with Visual<br>
Studio. Go complain to its vendor if you are still upset.<br>
<br>
So in short: no VC++.<br></blockquote></div><div><br>It is possible to build Rcpp using VC++, but it is not easy, and getting the<br>DLL's to work properly is difficult. Furthermore, VC++ is not supported by<br>CRAN so packages that depend on VC++ will have to be built using the<br>
MinGW tool chain before they can be released to CRAN. It should also<br>be noted that VC++ Express does not officially support 64bit builds (though<br>this is possible with some work, at least with the 2008 version).<br>
<br>
That said, it can be helpful to test using different compilers because the<br>GNU compilers tend to be lenient (though the latest versions are advertised<br>to follow the standards more closely).<br><br>For example, here is an issue that was picked up by the VC++ compiler but<br>
not by other compilers. On Line 171 of XPtr.h there is a template function definition<br>where one of the parameters is given a default value, but two trailing parameters<br>are not. The C++ standard says if one parameter is given a default value, then all<br>
parameters after this one must also be given default values. I don't know of any<br>rule that says this does not apply to template functions, maybe there is one,<br>in which case this is a problem with VC++.<br><br>The easy fix is to set the default value R_NilValue for the last two parameters.<br>
This results in errors due to ambiguous calls that end up calling the wrong<br>constructor. This occurs on Line 240 of Module.cpp, and on Line 200 of<br>RcppCommon.cpp. A simple work-around is to replace<br>clxp(cl) with clxp(cl,true) in the first case, and p(v) with p(v,true) in <br>
the second. I have not checked the logic to see if this might cause other<br>problems.<br><br>Besides this issue, the changes needed (in Rcpp 0.8.5)<br>to compile using VC++ are as follows:<br><br>1. Date.cpp: replace include of <unistd.h> with:<br>
<br>//#include <unistd.h> // for read and close on Solaris<br>#ifdef _MSC_VER<br>// POSIX open,read,write deprecated as of VC++ 2005.<br>// Use ISO conformant _open,_read,_write instead.<br>#include <io.h><br>
#define open _open<br>#define write _write<br>#define close _close<br>#define read _read<br>#define snprintf _snprintf<br>#else<br>#include <unistd.h> // for Solaris, e.g.<br>#endif<br><br>2. RcppDatetime.cpp: redefine snprintf as follows for MSVC:<br>
<br>#ifdef _MSC_VER<br>#define snprintf _snprintf<br>#endif<br><br>3. Insert missing header file stdint.h into Rcpp/inst/include (attached).<br><br>Dominick<br><br></div></div>
</blockquote></div><br>