Hello,
Thanks for your interest in Rcpp.
Le 2013-06-14 07:07, Martin Jakt a écrit :
Dear Rcpp developers,
I'm rather new to Rcpp but am very excited by it's abilities;
especially with
the lower degree of effort required to combine R and C++. Thanks!
However, I'm still left a bit mystified by how the source is compiled
and
packages built. I have tried to read the guidelines for extending R,
but it is
rather long and it seems to assume knowledge of many things I don't
really
understand.
My situation is this. I've written some C++ code for reading bigWig
files (a
binary genomic data file type) and used Rcpp to provide an R
interface to
this. I can build the package using:
R CMD check / build / INSTALL
and that works. However, I would prefer to be able to compile and
link the C++
part of this using just make and a suitable Makefile. This almost
works, but
the linker complains about missing references (from libRcpp). This is
not very
surprising as I'd expect that these should be present in libR.so. And
I can't
find libR.so anywhere on the system I'm using. (I don't think it is
present,
and I don't have root access, so..).
Why do you want that. R CMD essentially takes care all of the details,
cooks a Makefile, runs it ... transparently. It never needs to be a
concern.
You can gain some control by using the Makevars, etc ...
Which implies that R CMD is somehow able to link to libR without
libR.so?
Is that possible, and if so, how is that achieved?
I suspect the answer is quite simple, but it's not one that I've been
able to
find by googling.
I also have one other question regarding documentation. Is there a
reference
for the set of C++ classes and their interfaces that are defined by
libRcpp
somewhere? I did try to work something out by looking at the Rcpp
header
files, but that's not that straightforward.
I have a plan for a documentation website. but it is not ready.
Coming close is Dirk's doxygen digested documentation:
http://dirk.eddelbuettel.com/code/rcpp/html/index.html
This might help you, it might not. It is a matter of taste. For
example, I don't like it so much.
It also doesn't tell me very much about the implementation details.
So far I'm
mostly using information from examples here and there, and making
guesses as
to behaviour.
The basic idea is that when using R types, we use their own memory,
e.g. for a numeric vector (aka NumericVector in Rcpp) we use its double*
to manipulate the data.
Then, the best information you'll get about implementation details is
to follow the source code.
Not really an ideal situation. For example, looking at the
GenericVector class, I was surprised to find push_front suggesting
that it
doesn't quite mimic the STL vector class, which I believe guarantees
that the
memory is allocated in a contiguous block (possible to combine with
push_front
and push_back, but with some difficulty).
Those are somehow cosmetic additions. The usual suggestion is not to
use push_front and push_back on Rcpp types.
We use R's memory, and in R, resizing a vector means moving the data.
So if you push_back 3 times, you're moving the data 3 times.
Using R own memory is the best ever decision we made in Rcpp. You can
always use your own data structures to accumulate data, perhaps using
stl types and then convert back to R types, which is something we make
easy to do.
(It looks like 'the book', may have something like this, and I'm
planning to
buy a copy over the weekend, but..).
in any case I'd like to say thanks for the tools; I'm looking forward
to
having a better understanding of them (perhaps even using R in C++,
it seems
somehow so unholy..).
cheers,
Martin
_______________________________________________
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
