Sean, the path form the console is not under your control and it depends heavily on the internal settings in R (is console enabled, is R interactive, is the output a tty or a file ...) - that's why you have to use Rprint/REprintf - that's the only path that is guaranteed to work. Anything else is settings-specific and not guaranteed to work (it may appear to work in limited settings, but will not work in others). Note that, for example, WriteConsole is only used if R is not fed via I/O pipes - that may be what baffled you in that case.
So AFAICS the only C++ solution (other than using Rprintf/REprintf directly) is to create streams to pipes whose ends will call Rprintf/REprintf with the content. Anything else is not general. You may want to ask Rcpp people (Dirk is CC'd anyway ;)) - I'd imagine they must have thought of it as it seems very natural to request in a C++ interface ... (but I don't use Rcpp so I don't know). Cheers, Simon On May 6, 2011, at 3:19 PM, Sean Robert McGuffee wrote: > Hi, > > Thanks for the comments so far. > > I've been going through the code extensively and seem to be having trouble > reproducing what R is doing, so this confuses me. For example, when I write > out the pointer values for ptr_R_WriteConsole type functions, I can't find a > function that matches what is actually being called. > > REprintf("Rstd_WriteConsole=%ld, ptr_R_WriteConsole=%ld, > R_WriteConsole=%ld\n", Rstd_WriteConsole, ptr_R_WriteConsole, > R_WriteConsole); > > It might be something like RTcl_WriteConsole too. However, I can't seem to > find the headers I would need to try to find it's pointer value. Anyway, > these are often hidden/protected/static which is an aspect of code that I > only understand in concept. The concept I understand about this type of > stuff is that if you provide a better way of doing things, then maybe you > hide some stuff that doesn't involve the better way. However, in this case, > the hidden stuff is just making it difficult for me to debug and get to > bottom of what is going on. Anyway, I get different results if I call on the > functions that simply use stdout when trying to reproduce Rprintf > functionality. I'm only doing that to try to get to the bottom of what R is > doing with stdout and stderr. I also am having a similar issue with trying > to understand what GNU GCC is doing with how it sync's cout and cerr with > stdout and stderr. Maybe R is intercepting some of these components. Anyway, > > I was hoping to get around the > "5.6 Interfacing C++ code > ======================== [...] > Using C++ iostreams, as in this example, is best avoided. There is > no guarantee that the output will appear in the R console, and indeed it > will not on the R for Windows console. Use R code or the C entry points > (*note Printing::) for all I/O if at all possible." > if at all possible. My reason is that I have 76386 lines of c++ code that > I'm trying to interface with R, and it literally might be faster for me to > update R rather than modify all of that code to suit R which seems to be > lacking a c++ ostream interface. > > Ideally, I'd write rout and rerr versions of cout and cerr for R to become > more compatible with c++. I have had some trouble figuring a lot of this > hidden stuff out. Strategies I have considered are the following: > 1) Write macros that conditionally replace cerr and cout with Rprintf > somehow throughout all of my c++ code that I'm trying to interface with R. > 2) Recreate the std::cerr and std::cout type of classes but maybe add some > extra functionality for callbacks to when i/o events take place to somehow > try to fix things. > 3) Make a scratch version of R source code that has no hidden aspects to try > to investigate what is going on a little better. > > Also, I should mention that I found an unanswered post from someone who had > a similar problem when trying to use cerr and cout when accessing functions > from dynamically linked libraries. I wonder, is it possible that R hasn't > completely connected to these libraries? I mean, it's doing some sort of > magic where it finds a pointer to a function, but maybe c++ has a lot going > on in the background related to these ostream types that could be getting > messed up. Maybe some aspects of the global environment might be different > somehow? I directly link to my libraries via a c++ compiler when I get the > identical functions to work from main in c++. > > One final thing I'm considering is that the R manual also mentions something > about garbage collection and some circumstances under which it's important > to explicitly request pointers to be maintained. Is it possible that R is > eating global pointers used by std::ostream ? > > All suggestions are valued and if anyone has recommendations on strategy, > please let me know. > > Thanks, > Sean > > > On 5/6/11 2:50 PM, "Davor Cubranic" <cubra...@stat.ubc.ca> wrote: > >> On 2011-05-06, at 11:41 AM, Dirk Eddelbuettel wrote: >> >>> | I’m trying to call some of my c++ code from R and seem to be having an >>> issue >>> | with streams, although that’s just one obvious sign of something different >>> | in performance between calling the same function from main in c++ vs. >>> | calling the same function from R. [...] >>> In a nutshell, R 'owns' your console. That is part of the Faustian bargain. >> >> But isn't he redirecting cout to a file, so the C++ output is not to the >> console? >> >> Davor > > > On 5/6/11 2:41 PM, "Dirk Eddelbuettel" <e...@debian.org> wrote: > >> >> On 6 May 2011 at 14:21, Sean Robert McGuffee wrote: >> | Hi, >> | >> | Sorry, I just tried posting this but I had it in the wrong format of text, >> | so this is a cleared format repost: >> | >> | I’m trying to call some of my c++ code from R and seem to be having an >> issue >> | with streams, although that’s just one obvious sign of something different >> | in performance between calling the same function from main in c++ vs. >> | calling the same function from R. I’m not getting any signs of errors from >> | R, but the behavior is different somehow and in a way that breaks my >> | algorithms. In both cases of launching a function from c++ or R, I redirect >> | cout to a file using a streambuf. In particular, I can see progress stop >> | when launching from R at a point when cout gets truncated when starting to >> | write out iterator values in a std::vector<string>. Then, I find no way to >> | write anything else to cout. When I write those values to Rprintf, they are >> | there and they are as expected. I’ve tried setting >> | ios_base::sync_with_stdio(false) in case R is messing with stdout and >> stderr >> | somehow, but that made no difference. I’m not quite sure how R uses those C >> | FILE* streams. Anyway, I am wondering if anyone has a hunch as to what >> might >> | be going on. At this point I don’t know if it might be an issue with R not >> | completely handling c++ from a library or if it is an issue with cout in >> | particular or if there is something else I’m missing. Please let me know if >> | you have any suggestions for me. >> >> Doug Bates sometimes remarks that, once all other alternatives are exhausted, >> one could consider reading the manual. And indeed, 'Writing R Extensions' has >> this to say: >> >> 5.6 Interfacing C++ code >> ======================== >> >> [...] >> >> Using C++ iostreams, as in this example, is best avoided. There is >> no guarantee that the output will appear in the R console, and indeed it >> will not on the R for Windows console. Use R code or the C entry points >> (*note Printing::) for all I/O if at all possible. >> >> In a nutshell, R 'owns' your console. That is part of the Faustian bargain. >> >> Dirk >> >> -- >> Gauss once played himself in a zero-sum game and won $50. >> -- #11 at http://www.gaussfacts.com > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel