Re: How to break out of a computation?

[John W. Eaton]

On 20-Feb-2006, Sebastien Loisel wrote:

| >
| > | std::ostream &get_cerr(void) { return cerr; }
| >
| > I don't think I want to add this function to Octave.  A DLL or shared
| > library is just an implementation detail.  There should be one
| > std::cerr symbol for a program.  If there are multiple std::cerr symbols
| > depending on the way a program is linked, then I would think that is a
| > bug in the compiler/libraries on your system.  Can you point to some
| > explanation of why this would not be a bug?
| 
| 
| The experts at MinGW answered that question here:
| 
| http://sourceforge.net/forum/forum.php?thread_id=1442855&forum_id=286529
| 
| Apparently it's a Microsoft design decision and there's no workaround except
| the one I gave above. Since I have zero hope of getting Microsoft to fix it,
| either it goes into octave, or embedded Octave users on Windows (including
| Cygwin) will forevermore use a patch.
| 
| Depending on why you oppose it, there are still possibilities. First off,
| you don't need to put this function in a header file anywhere. Second, if
| you don't want to pollute your symbol table, you can #ifdef __MINGW__ it.
| Third, you could autoconf it.

OK, I'm reluctant to add the function because it seems like a big-time
kluge.  Every .oct file is a DLL, so output from any .oct file that
uses std::cerr directly will lose output and that seems bad.  Of
course, they really shouldn't be using std::cerr directly anyway (they
should be using Octave's error() function).  But anyway, the solution
is clearly not for every .oct file to have a function like your
get_cerr above.

I would be willing to fix Octave to have an octave_stderr stream and
use that internally, similar to the octave_stdout stream that we use
now.  Would that help?

Also, ideas like trying to grab the file descriptor seem a bit
questionable to me.  That seems to depend on the current
implementation details for DLLs and C++ on Windows, and that could
probably change at any time.

BTW, does the Windows implementation of std::cout mean that if you do
something like

  function_from_dll_one ("some output");
  function_from_dll_two ("some other output");

in which these functions both write to std::cout, but they are defined
in separate DLLs, that the order of output is not defined?  I'm
thinking that if the separate std::cout objects defined in the separate
DLLs have separate buffers, they could be flushed in an order that is
not expected.  It seems to me that it is bad to design a system that
would behave in significantly different ways depending on the linking
method used since I see that as purely a detail of the implmentation,
and something that one should not have to worry about (these functions
are defined in separate DLLs?  Oh, better do something extra then).

jwe