This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unifying the GCC Debugging Interface


On Wed, Nov 21, 2012 at 9:02 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>>
>>> 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.
>>
>> I agree with Lawrence that for texts that need localization, what
>> we currently have is probably much better deployed.  On the other hand, for
>> debugging routines and in-memory formatting, IOStreams are
>> very handy.
>
> I'm not deeply against iostreams, but I don't see that they bring us
> any significant advantages over what we already have.  We already have
> typed check formatting, we can already write to a memory buffer.  It
> took a lot of work to get there, but that work has been done.  It's
> quite unlikely that we would ever want to use iostreams for
> user-visible compiler output, because there is no straightforward
> support for localization.

As I said earlier, our homegrown IO with localization is probably much
better than what bare bones C++ IOstreams offer, so we are all
in agreement over this.

> So we are only talking about dump files and
> debug output.

Yes.

>  What parts of the compiler would be clearly better if
> we used iostreams?

Having to hardcode the format specifiers means that we
are either restricted in changes or bound to (silent
truncation) errors when we change representation.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]