[Rcpp-devel] How get colnames and rownames in Rcpp method?

[Dominick Samperi]

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 <djsamperi at gmail.com>wrote:

> On Wed, Jul 28, 2010 at 10:11 PM, Dirk Eddelbuettel <edd at debian.org>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100731/a3feea60/attachment-0001.htm>