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

[Sean Robert McGuffee]

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