This is the mail archive of the gcc-bugs@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]

[Bug c++/17781] add STL error message filtering


------- Additional Comments From giovannibajo at libero dot it  2004-10-02 01:42 -------
Subject: Re:  add STL error message filtering

lothar at xcerla dot com wrote:

> Could you please state what "next C++" means (next
> standard, next version of gcc, ...).

Next standard.

> Actually I started this entry (with Severity: enhancement) to spawn a
> discussion about adding such aid to the compiler rather than to rely
> on external tools that may or may not work with the users build
> environment and may or may not break with new releases of the compiler.

I understand that. We get many enhancement requests in Bugzilla, and we use our
own judgement to keep the ones that we think have a reasonable possibility to
ever get implemented. This one is not in this category. There is a widely used
tool, STLFilt, which is free by any means and works very well. It is written in
perl so I guess it works almost everywhere. If the compiler would change its
error message so radically to break it (and notice, it hadn't for a decade or
so), the tool could still be updated in probably less than a couple of hours.

Really, this does not belong to the compiler. It is much more difficult to
implement it in there.

> I believe that readable and understandsable compiler messages are
> CRUCIAL for both compiler writers and compiler users. If users do
> not understand error messages their cry for help will flood the compiler
writers.

I could not agree more. Though, it is not GCC's fault is STL names are complex
and hard to understand. Our job is to produce a correct error message, which
includes a full instantiation specification. If you do not like it, you can use
STLFilt.

> If it is considered useful by enough people, why should it then not be
> included in the compiler?

Because GCC development is not like this. If you feel so strong about this, I
suggest you to start implementing this yourself and prepare a preliminar patch.
You will realize that the code you have to touch is much, much, much more than
a couple of regexp lines that you can use in perl. Otherwise, another option
would be for you to hire someone to do the job.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17781


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