Deciphering C++ template error messages

Question

I\'m really beginning to understand what people mean when they say that C++\'s error messages are pretty terrible in regards to templates. I\'ve seen horrendously long erro

Answer 1

I sure as hell can't. Small errors explode into pages and pages of unreadable junk. Usually early in the morning, before coffee. :(

My only advice is to take a deep breath, start at the top and try and parse the important pieces of information. (I know, easier said than done, right?).

Answer 2

Even though its an old post, this may be helpful for other people stumbling upon this post.

I had exactly the same issue, in my case the errors could not even be printed to screen anymore as they were too long. So I dumped them into a text file and tried some basic search using a text editor rather than grep'ing through the file, some of which could be as large as 20 MB (not bad for just errors). Most errors would be duplicated, as I compiled in parallel, so that was another huge problem.

As I was getting tired with that approach (and also it was not very productive), I developed a small helper program which I could chain in directly into my compiler toolchain, so that any output generated by the compiler could be formatted based on some rules defined in a json file. The program can be found here: https://github.com/tomrobin-teschner/dotify

There are three basic functionalities:

• Don't print current output (line) from compiler if it contains a certain string
• Only print a certain line if it contains a keyword (which can be colorised)
• If there is a template involved, remove the content between the <> brackets and replace them by dots. So for example, MyClass<std::vector<double>, std::array<double, 3>> would be simply replaced by MyClass<...>.

The full error message is still stored inside a log file (and can be later used if more detailed information are required), the parser only works on the output which is printed to the console.

The command to invoke the parser is

/path/to/program | tee log | /path/to/parser -f /path/to/inputFile.json

/path/to/program is the program to execute (and from which the output should be formatted) /path/to/parser -f /path/to/inputFile.json, location of the parser, the -f flags specifies the input file (in json format), which, for a very simple case could look like this:

{
  "ignoreCompleteLineIfItContainsSubstring" : [
    "should be suppressed"
  ],
  "ignoreContentBetweenDelimiter" : [
    {
      "startingDelimiter" : "<",
      "endingDelimiter" : ">",
      "replaceContentBy" : "..."
    }
  ],
  "styleLineContainingKeywords" : [
    {
      "keyword" : "error",
      "removeDuplicates" : true,
      "applyStyle" : "onKeyword",
      "color" : "red",
      "style" : "bold"
    }
  ]
}

A full list of options and explanations can be found on the project site (https://github.com/tomrobin-teschner/dotify)

Answer 3

You can try the following tool to make things more sane:

http://www.bdsoft.com/tools/stlfilt.html

Answer 4

At least in Visual Studio, there is more information given in the Output Build window rather than the Error List. I've had a template error in the Error List state, "Cannot convert Foo<int> to Foo<int>". There were some lines following the actual error in the Output window that helped me to decipher what the actual problem was.

Answer 5

As @nsanders said STLFilt is a good solution. A home grown STLFilt (when you don't want to go to the trouble of installing Perl) is to copy the error message in an editor and start replacing parts of the error until it becomes (more) manageable.

e.g.

s/std::basic_string<char,std::char_traits<char>,std::allocator<char>>/string/g 

In less geeky terms this means:

Replace:

std::basic_string<char,std::char_traits<char>,std::allocator<char>>

With:

string

Answer 6

Some compilers give better messages than others. What compiler are you using? Having said that, they are all pretty bad. C++0X will fix most of this problem (see concepts), but the standard won't be released until 2009, and broad support will probably be even later than that :-(