OSNews

Yes, but sometimes a nicer and more precise error message would be helpful.
The most disturbing error messages I've seen so far are from accidentially feeding C++ code into gcc. Holy sh*t, if these error messages are not scary I don't know what is! So if gcc tells you that your code doesn't make any sense it's probably because you should have called g++ in the first place.

Nevertheless, it should do some simple checks like running g++ (if it's installed) on the same input and check if it produces less error messages. A simple hint like "You want to run g++ on this source" would be nice.

Yeah. Makes me nervous about the wth is going on with template code that compiles but isn't 100% correct. And how many crashes all that ridiculous complexity has caused.

The more fun ones are template errors. Two pages of output and you still have no idea what you did wrong.

Well, you're coding in C++, yes? There's where you went wrong lol

Write some moderately complex code using Boost.Lambda, then make a typo. Just one, in an innocuous a place as you can find. G++ will just barf all over your shoes, and you won't be able to get the smell out for a week.

The complete illegibility of template expansion errors has killed any enthusiasm I had for Boost, or "modern C++" in general. Its not really the fault of the compilers, C++ templates are just a fundamentally crappy feature from an ease-of-use and ease-of-implementation point of view.

Edited 2007-03-09 21:36

I definitely have found Java to give more specific errors when there are compile problems - I think it is due to the degree of reflection in the language itself. I think that makes it an easier job for the compiler to spot errors.

It's not the degree of reflection in the language, but rather the syntax and semantics of the language. Java is explicitly designed to be parseable with an LALR(1) grammar. Parsing C++ is nearly impossible with conventional parser generators that are designed for LALR grammars. Also, the template syntax is very poorly suited for use in meta-programming, because it wasn't originally designed for that. It "evolved" from a simple generic programming facility into a meta-programming facility. When you combine all this with the fact that C++ tries very hard to maintain compatibility with the extremely primitive C linking model, you end up with the mess you have now.

It is entirely possible to design a macro (meta-programming) system that is powerful, simple, and relatively easy to implement. Between Scheme, Lisp, and Dylan, there are probably a couple of dozen good macro implementations in existence. In comparison, there are all of three C++ parsers that even come close to standards compliance, even despite the fact that there is probably a couple of orders of magnitude more effort put into C++ implementations than into implementations for those languages combined.

I'm going to use Dylan's macro system as a point of comparison, since the prefix syntax of Scheme and Lisp make macros much simpler to implement and easier to understand. However, it should be noted that these points apply almost universally to macro systems in all of these languages. The first thing the Dylan designers did right with the macro system is make the language LALR(1) parseable, including the macro sub-language. This means that you don't need to hand-write a complicated parser for the language, but you can instead use one of the array of tools that exist for dealing with LALR grammars. Second, they designed it explicitly for meta-programming, specified that basic syntactic constructs in the language (things like "for" loops) should be implemented as macros over more primitive constructs. This gave compiler writers a very strong incentive to make macro-expansion error messages really easy to understand, otherwise even simple syntax errors in loops would be incomprehensible. Third, Dylan compilers treat macros as first-class compile-time objects, and store a representation of the macro in the compiled output. Not only does this buy you the ability to export macros from shared libraries, but it gives the compiler a very clear separation between the single definition of the macro and uses of the macro. Fourth, and this is a point that ties back to the ease of implementation point, Dylan IDEs give you a way to see the code after macro-expansion. Almost all compile-time errors that result from calling a macro happen because the macro is used improperly in a way that causes invalid code to be generated. Looking at the expanded code usually makes it immediately obvious what you did wrong.

I actually like C++ templates and Boost quite a lot. It's just the compiler errors that suck.

It's much easier to find the bug by inspecting the code than reading the error.

It should be pretty easy to add an optional fatal warning if a class isn't properly terminated by the end of a file.

"If GCC is so bad at producing legible error messages, why not offer the developers more appropriate messages instead of complaining? Be part of the solution, not the problem."

Personally, I like the concept of throwing a detailed error message containing some information:
- What error occured?
- Where did the error occur?
- What initiated the error?

This goes for gcc as well as for any other program. For example, instead of throwing "error 5", something like "error: fopen(): file not found: /dev/foobar" would be the right way to inform the user about an abnormal termination.

A detailed and complete (!) explaination of the problem is the best way to get a solution. This is not "complaining", it rather is "identifying the error as exact as possible". The compiler is not the problem. The source code files passed to it are - or the ones who wrote it. :-)

In most cases, the compiler can only judge from syntax, but not from context. It uses the description of the "skeleton" of the C programming language, but it cannot imagine what the programmer wants. Maybe you're thinking about the semantic compiler? :-)

int a, b, sum;
sum = a - b;

semcc: error in foo.c in line 5: You wanted a sum, but got a difference. Please change '-' to '+'. By the way, I fixed it for you...

Would that be more appealing? :-)

(Excuse me if I'm doing you wrong. It's typical for most users that they don't know what they're doing, but should we enlarge this way of doing things to programmers, too? 'Trial and error' is not a programming concept.)