Has anybody thought about inserting a capability like STLfilt (see http://www.bdsoft.com/tools/stlfilt.html) to gcc? It woukd be great if gcc would be the first compiler out there having this VERY useful feature built in.
most of the problems come from displaying the default template arguments, see PR 14912 for a bug about that.
STLfilt does a pretty good job already. It would be a GREAT use to the average gcc user if gcc only could mimic the behaviour of STLfilt. I consider myself quite fluent with STL/templates but even I have trouble to parse these long error messages. How much more trouble is it to a novice user. And even if the parsing fails in some situations; it's still worthwile in a lot other situations. In case it fails to parse the message or the user wants full control gcc could provide a switch to turn it off, so she can look (again) to the lengthy full error message. Its just that I'd like to have gcc do the message parsing than having another tool to wrap around gcc which may or may not work with different build environments.
No, sorry, GCC won't do this at this point. Our job is making a correct diagnostic. If C++ template errors are too hard, we can't help it. This is what STLFilt is for. I just hope the next C++ will have a good way to emit compile- time errors.
Could you please state what "next C++" means (next standard, next version of gcc, ...). 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 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 also would like to know what arguments speak against such a feature, as it proves to be worthwile (why should it be implemented as an external filter otherwise). As said before it could be controlled by a flag, so current message behaviour will be still available. If it is considered useful by enough people, why should it then not be included in the compiler?
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
Hummm... Something we *could* do is further extending and improving the concept check machinery in libstdc++-v3 (we are already doing that a bit, actually ;) and/or bring in the latest improvements in Boost: IMO often the error messages are more clear and short. Are you already using it?? See: http://www.boost.org/libs/concept_check/concept_check.htm and, of course: http://gcc.gnu.org/onlinedocs/libstdc++/19_diagnostics/howto.html#3