[Rd] cerr and cout not working calling c++ from R

Sat May 7 04:09:06 CEST 2011

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" <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
>>> 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" <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.
>> 
>> Dirk
>> 
>> -- 
>> 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
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 