But one thing that never ceases to amaze me is how bad the GNU C++ compiler's error messages can be. Why does this amaze me? Well, presumably GNU C++ is one of the compilers that is mostly frequently used by developers who "just care about writing working code, not messing with all that formal mumbo jumbo." Case in point, the following error message:
NelsYield-Instrumented.cxx:12: error: new types may not be defined in a return typeOkay, this doesn't seem too bad. But first, oh compiler, wouldn't it be helpful to tell me which type is the 'new' type you think that I'm declaring? Regardless, I know enough about what's going on to know that the error is not in using an undeclared type (the type is included in the header file that I #include) but rather somewhere else in the process. This isn't the best example of bad error messages from g++, it was the closest one at hand, but I personally have seen much worse, much less helpful messages. Just like SML, the error message never seems to actually tell you what the problem is, and you end up being Mr. C++ detective. Java is a dream by comparison. Anyway, just a little venting... not really sure where I'm going with all of this.
Update:
Natuarlly, I was missing a semi-colon at the end of my class definition. C++, I hate you will all of my being.
The main reason it is hard for ML compilers like SMLnj to have good error messages is type inference. An "error" might be the result of a mistake made way earlier in the program that made the compiler commit to a particular incorrect type for some value which later results in an un-typable use of that code. C++ certainly doesn't have the same excuse.
ReplyDeleteNot sure if you are aware of it or not, but there is work on generating better error messages for both ML-like languages (OCaml) and C++ at the University of Washington.
Oh yeah I know. I totally understand why ML has this problem and in fact I (most of the time) believe that type inference is worth it. As far as I understand, type inference works a lot like a constraint solver, and when several constraints are contradictory, it's hard to point out which one is wrong. (Is that a fair description of the problem?)
ReplyDeleteAnyway, I am looking at this more from the other perspective. If someone weren't willing to use SML because of its so-so error messages, I would politely point out the fact that g++'s error messages also leave a lot to be desired. C++ is a (overly) complex language, and I believe this has a lot to do with the quality of error messages that its compilers produce.