Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have worked a little while with the Microsoft compiler from Visual C++ but I worked a long time with G++, and I remember often having bad times understanding what was wrong in my code with the former.

Beside binary code generation and optimisation, I think this is a very important feature of a C++ compiler: giving the programmer a clue that makes him understand as fast as possible what is wrong with his/her code. I can understand some programmers understand programming as some sort of "competition" to make less errors, but to me that's a counter productive opinion.

I once tried Clang compiler for C from the LLVM thingie, I didn't use it for a long time, but I was impressed on how explicit and easy to understand the error messages were.

What are your experiences, and how do you think this matters ?

Some WIP of C++ Clang:

share|improve this question

migrated from Jan 2 '11 at 7:38

This question came from our site for professional and enthusiast programmers.

I usually understand VC++ errors, and I find it interesting that you didn't provide any examples. – Jonathan Wood Dec 31 '10 at 14:29
A prerequisite to understanding compiler errors is understanding the language and its features. – Klaus Byskov Hoffmann Dec 31 '10 at 14:31
@Klaus, compilers could still have been a bit more user-friendly, for example compile errors in templated code are incredibly difficult to understand even for experienced programmers (I remember there was a log post-processor trying to make them more natural) – 7vies Dec 31 '10 at 14:33
Template code, naturally, is the most difficult for compiler to present clearly, nevertheless, it's rather rare when VC can't produce easily comprehensible error messages. It clearly shows instantiation stack in a nice formatted way. So this problem seems to me blown out of proportions. – Gene Bushuyev Dec 31 '10 at 15:16
3 "...AND your window wasn't wide enough to read this whole error message" Hehehe... – dmckee Jan 1 '11 at 23:03

6 Answers 6

up vote 6 down vote accepted

From what I have seen, Clang definitely has the best error messages available.

This however comes at a cost: it takes time to develop and test.

I think therefore that this is more a mindset issue than anything else: VS and gcc are trying to provide ever more C++0x support these days, and compliance is hard to achieve, and some new features required extensive rewrite (move semantics and rvalue references come to mind).

Clang on the other hand was built with nice error reporting as an advertised feature. It's an integral part of the compiler: the very Diagnostic core has been built around this feature, with Hint, SourceRange etc...

It is also a real focus of developers (I have seen commits whose sole goals was to improve an existing error message) and suggestions on error reporting are always appreciated (either new diagnosis or improved diagnosis).

I suppose this comes at the cost of diverting manpower from other tasks. Of course, for open-source software it may not be the case, since improving diagnosis is usually a relatively trivial task it may be tackled by beginners while the lead / experienced developers may focus on core features.

Edit: Example of recent (today) commit

Chandler Carruth modified the diagnostic emitted for arrays with a negative size to include the name of the array in the error message itself, because as of C++03 the poor's man static_assert is often implemented using this trick, with the name of array being the error message intended :)

share|improve this answer
damn I'm so impatient to try the C++ form the LLVM. – jokoon Jan 4 '11 at 18:16
Can you provide a naive sample? – OscarRyz Jan 4 '11 at 19:28

Honestly, if you are having problems getting your code to compile then there are much larger issues than perhaps less than ideal error messages. The compiler IS NOT a debugger.

I understand that the messages can be pretty confusing for newbs. In that case, I suggest complying often rather than after writing the whole application. It is really hard to figure out what is wrong with the code if you write code with a ton a mistakes.

For seasoned programmers though, getting code to compile should not even be an issue.

Either way, once you work with the compiler for a bit the messages are not as cryptic as you might think.

share|improve this answer
What is a "newbs" ? Furthermore, I don't think a message is more confusing for a begginner than for an experienced programmer: a programmer used to some symptomatic compiler error can quickly guess the errors. An experienced programmer who changes his compiler might have to learn the symptoms again. A compiler is not a debugger, but I find the purpose of the compiler much more important than a debugguer: it finds all typo errors: a programmer has to have a good algorithm, the job of the compiler is to help the programmer translate his idea into machine code, and error finding is all about this – jokoon Jan 5 '11 at 9:55

I think it does take a while to get used to a particular compiler's error messages, but once you have understood what each message means, (in my experience) you are in a good position to find the issue. Some compilers are better than others in terms of understanding what they are doing, so obviously it is worth putting some effort into generating decent messages, but at the end of the day, there is not silver bullet, you still need to examine the code manually and fix it!

It is a very hard problem to be specific about compiler errors without guessing- no one likes a smartarse less than programmers.

share|improve this answer
+1. Exactly my experience. – Martin v. Löwis Dec 31 '10 at 14:33
template error messages especially vary wildly between compilers, and when the critical information just isn't part of the message, there's no way to "get used to it". – Ben Voigt Dec 31 '10 at 14:34
Message + guessing sounds more appropriate to me than just a hardcore message (templates are a good example) – 7vies Dec 31 '10 at 14:39

Basically, the compiler should not do anything more than pointing out which line is the culprit one and a little description of what is wrong. It is supposed you know the theory behind how general programming works and how your programming language works, thus more info from the compiler would not be needed in my humble opinion. If a compiler that does explain this kind of errors is to be made/has been done, i guess a lot of the time on it's development was used [READ: Used, not wasted] in the logic to parse those errors into human-readable and fully-explained English where that time could of been used into better optimization/standards compliance... I am not saying this is bad, but if i have to choose between a fully-fledged standard compiler such as the MSVC compiler and something a tad bit under-developed but that explains everything 100%... id go with MSVC. These are my 2 cents, bear in mind i have NOT used Clang and have no real idea of what it is. Happy coding :)

share|improve this answer
Looking at the total cost of a program, it is quite likely that for learners (in particular - even for many experienced programmers too), the compiler with the excellent error messages ends up being cheaper than the compiler with most advanced possible optimizations. Very few programs really depend on the utmost in compiler efficiency (and when they do, there is 20% or less of the code where it matters, and 80% or more where it does not). – Jonathan Leffler Dec 31 '10 at 14:39
I am just thinking that the "Excellent error messages" compiler could be under-developed respecting the standard compiler, but watching it from your POV i think you are right as well... This is pretty much personal preference :) – Machinarius Dec 31 '10 at 14:44
you are partially right, partially because Clang is still very much in development (C++03 is claim as supported as of December, C++0x is a far goal which puts in much behind gcc or VS there), but this has more to do with the fact that it is a new compiler than with the fact that its error messages are great. I'd love VS and gcc to work on their error messages, really. – Matthieu M. Jan 4 '11 at 16:01

From my experience:

1) C++ is complicated enough to make it difficult to parse it whatsoever, not to mention parse it with good error recovery. For example, omitting ; at the end of class definition often makes it one with the following declaration/definition, thus yielding a cryptic message like:

New types cannot be defined in return type

instead of

Omitted ; after class definition

And the error is technically true! The problem is, the class def may be in one file and the error will appear in different one, which very often confuses beginner programmers (oh how many times did I fall for this one myself years ago!). But still, today's compilers try to be helpful - for example for quite some time g++ will give a hint ("did you forget a ;?") after the problem.

C++ is not perfect in most cases, but like 90% of them are quite simple to understand, and trivially simple once you know a bit better how C++ grammar looks like.

But there's a whole second level of errors out there...

2) Definitely the MOST sophiscated error messages a programmer may ever see are the errors related to templates and template instantiation. Such an error (just one!) often may span several screenfuls of text and an apprentice C++ programmer will panic at the very first sight. And the error underneath may be anything: even a simple typo in method name.

The problem here is simple: Templates in C++ are a programming language by themselves. No exagerrating here, they're proven to be Turing-complete :) And I believe that with the current C++, when you make a mistake with templates, there's NO reliable way for the compiler to guess "how this code is supposed to look like".

Then, the only thing the compiler can do is to say: I cannot instantiate template X with arguments A, B and C when C is a template instantiated with U, W, because C<U,W> cannot be passed as a parameter to X::foo(A,B,C<K,R>), et cetera, et cetera. Fill this with meaningful template names, meaningful method names and a lot of namespaces in between and you get lots of lines. Now, add "candidates are:" section to that and this gets LONG. Helpful and - with a little bit of patience and experience - readable, but LONG.

In fact, there was an attempt to solve this situation. It was called "concepts" and was meant to be included in the next C++ standard. Basically, a concept was to be something like a formal specificatation of the "interface" of a template.

With concepts, the above may be reduced to "the template T was declared to be instantiable with the second template parameter obeying the concept XYZ, and that template doesn't support XYZ, so I cannot instantiate T here".

But the problem is that "concepts", in order to be defined in a correct and useful manner, would be probably even more complicated than the template system itself. So they gave it up in C++0x...

So the answer is sad: The best thing we can do is to make a syntax colouring and formatting script for the compilers' error messages about templates. :)

share|improve this answer
Without concepts, it is just duck typing, which is fun until you make a mistake. Quack quack. – 7vies Dec 31 '10 at 15:05
@7vies, duck typing has its advantages. I'm sure when concepts will be added, people will complain that they are too restricting. Just by adding 'cout << whatever' the code may no longer compile, because a template wasn't declared to be stream-able, though it was stream-able in "duck typing" sense. Some things being implicit can be both a boon and a hurdle. – Gene Bushuyev Dec 31 '10 at 15:23
@Gene, yep this implies all those "static vs dynamic" questions. On the other hand, concepts do not forbid duck typing - they only ensure that a class implements a certain interface, which is more powerful than classic inheritance. – 7vies Dec 31 '10 at 15:44
@7vies, though concepts have not been finalized yet, there are many problems with existing approach, like the problem I pointed. To save time, here is a Stroustrup's paper: – Gene Bushuyev Dec 31 '10 at 16:08
As always, when you get a long list of compilation errors, start with the first error on the top, not the last error on the bottom. Usually the whole list will disappear once you've fixed that first one. – gablin Jan 4 '11 at 10:54

As a compiler implementor I can tell you that reporting errors is the hardest part of compiler design. It means not only translating stuff, it means keeping track of how you translated it so if something goes wrong you have a "back trace" of how the compiler got there.

For example with templates, you can instantiate a template type parameter with an argument which is itself a template, and so to report an error context you have to report: the point the base type is defined, the point the template using it is defined, the point the template using it uses it, the point the outer template is defined, and the point that it is applied to the template .. and then the error may be in some method call applied to the resultant object which can't be reported until you call it so that's another point. So for a simple code like:

X<Y<T>> a; a.f();

you have 6 distinct places in the source to report, any one of which could be the position of the actual error. Even if the end user can wade through this trivial example with only 6 positions reported they have no hope of wading through a more complex example, so the compiler HAS to do some work to try to guess what it should report and what to leave out.

And all this requires keeping track of all that information.. for just about every "term" in the AST and IL. Can you imagine reporting a problem where there was overload resolution done, and an error occurs because the "wrong" overload was selected?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.