Re: Redirectable octave?

[Michael Goffioul]

On 10/16/07, John W. Eaton <address@hidden> wrote:
> | int octave_main(int argc, char **argv, int embedded, FILE* in, FILE
> | *out, FILE *err)
>
> Since Octave uses std::cin, std::cout, and std::cerr instead of stdin,
> stdout, and stderr,

Actually, the parsing code uses stdin (see get_input_from_stdin). For
stdout/stderr, I'm not sure.

> I think it would be best if these were istream and
> ostream objects instead of FILE objects, but then that means the
> octave_main function has to be a C++ function and you probably have to
> deal with name mangling issues when looking it up in your DLL.

Indeed, I would rather avoid dealing with C++ types as it makes dynamic
loading difficult (impossible?). Using FILE* was just a initial idea, to
illustrate what I had in mind.

> It would be possible for us to use our own named references to
> std::cin, std::cout, and std::cerr inside of Octave, but that won't
> prevent people from writing directly to them in their own .oct files,
> so I don't see this as a complete solution to your problem.

Indeed, but if octave at least could have configurable std IO, that would
already be good. If these std IO's are then available through a well defined
API (in the same way there is an octave_stdout available), it would be
up to the oct files to use them if they want their input/output to be
handled correctly.

In the end, you have the same problem with Matlab in MEX files: if you
want something to appear in the Matlab console, you must use mexPrintf
instead of regular stdio calls (I'm talking about Matlab in GUI mode).

Michael.