将类静态成员定义放入cpp文件 - 技术限制？

Question

one of my "favorite" annoyance when coding in C++ is declaring some static variable in my class and then looking at compilation error about unresolved static variable (in earlier times, I was always scared as hell what does it mean).

I mean classic example like:

Test.h

class Test
{
private:
  static int m_staticVar;
  int m_var;
}

Test.cpp

int Test::m_staticVar;

What makes it in my eyes even more confusing is the syntax of this definition, you can't use 'static' word here (as static has different meaning when used in cpp, sigh) so you have no idea (except the knowledge static member vars work like that) why on earth there's some int from Test class defined in this way and why m_var isn't.

To your knowledge / opinion, why is that? I can think of only one reason and that is making linker life easier -- ie for the same reason why you can't use non-integral constants (SomeClass m_var = something). But I don't like an idea of bending language features just because some part of compilation chain would have hard time eating it...

Answer 1

Well, this is just the way it works. You've only declared the static member in the .h file. The linker needs to be able to find exactly one definition of that static member in the object files it links together. You can't put the definition in the .h file, that would generate multiple definitions.

UPDATE: C++17 can solve this with an inline variable .

Answer 2

First, from compiler's point of view, this is perfectly reasonable. Why redundant keyword where it is not needed?

Second, I'd recommend against static members in C++. Before everybody jumps, I will try to explain.

Well, you are not going to have any public static data members (very rarely useful). In any case, most classes have their own CPP file. If so, a static global, IMO is preferable over a private static member for reasons of dependency reduction. Unlike non-static private data, the static ones are not part of the interface, and there's very little reason why should the user of the h file ever have to recompile, or at all see these members.