On 25 November 2011 02:48, Dean Michael Berris <mikhailberis@gmail.com> wrote:
But it's not the library emitting these horrible error messages. So why is this tied with the library and not the compiler?
Imagine you know nothing of boost. You're using C++ and you're used to the normal error messages, not great but you understand them. Then one day someone points you to this exiting lambda emulation called Phoenix, you see the demos and they look great. You sit down and try writing a small program. And pages and pages of error messages fill your screen. You don't then think, "my compiler generates bad error messages" as it's normally good enough. You think, "I don't like this" and it happened as a result of using Phoenix. So the link is made, "Phoenix creates horrible error messages".
Why aren't people saying "I don't want to use this compiler because it's crappy at generating error messages for *any* code"?
People are reluctant to change from what they're used to. The following is from a post about google's use of clang. Remember that many C++ programmers won't even bother to try clang, let alone give it a week. On 31 October 2011 20:54, Chandler Carruth <chandlerc@google.com> wrote:
That said, while the feedback was overwhelmingly positive, there were definitely some who were less enthusiastic. Many of these people had worked with GCC for so long that they exhibited strong change aversion. The messages from GCC are very familiar, and map to an existing set of problem descriptions for these people. They faced a learning curve when the messages changed *at all*, and that was costly. Interestingly, for a surprising number of people in this bucket, after a few months of using Clang, they were reluctant to switch back. They had slowly noticed and started using several common elements of Clang's diagnostics (such as typo-correction and macro backtraces) without even realizing it. When they looked at GCC's messages, they didn't have the information they wanted to understand the problem.
The full post is at: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-October/018352.html