This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Unifying the GCC Debugging Interface
On 11/20/12, Xinliang David Li <davidxl@google.com> 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 <crowl@googlers.com> wrote:
>> On 11/20/12, Diego Novillo <dnovillo@google.com> wrote:
>>> On Nov 20, 2012 Basile Starynkevitch <basile@starynkevitch.net> 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