On Jul 30, 2008, at 12:35 , Ernest Turro wrote:
On 30 Jul 2008, at 15:18, Kjell Konis wrote:
I found this in Writing R Extensions:
"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 (see Printing) for all I/O if at all possible."
That is, use Rprintf() instead. The fact that your code works with
one version of gcc and not another can probably be chalked up to
coincidence.
The doc warns that the output to stdout using iostreams may not
appear on the console, there is no indication that doing this may
crash R (and this has never happened to me before). Certainly, the
use of file streams (fstreams) should work just fine.
FWIW I saw this problem when using mismatching compilers before (long
time ago when we had to use FSF-built gcc because of bugs in Apple's
gcc). Its likely cause is a combination of incompatible ABIs and
libstdc++ mismatch. Note that Apple's gcc build script goes into great
pains to not mess up system stdc++ because it's asking for trouble.
Cheers,
Simon
Kjell
On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote:
Dear all,
R on Macports relies on GCC 4.3 to build packages. I find that
packages with shared objects that use C++ streams crash R if they're
compiled using Macports' gcc43, but work fine if compiled in exactly
the same way using Apple-supplied GCC 4.2. Has anyone here had the
same issue/know what is causing this problem?
Thanks,
Ernest
______________________________________________
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
