How to call operator<< functions?

[Daniel Jacobowitz]

As a general note: the most useful thing to accompany any bug report is
a test case! :-)  We can't fix them without tests.

On Wed, Aug 30, 2006 at 01:11:43PM +0300, Michael Veksler wrote:
> Passing 'std::cout' seems impossible. Any attempt to pass std::cout 
> crashes. To overcome this I define my own global
>    ostream gecLog(cout.rdbuf()); 
> (or something similar) and recompile the code. This lets me pass gecLog 
> instead of cout, and it _sometimes_ works:

Fred's response seems reasonable; that might be the problem, or it
might be something else.  If you have a testcase, please post it.

> (gdb) p pd.Print(gecLog)
> Cannot resolve method (null)Print to any overloaded instance

Ditto.  I've never seen this error before.

> --------------------------------------
> I wanted to do the same for operator<<:
> (gdb) p 'operator<<(std::ostream&, MyClass const&)'
> $17 = {ostream &(ostream &, const class MyClass
>     &)} 0x8068a00 <operator<<(std::ostream&, MyClass const&)>
> (gdb) p $17(gecLog, *pd)
> Program received signal SIGSEGV, Segmentation fault.
> -----------------------

You can just use "print gecLog << *pd".  Does that work better? 
Anyway, I would have expected calling the operator to work.

With tests for these bugs we can make the next GDB release the
best ever for C++.

> Print(cerr). Sometimes, while debugging a piece of code,  that a vital 
> object has <<, but no DebugPrint, and *that* really frustrates me - 
> especially when I loose a 60 minutes debugging session to a SIGSEGV.

You might want to use set unwindonsignal, then, as it suggests. 
There's some risk associated, but it usually works.  You can also
use "return" to get out of the called function, but make sure you tell
GDB not to pass the sigsegv when you continue.

-- 
Daniel Jacobowitz
CodeSourcery