The following is a fairly technical post about something that came up during our programming efforts. It assumes a certain amount of experience with the intricacies of C++, so if that’s not your cup of tea, don’t pay this post any mind.

I spent some time yesterday integrating my C++ math library with Lua. I have a pretty robust Lua integration library at this point, but it heavily leverages template partial specialization to achieve the ease-of-extensibility that I want. While I have become rather adept in the past few months at dissecting and making use of template error messages, I ran into a confounding error that I simply had to share*.

Here is a C++ program that represents the kind of task I was attempting to implement. The original code was implementing C++-side templated generation of Lua userdata metatables for my templated mathematical primitive classes. The following code snippet, while contrived, should serve as a more digestible demonstrative example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

#include <iostream>
using namespace std;
 
// A few generic templates
template <int N>
struct Foo
{
};
template <>
struct Foo<1>
{
};
template <int N>
struct Printer
{
  static void Print()
  {
    cout<< "You have " << N << " " << Texter<Foo<N> >::GetText() <<endl;
  }
};
template <typename T>
struct Texter
{
  static const char* GetText() { return "apples"; }
};
 
// Let's call this next specialization "A"
template <>
struct Printer<1>
{
  static void Print()
  {
    cout<< "You have just one " << Texter<Foo<1> >::GetText() <<endl;
  }
};
 
// And let's call this next specialization "B"
template <int N>
struct Texter<Foo<N> >
{
  static void Test() { Printer<N>::Print(); }
  static const char* GetText() { return "apple"; }
};
 
int main(int argc, char** argv)
{
  Texter<Foo<1> >::Test();
}

So, what would you expect to happen when you run this program? I would have expected it to print out, “You have just one apple” and terminate. What I would NOT have expected is for it to spit out this error:

1
2
3
4
5
6
7
8
9
10
11
12

1>------ Build started: Project: TrickyTemplates, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>c:\finalformgames\trickytemplates\trickytemplates\main.cpp(40) : error C2039: 'Test' : is not a member of 'Texter<T>'
1>        with
1>        [
1>            T=Foo<1>
1>        ]
1>c:\finalformgames\trickytemplates\trickytemplates\main.cpp(40) : error C3861: 'Test': identifier not found
1>Build log was saved at "file://c:\FinalFormGames\TrickyTemplates\TrickyTemplates\Debug\BuildLog.htm"
1>TrickyTemplates - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

It was telling me that Texter<Foo<1>> does not have a method named Test in it. But there Test is, right above the call to it! All my efforts to statically analyze the program for the problem were fruitless (in part because the actual code was vastly more complex than this example). So, I did what anyone would do in my shoes, and started poking at it with a stick.

One surprising result: if I changed Printer to take in an additional template parameter, typename T, the error went away.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

...
template <typename T, int N>
struct Printer
{
  static void Print()
  {
    cout<< "You have " << N << " " << Texter<Foo<N> >::GetText() <<endl;
  }
};
...
template <typename T>
struct Printer<T, 1>
{
  static void Print()
  {
    cout<< "You have just one " << Texter<Foo<1> >::GetText() <<endl;
  }
};
...

Well, that’s pretty strange. Needless to say, this did little to allay my worry.

So, I rolled it back and broke out an old tried-and-true technique I picked up while working with the Metrowerks Codewarrior debugger: try moving blocks of code around. Sometimes this is illuminating, and, in fact, I found that by swapping the order of specializations “A” and “B” (see above code snippets), the error went away. Again, not too reassuring, but it gave me a lead by suggesting that something about this bug must relate to the order in which things are defined.

I searched online for all manner of permutations of keywords relating to the situation, and finally found this post on a site about the programming language D (which has many similarities to C++):

“If two template specialization refer to each other, there is the possibility that one of them will try to instance the other before the specialization for the other is created. The result would be either a compile error or an attempt to instance the wrong template. On the other hand, if I’m not missing something, a compiler would also be correct to lazy evaluate specializations, in which case this problem may well not occur. Some way to ensure the desired behavior here would be needed.”

So, my current understanding as to what was going on is as follows: The Printer<1> specialization is instantiating the Texter<Foo<1>> specialization before the Texter<Foo<N>> specialization is defined. This is because the correct order cannot be determined due to two specializations cyclically referring to each other. As a result, it is masking out the later definition of the Texter<Foo<N>> specialization. When we call Texter<Foo<1>>::Test() in main(), it uses the incorrect specialization, which does not define the a member named Test. This may be inaccurate, but it seems to line up best with the symptoms from what I have figured out. That being said, if you are familiar with this bug, or have a contrasting theory, please share with us below in the comments.

What’s especially surprising about this error is that there is supposed to be an error message you get when it happens! It’s not hard to invoke it, either:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// This compiles just fine:
template <int N> struct X
{
  static void A() { Y<N>::B(); }
  static void C() { }
};
template <int N> struct Y
{
  static void B() { X<N>::C(); }
};
int main(int argc, char** argv)
{
  X<1>::A();
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// This, however, throws a C2908!
template <int N> struct X {};
template <int N> struct Y {};
template <>
struct X<1>
{
  static void A() { Y<1>::B(); }
  static void C() { }
};
template <>
struct Y<1>
{
  static void B() { X<1>::C(); }
};
int main(int argc, char** argv)
{
  X<1>::A();
}

I do not mean to fault Microsoft for their failure to throw this error at me. It’s one hell of an edge case, and if you’re in this deep, you really ought not to rely on your compiler to bail you out when you do Bad Things. That being said, it’s nice to be able to trust that your compiler is Always Right, and experiences like this make that trust feel tenuous and uncertain.

In conclusion, do not let your template specializations refer to each other cyclically, or you may find yourself a sad, sad panda.

*Please note that this post refers specifically to behavior I experienced using Visual Studio 2008 9.0.21022.8 RTM on a machine running Windows XP. If you are on a different platform, you may or may not experience the same behavior.