[Rprotobuf-yada] Compiling on RHEL 64 bit Linux

[Romain Francois]

On 12/26/2009 10:57 AM, Romain Francois wrote:
>
> Sorry I have not been around for this issue.
>
> For the external_pointer thing, it is just something I played with, but
> apparently I don't file my toys when I'm done with them. Thanks Dirk for
> cleaning my mess. More on this below.
>
> For the S4 thing, I think this is die to a recent change in R. Which
> version of R are you using ? I only plan to support current versions of
> R, so if the problem still appears with current R, I'll have a look,
> otherwise maybe not (maybe yes)
>
> I will enforce current version of R later.
>
> Romain

(I forgot the "more on this below" that was advertised above.

I now have a template x_ptr in package CPP to manage external pointers.

This allows for things like this :

SEXP foo( SEXP xp ){
	// create a smart external pointer
	x_ptr<Foo>(xp) p(xp) ;
	
	// now I can use p as a smart pointer to Foo
	p->foobar( ) ;

	return R_NilValue ;
}


I have not managed to do what I really wanted to do with it which was 
using implicit conversion so that I could declare the function like this:

SEXP foo( x_ptr<Foo> ) ;

but it does not work.




template <typename T>
class x_ptr {
	public:
   		explicit x_ptr(SEXP xp) ;
   		
   		T& operator*() const ;
   		T* operator->() const ;
   		SEXP getProtected() ;
   		SEXP getTag() ;
   		SEXP getExternalPointer() ;
   		
   	private:
   		x_ptr() ;
   		SEXP xp;
   		T* pointer;
};

template<typename T>
x_ptr<T>::x_ptr(SEXP xp) : xp(xp) {
	pointer = (T*)EXTPTR_PTR(xp) ;
}

template<typename T>
T& x_ptr<T>::operator*() const {
	return *pointer ;
}

template<typename T>
T* x_ptr<T>::operator->() const {
	return pointer ;
}

template<typename T>
SEXP x_ptr<T>::getProtected(){
	return EXTPTR_PROT(xp) ;
}

template<typename T>
SEXP x_ptr<T>::getTag(){
	return EXTPTR_TAG(xp) ;
}

template<typename T>
SEXP x_ptr<T>::getExternalPointer(){
	return xp ;
}



> On 12/24/2009 08:58 PM, Dirk Eddelbuettel wrote:
>>
>> On 24 December 2009 at 14:08, Saptarshi Guha wrote:
>> | Hello,
>> | I just checked out Rcpp(0.7.0.1)(from svn), built, installed and then
>> | checked our rprotobuf(revision 253).
>> | I still get
>> | ** preparing package for lazy loading
>> | Loading required package: Rcpp
>> | Error in rematchDefinition(definition, fdef, mnames, fnames, signature) :
>> |   methods can add arguments to the generic only if '...' is an
>> | argument to the generic
>> | Error: unable to load R code in package 'RProtoBuf'
>> |
>> | But loading Rcpp( library(Rcpp) ) in R works. Can I provide something else?
>>
>> Didn't one yout mails say R 2.8.* ?  I suspect that it is one of those S4
>> aspects.
>>
>> Dirk, who sticks to S3 most of the time
>>
>> | Regards
>> |
>> |
>> | On Thu, Dec 24, 2009 at 1:13 PM, Dirk Eddelbuettel<edd at debian.org>   wrote:
>> |>
>> |>   On 24 December 2009 at 12:54, Saptarshi Guha wrote:
>> |>   | Yes, it all compiled now(thanks), but ...
>> |>   |
>> |>   | ** preparing package for lazy loading
>> |>   | Loading required package: Rcpp
>> |>   | Error in rematchDefinition(definition, fdef, mnames, fnames, signature) :
>> |>   |   methods can add arguments to the generic only if '...' is an
>> |>   | argument to the generic
>> |>   | Error: unable to load R code in package 'RProtoBuf'
>> |>
>> |>   Works for me on amd64 with current Rcpp. I just committed the fix to the
>> |>   issue you found and cleaned three or four other 'g++ -Wall' issues -- then
>> |>   after 'cd pkg; ./cleanup; cd ..' a fresh R CMD INSTALL as all is well here:
>> |>
>> |>>   library(RProtoBuf)
>> |>   Loading required package: Rcpp
>> |>   R>
>> |>
>> |>   and e.g. 'demo(io)' runs fine.
>> |>
>> |>   Dirk
>> |>
>> |>   --
>> |>   Three out of two people have difficulties with fractions.
>> |>
>>
>
>


-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IlMh : CPP package: exposing C++ objects
|- http://tr.im/HlX9 : new package : bibtex
`- http://tr.im/Gq7i : ohloh