How do you debug heavily templated code in c++? [duplicate]

Answer 1

For debugging, often it helps to just stop the meta-program at some point and show a type that is the result of some type computation. This can be achieved like this:

template <class T>
struct mp_debug : T::MP_DEBUG_FORCE_COMPILE_FAILURE {};

using Foo = int; // type to be inspected

// usage at namespace scope
template struct mp_debug<Foo>;

// usage at function scope
int main() {
  mp_debug<Foo>{};
}

This causes the compiler to print a compile-time error that shows the evaluated type argument of mp_debug.

Answer 2

Which compiler are you using? VC8 and 9 are actually pretty decent at outputting readable error messages. It still takes a bit of patience to go through, but it can be done, and they essentially show the compile-time equivalent of the call stack. Starting at the bottom, which template instantiation caused the error, and what were the template arguments? Next level up shows the template it was instantiated from and so on, all the way up to the top-level. Of course this is only visible in the "output" tab, not the "errors" one which it normally shows after a failed compile.

The principle is similar in GCC, although last I tried, at least, the formatting was somewhat less readable. But really, you just have to trace through the stack of instantiations, and at each level, verify that it got instantiated with the types you expected, until you find the one that introduced the error.

It's a pain, but it can be done, and it requires nothing more than patience and a willingness to read the error messages. :)

Also, liberal use of static_assert (or BOOST_STATIC_ASSERT) can help a lot by providing sanity checks

Answer 3

This should help you I think.

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

I have not used it myself; but, it might help you. I can also tell you that as you get more experience with templates and metaprograms you will get used to the error messages. They can be a bit tough to read sometimes; but, there is logic to their madness. Just make your terminal as large as you can and try to translate what it is saying in your head as you read it.

Answer 4

You get used to it as time goes by, and unfortunately if you plan on using C++, you have to. Because, some libraries like VC9 have good error messages, but as soon as you move to say GCC, or some other compiler, the messages are gone. And even VC9 won't help you much when you have errors from some library written by someone else, or yourself during a late-night, even some Boost libraries aren't that friendly. Simply because not every author has taken the trouble to make things clear when an error occurs, and that is even more common with new libraries (that tend to have the most errors and less help).

Also you must remember that the nice STATIC_ERRORS you may find here and there in code, are placed by the authors where things commonly break, and there will always be horrible corner cases, that the author didn't contemplate, that will produce 400 lines of error messages because you missed a const somewhere for example.

Using tools will help you out in the beginning, but hurt you on the long run. And since the problem is inherent of C++, its not going away any day soon. And these walls of errors will likely be with us until C++ is no longer in use. So tools will just cut your teeth, when you need them to survive. If you planning on leaving C++ soon, then please feel free to use them. Nowadays I can normally understand those 400-line error messages in one glance, so they are crystal clear to my eyes, but thats not thanks to any tools.

As with everything, especially C++, it takes experience and training.

Answer 5

If you're using gcc, I've found that colorgcc can help out a tiny bit. The color coding makes it easier to mentally parse out warnings vs. errors vs. contextual information.