[Rcpp-devel] How to handle std::cout/std::cerr in shared libraries

Watal M. Iwasaki heavy.watal at gmail.com
Fri Oct 26 16:36:37 CEST 2018


Dear Dirk,

Is it possible for Rcpp to do some pre-execution hook before user code? For
example, if Rcpp system can hijack the std::cout buffer by executing
`std::cout.rdbuf(Rcpp::Rcout.rdbuf())` automatically, then Rcpp users (and
external libraries) no longer have to care about Rcout, and can just stick
to std::cout.

Best,
Watal

On Fri, Oct 26, 2018 at 10:12 PM Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 26 October 2018 at 22:03, Watal M. Iwasaki wrote:
> | Dear Dirk,
> |
> | Thank you for the prompt response. Good to know there is no easy way. I
> | have made up my mind to change the library code as you suggested. But I
> | don't like preprocessor macro; therefore, the problem here was solved by
> | moving/hiding `std::cout.rdbuf()` part into the library as a function
> that
> | takes a streambuf pointer, and just calling it from Rcpp side. Now,
> output
> | is properly sent to R console, R CMD check complains nothing, and the
> | library still remains free from R/Rcpp code. Thanks again.
>
> Nicely done.
>
> We could do with a more general solution to this. If you have ideas ...
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>


-- 
Watal M. Iwasaki / 岩嵜 航
SOKENDAI, The Graduate University for Advanced Studies,
Hayama, Kanagawa 240-0193, Japan
+81-46-858-1576
https://heavywatal.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20181026/c4d05420/attachment.html>


More information about the Rcpp-devel mailing list