That depends on what you do with it. If you don't give the address of the static data member, no one is going to change it. Static data members are shared between all instances of a class, and thus they are not part of any specific instance of the class.

Example:


#include &ltiostream>

struct point
{
point() { ++instances; }
point(int x, int y) : x(x), y(y) { ++instances; }
~point() { --instances; }

int x, y;

private:
static int instances;
}

// It's kind of like a global, there's only one copy, and
// it must also be declared outside the class.
int point::instances = 0;

int main()
{
point p[256];
assert( p[0].instances == p[172].instances ); // always succeeds
assert( point::instances == point::instances ); // same thing

std::cout << point::instances; // 256, because we're using 256 points

return 0;
}



This is just one use of a static data member, which uses the constructors and a shared variable to track the number of points currently in use.

Another way of looking at it is that static data members and static member functions are just like global data members and global member functions, except of course that they need the class name (not an object!). Note that static member functions cannot access the data of any specific instance of that class, unless you explicitly pass the instance to the static function.

This limitation is great, and it can be used for callback functions to work with legacy C code, among other things.


Edited by - null_pointer on March 21, 2001 2:31:27 PM

"legacy" ??

Hmm.... The final nail has not yet been driven into C callbacks, that it hasn''t. Besides many still use C.

GayleSaver:

I made a slight mistake. The phrase I should have used was "legacy C-like C++ code". The difference is that I do not mean that the C language is dead, simply that some bad habits common in C++ as carry-overs from C are deprecated in C++.

Legacy is the adjective I use to describe older, slower code techniques, especially those which cause problems when you try to mix them with C++ features. Look up C''s qsort, note the use of a callback, and then look up C++''s std::sort and note the use of a function object. Function objects can be inlined, callbacks cannot. In addition, C++ contains function objects for most numerical operators, which fits in quite well with templates, default template arguments, and operator overloading. It also happens to work nicely for function overloading, allowing me to sort a standard container such as list with no more code than a C-style array, using a version specialized for each standard container.

Note the differences in the argument lists for qsort and std::sort - std::sort takes either two or three parameters. The first two point to the beginning and one past the end of the sequence (which can pointers, or types that act like pointers such as iterators). The third parameter "defaults" to using the less-than operator, which can also be defined for user-defined types.

By contrast, qsort takes four parameters, even in the simplest and most common cases. The first one indicates the beginning of the sequence, which must be a pointer to an array. The second parameter tells how many elements are in the array. The third parameters tells how large each element is. Note that qsort can''t deduce the size of the type in simpler cases, such as sorting an array of intrinsic types. Unfortunately, this isn''t merely a simple matter of notational convenience - since the size of the type isn''t known until run-time, the compiler can''t optimize qsort as well. The fourth parameter is a function callback that acts as a predicate. Note that you must define a function callback, even if you are only using the intrinsic types.

Thus certain C++ language features give std::sort the decided advantage in speed and notational convenience, without sacrificing its generic usage. In fact, std::sort is even more generic than qsort.

I have to go now, I apologize for any mistakes.