Right -- gdb does not know the complete type of std::cout and
std::cerr -- try the following program with -g and invoke print, or <<
in the debugger -- see what you will get:
#include <iostream>
using namespace std;
class A {
public:
int i;
};
__attribute__((noinline)) void print (ostream& os, const A& a) { os <<
a.i << endl ; }
__attribute__((noinline)) void operator<< (ostream& os, const A& a)
{
os << a.i << endl;
}
int main()
{
A a;
cout << a;
print (cout, a);
On Tue, Nov 20, 2012 at 4:37 PM, Lawrence Crowl <[email protected]> wrote:
> On 11/20/12, Xinliang David Li <[email protected]> wrote:
>> one minus -- less gdb friendly.
>
> Do you mean that gdb does not handle the stream expressions
> or something else?
>
>>
>> David
>>
>> On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl <[email protected]> wrote:
>>> On 11/20/12, Diego Novillo <[email protected]> wrote:
>>>> On Nov 20, 2012 Basile Starynkevitch <[email protected]> wrote:
>>>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>>>> > > function (FILE *, item_to_dump, formatting)
>>>> > > function (item_to_dump, formatting)
>>>> >
>>>> > Since we have switched to C++, it would be really nice to have
>>>> > dump functions writing to a C++ std::ostream
>>>>
>>>> I'm not sure what to think about using streams. I have no great
>>>> familiarity with them, so I can't say whether they provide any
>>>> concrete advantages over dumping to FILE objects. Additionally,
>>>> the rest of the compiler uses FILE objects for I/O. How do the
>>>> two stay in sync?
>>>
>>> There are two big advantages. First, you can concisely output a
>>> bunch of stuff without having to worry about types. Very good for
>>> quick coding.
>>>
>>> std::cout << "My variable is " << varnode
>>> << " and its type is " << typnode
>>> << std::endl;
>>>
>>> Second, the streams write to an output stream, which can be a
>>> file or it can be a string buffer. So, output isn't essentially
>>> different from writing chars to a string.
>>>
>>> The primary disadvantage is that to exploit that those advantages,
>>> you need to convert all of the debugging/dumping I/O to use streams.
>>>
>>> And, as a side note, highly formatted output generally is not
>>> much better than printf. For any text that needs to be localized,
>>> I recommend that we stick with what we have.
>>>
>>> --
>>> Lawrence Crowl
>>
>
>
> --
> Lawrence Crowl