Thanks. Hopefully someone will pick it up or at least create an issue by proxy 
for you. 

Romain

Le 29 juil. 2014 à 12:17, Christian Authmann 
<authm...@mathematik.uni-marburg.de> a écrit :

> I've removed the bool cast from last week's git, reinstalled the package, ran 
> the test suite with --allTests, recompiled my own codes, everything seems to 
> work.
> 
> If the bool cast is missing, the code should just fall back to the templated 
> operator T(), with T=bool. Unless RCPP_DEBUG_LEVEL is enabled, those are 
> identical.
> 
> 
> RUNIT TEST PROTOCOL -- Tue Jul 29 13:20:29 2014
> ***********************************************
> Number of test functions: 439
> Number of errors: 0
> Number of failures: 0
> 
> 
> Sorry, due to a restrictive firewall on my dev computer, I cannot access 
> github from it. A mail will have to suffice for now.
> 
> 
> Ciao,
> Christian
> 
> On 29.07.2014 10:44, Romain Francois wrote:
>> This is likely to be a bug in Rcpp, don't go bother clang about it:)
>> Perhaps you can try to remove the bool cast and run the test suite. If 
>> everything works, then it either means that there are no tests for the 
>> particular case or that the overload is useless.
>> 
>> You probably have to consider what happens with :
>> 
>> list["a"] = false ;
>> bool a = list["a"] ;
>> 
>> i.e. does it work when the overload is removed, etc ...
>> 
>> Also, it will be more useful if the example was not using RInside, as this 
>> has nothing to do with RInside really. You can easily demonstrate the 
>> problem with a cppFunction or a sourceCpp without having to go through 
>> RInside.
>> 
>> I'd recommend to go here for bug submission:
>> https://github.com/RcppCore/Rcpp/issues
>> 
>> Romain
>> 
>> Le 29 juil. 2014 à 10:36, Christian Authmann 
>> <authm...@mathematik.uni-marburg.de> a écrit :
>> 
>>> Hi,
>>> 
>>> the following testcase exposes a difference in gcc and clang
>>> 
>>> -------------------- snip --------------------
>>> #include <Rcpp.h>
>>> #include <RInside.h>
>>> 
>>> int main(int argc, char *argv[]) {
>>>     // We need some kind of R environment to create a List.
>>>     RInside R;
>>> 
>>>     Rcpp::List list;
>>>     list["a"] = 42;
>>> 
>>>     int a_auto = list["a"];
>>>     int a_cast = Rcpp::as<int>(list["a"]);
>>> 
>>>     std::cout << "list[\"a\"]                = " << a_auto << std::endl;
>>>     std::cout << "Rcpp::as<int>(list[\"a\"]) = " << a_cast << std::endl;
>>> }
>>> -------------------- snip --------------------
>>> 
>>> Results:
>>> 
>>> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
>>> list["a"]                = 42
>>> Rcpp::as<int>(list["a"]) = 42
>>> 
>>> Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
>>> list["a"]                = 1
>>> Rcpp::as<int>(list["a"]) = 42
>>> 
>>> 
>>> list["a"] returns a Rcpp::internal::generic_name_proxy<19>, which has the 
>>> following typecasting operators: (rcpp/vector/proxy.h)
>>> 
>>> -------------------- snip --------------------
>>> template <typename T>
>>> operator T() const {
>>>     #if RCPP_DEBUG_LEVEL > 0
>>>     SEXP res = get() ;
>>>     RCPP_DEBUG_1( "generic_name_proxy::get() = <%p> ", res ) ;
>>>     return ::Rcpp::as<T>( res ) ;
>>>     #else
>>>     return ::Rcpp::as<T>( get() ) ;
>>>     #endif
>>> }
>>> 
>>> operator bool() const{
>>>    return ::Rcpp::as<bool>(get());
>>> }
>>> -------------------- snip --------------------
>>> 
>>> A few sprinkled printf's reveal that clang will call the bool typecast, 
>>> while gcc calls the template as intended.
>>> 
>>> 
>>> Now that I know, I can easily work around it by using Rcpp::as where needed 
>>> (and I'm posting here so maybe others can find the information), but maybe 
>>> it should be fixed. ;)
>>> 
>>> 
>>> I don't know all the intricacies of the C++ standard. Is this a bug in 
>>> clang? Or is clang free to use any conversion operator it likes, and Rcpp 
>>> is at fault for relying on implementation details of gcc?
>>> 
>>> If the former, I'll create a reduced testcase and file a bug with clang.
>>> 
>>> If the latter, I noticed that removing the bool typecast altogether will 
>>> cause clang to correctly return 42. Unless there is a good reason for its 
>>> existence (say, to suppress logging for bool casts), we could just remove 
>>> it.
>>> Grep'ping all the includes suggest that this is the only class with 
>>> redundant typecast operators.
>>> 
>>> 
>>> Ciao,
>>> Christian
> 
> -- 
> Christian Authmann
> Philipps-Universität Marburg
> Fachbereich Mathematik und Informatik
> AG Datenbanksysteme
> Hans-Meerwein-Straße
> D-35032 Marburg
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

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

Reply via email to