Hi Hadley, Thank you for your prompt reply! I understand your point, and am not sure how to proceed without it.
*Motivation*: I'm currently working on my dendextend package (link to github<https://github.com/talgalili/dendextend>), and one of the biggest bottlenecks in working with dendrogram objects is the need to use recursion for various small tasks (using the dendrapply function). *Goal*: to be able to make specific dendrapply_Rcpp functions to make some operations faster. If you think there is a better way, or that you still think I should not use it in this way (and generally, how to fix my the code from my previous post) - please let me know. With regards, Tal ----------------Contact Details:------------------------------------------------------- Contact me: tal.gal...@gmail.com | Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) | www.r-statistics.com (English) ---------------------------------------------------------------------------------------------- On Fri, Jul 26, 2013 at 6:44 PM, Hadley Wickham <h.wick...@gmail.com> wrote: > > // note: The FUN will change the object x itself > > // hence - it must be clear to use an object we wish to > change > > (it will NOT be copied!) > > Why do you want to do that? It's a generally a bad idea to modify R > objects in place. > > Here's a simple example showing why C level modification of R object > is particularly dangerous: > > library(inline) > foo <- cfunction(c(x = "SEXP"), '{ > INTEGER(x)[0] = 0; > return R_NilValue; > }') > > x <- 1:10 > y <- x > foo(x) > > # First value is modified as expected > x > > # But y is also modified! > y > > Hadley > > -- > Chief Scientist, RStudio > http://had.co.nz/ >
_______________________________________________ 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
