views:

104

answers:

2

Hi,

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 -- i.e. 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...

+2  A: 

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.

Hans Passant
Technically, you can put it in the .h-file as long as the file is not included in more than one compilation unit. :)
grddev
Not much point in putting it in a .h file then.
Hans Passant
On the other hand, it is OK to have multiple definitions of a template (or an inline function?) and have the linker pick one...
UncleBens
@UncleBens: C++ is never consistent. That's part of its charm.
Mike Seymour
+1  A: 

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.

Pavel Radzivilovsky
You probably want `s/static global/variable in the anonymous namespace/`. Those cause less problems with templates (they have unique external linkage; static globals have no external linkage).
MSalters