Why initialization of static member is a must?

[meili100]

Here is a simple example:

struct E{
public:
	static int c;
	E() {c++;}
	~E(){c--;}
};

//int E::c=0;
int main(){
	E e;
	return 0;
}

We can see if we declare c as "int c" rather than "static int c", it can compile. When c is declared as "static int c", it can't compile without "int E::c=0;". Why is that?

[brewbuck]

Because the declaration "static int c" just says that somewhere else, there shall be a definition of E::c. It does not cause the definition by itself.

[meili100]

Then why int c works? Why complier does not force it to be defined?

[tabstop]

int c; means that each instance of class E has a variable named c (which it is then up to the constructor, presumably, to deal with). static int c; means that there is a variable which belongs to the class as a whole, and must therefore be defined once, somewhere, for the class.

[KIBO]

because static class members are shared over all classes and they may only have 1 instance in the entire program. Its up to the programmer where to define this variable.
"normal" member variables get a new instance whenever an object of the class is created

[CornedBee]

The initialization is not necessary, though, only the definition is. In other words
int E::c;
is enough (and c will still be 0).

[cpjust]

Is there a reason why the compiler can't do that itself without you explicitly declaring it (other than if you want it initialized to something other than default)?

[matsp]

Yes, the reason is that the compiler can't really know WHERE to place this "autogenerated" variable. Note that:

int x;
int E::c;
int y;

will ensure that x and y are either side of E::c in memory.

Since it's essentially a global variable, you may want to put it somewhere it makes sense to sit [e.g. together with other variables that are used together with it, for caching benefits]

--
Mats

[brewbuck]

Then why int c works? Why complier does not force it to be defined?

Because each object contains its own non-static variable, there is no logical place where such a definition could be placed. Therefore, for non-static members, the declaration serves as the definition for all instances.

[grumpy]

Note that:

int x;
int E::c;
int y;

will ensure that x and y are either side of E::c in memory.

Not true. Order or location of declarations of variables does not control where they are physically placed in memory. Some compilers might elect to do such things, but there is no guarantee they will.

To answer the original question, declarations of non-static members of a class are actually a definition (so, whenever an instance of the class is created, its non-static members are). For static members of a class, the declaration within the class body is not a definition. ie in your example, "static int c;" is the declaration and "int E::c = 0;" is the definition.

Why is all this tap-dancing necessary? Given two (or more) source files in which the compiler sees

struct E{
public:
	static int c;
};

the compiler and linker, as a pair, could theoretically infer that one definition of E::c is needed and resolve any usage of that static member in those multiple source files so, in effect, E::c is defined exactly once.

The problem is, with separate compilation of source files, the compiler cannot resolve such things in isolation -- such resolutions require examination of all the source files as a set. The typical dumb linker (the program that links object files and libraries together to create an executable entity, which is what is supplied with most operating systems and/or development environments) also tends to choke if more than one definition occurs across multiple object files and libraries. The common practical situation, therefore, is a compiler that can't resolve the concern without help and a dumb linker that won't help it. That puts the onus back onto the programmer to explicitly resolve the issue and ensure only one definition occurs across all source files. This sort of thing is the basis for the "One Definition Rule" (ODR) in the standard. [There's more justification for the ODR than that, but that's the basic idea.]

Smarter linkers (that do analysis across multiple object files to resolve situations of multiple definitions and other phenomena) do exist, but they are rare. With a smarter linker the definition "int E::c;" would actually be optional.

The net effect of all that is that the standard must allow for the full range of practical situations, and a common practical situation involves usage of dumb linkers. So, practically;
1) "static int c;" within struct E is treated by typical compilers as a declaration (the standard treats it that way too);
2) the subsequent "int E::c;" is treated as a definition.
3) the linker must see exactly one definition (otherwise it will emit an error message about multiply definitions)