This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/17781] add STL error message filtering
- From: "giovannibajo at libero dot it" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Oct 2004 01:42:26 -0000
- Subject: [Bug c++/17781] add STL error message filtering
- References: <20041001194704.17781.lothar@xcerla.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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