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: Improving C++ error output?


> To most developers I know, the number one annoying thing about C++/STL
> programming is deciphering inane error messages.  (For example, forget
> to declare an iostream operator << for your data type, and you're
> treated to a 75-line error message detailing all the candidate operator
> <<s; informative, but way *too* informative.)

-fmessage-length=0 can help a bit, especially if you want to postprocess
(automatically or with an editor).  But yes, there's no point in reporting
more than a relatively small number of candidates (default, say, to three,
report the first three, then a count of how many more aren't printed).
A user option could change the threshold.

> Has there been any work towards making g++ error output easily
> machine-readable?  E.g., a command-line flag --error-format=xml causing
> errors to be output in XML.  If I did some work toward this end, would
> it have a shot at being accepted into the g++ tree?

I'm not sure that this is the right approach.  If you can do something
intelligent in a post processor, it could probably be done better inside
the compiler where more information is available.


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