[Rd] cerr and cout not working calling c++ from R
simon.urbanek at r-project.org
Sat May 7 04:09:06 CEST 2011
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).
On May 6, 2011, at 3:19 PM, Sean Robert McGuffee wrote:
> 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,
> 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.
> On 5/6/11 2:50 PM, "Davor Cubranic" <cubranic at 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
>>> | 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
> On 5/6/11 2:41 PM, "Dirk Eddelbuettel" <edd at 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.
>> Gauss once played himself in a zero-sum game and won $50.
>> -- #11 at http://www.gaussfacts.com
> R-devel at r-project.org mailing list
More information about the R-devel