[Rcpp-devel] Shared library error after update
Simon Zehnder
szehnder at uni-bonn.de
Tue Mar 4 11:05:01 CET 2014
This is interesting! Will the fix be part of the next release of Rcpp? For me myself the difference between const and non-const is in my project negligible as the code is not for direct use by other users - my unit tests detect any unintentional modification of objects - so I keep up to now the stable release of Rcpp and wait for the next stable one.
I am always open to learn more, so could you give me a short intuition what the idea of the Proxies is (the class members I do understand, but why is it called proxy - seems to give a hint - was the name simply chosen because the Proxy classes just manage data owned by R?) ?
Best
Simon
On 03 Mar 2014, at 20:41, Kevin Ushey <kevinushey at gmail.com> wrote:
> The bug is simply that the constructor is left declared, but
> undefined, for const_SlotProxy objects. In SlotProxy.h, we have:
>
> class const_SlotProxy : public GenericProxy<const_SlotProxy> {
> public:
> const_SlotProxy( const CLASS& v, const std::string& name) ;
> const_SlotProxy& operator=(const const_SlotProxy& rhs) ;
>
> template <typename T> operator T() const {
> return as<T>( get() );
> }
> inline operator SEXP() const {
> return get() ;
> }
>
> private:
> const CLASS& parent;
> SEXP slot_name ;
>
> SEXP get() const {
> return R_do_slot( parent, slot_name ) ;
> }
> } ;
>
> Note that the const_SlotProxy constructor is declared, but never
> defined. I think this was missed in the proxy class cleanup, where a
> lot of proxy 'meat' was inlined for compatibility with Solaris.
> Fortunately it's trivial to fix and I'll push something to the GitHub
> repo in a second.
>
> Cheers,
> Kevin
>
> On Mon, Mar 3, 2014 at 11:21 AM, Kevin Ushey <kevinushey at gmail.com> wrote:
>> Hi Simon,
>>
>> I can replicate this, and also fix this, if I change 'const Rcpp::S4&
>> classS4' to 'Rcpp::S4 classS4'. (That is, assuming a simple example
>> where I try to compile that class and construct an object using
>> sourceCpp).
>>
>> Since Rcpp classes are just proxy objects, you don't have to worry too
>> much about passing Rcpp objects by value, since you are essentially
>> just copying pointers.
>>
>> As for what the actual regression is -- that will take some more investigation.
>>
>> Try changing that around and let me know if things work.
>>
>> Cheers,
>> Kevin
>>
>> On Mon, Mar 3, 2014 at 10:59 AM, Simon Zehnder <szehnder at uni-bonn.de> wrote:
>>> Hi Kevin,
>>>
>>> the github repo is a good idea, though I have some dependencies on other C++ libraries that have to be installed first and that makes it unfavourable.
>>>
>>> However, I figured out where the source of the error seems to be: It is a header file of a C++ class that can be constructed from an Rcpp::S4 object. It looks like this:
>>>
>>> #ifndef FINMIXDATA_H
>>> #define FINMIXDATA_H
>>>
>>> #include <RcppArmadillo.h>
>>> #include <string>
>>>
>>> class FinmixData {
>>> public:
>>> arma::mat y;
>>> arma::ivec S;
>>> arma::vec expos;
>>> arma::vec T;
>>>
>>> std::string dataType;
>>> unsigned int N;
>>> unsigned int r;
>>>
>>> /* constructor */
>>> FinmixData (const Rcpp::S4& classS4) :
>>> y(Rcpp::as<arma::mat>((SEXP) classS4.slot("y"))),
>>> S(Rcpp::as<arma::ivec>((SEXP) classS4.slot("S"))),
>>> expos(Rcpp::as<arma::vec>((SEXP) classS4.slot("exp"))),
>>> T(Rcpp::as<arma::vec>((SEXP) classS4.slot("T"))),
>>> dataType(Rcpp::as<std::string>((SEXP) classS4.slot("type"))),
>>> N(Rcpp::as<unsigned int>((SEXP) classS4.slot("N"))),
>>> r(Rcpp::as<unsigned int>((SEXP) classS4.slot("r"))) {}
>>> ~FinmixData () {}
>>> };
>>> #endif
>>>
>>> This worked before the update. It seems to me that I have to change the initialisation list .... I work on it. Any suggestions are welcome!
>>>
>>> Best
>>>
>>> Simon
>>>
>>>
>>> On 03 Mar 2014, at 17:53, Kevin Ushey <kevinushey at gmail.com> wrote:
>>>
>>>> Do you have a GitHub repository or some other means of sharing your
>>>> package, so we can try testing it?
>>>>
>>>> On Mon, Mar 3, 2014 at 6:12 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>>>>>
>>>>> On 3 March 2014 at 14:38, Simon Zehnder wrote:
>>>>> | Though I couldn't detect NEWS relevant for my package. I have rebuilt my package several times now and the error remains. I remember that there was once some news about Rcpp now being header only (also the Rcpp.package.skeleton function does not include a Makevars file in the src folder). Does that mean I delete the line
>>>>> |
>>>>> | PKG_LIBS = '$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"'
>>>>> |
>>>>> | from my Makevars file?
>>>>>
>>>>> Yes you may.
>>>>>
>>>>> | Is it obligatory?
>>>>>
>>>>> No.
>>>>>
>>>>> If it were mandatory to remove it we would have said so. It is now a null-op
>>>>>
>>>>> edd at max:~$ Rscript -e 'Rcpp:::LdFlags()'
>>>>> edd at max:~$
>>>>>
>>>>> under the current version of Rcpp, and works as before under previous version
>>>>> ensuring continuity.
>>>>>
>>>>> Please construct a minimally reproducible example. Based on your two emails
>>>>> there is no further help I can give you.
>>>>>
>>>>> Dirk
>>>>>
>>>>> --
>>>>> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>>>>> _______________________________________________
>>>>> Rcpp-devel mailing list
>>>>> Rcpp-devel at lists.r-forge.r-project.org
>>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>>
More information about the Rcpp-devel
mailing list