Static member in a class

[stonny]

I read the following sentence from a c++ website, but can not
understand why. can anyone help me with it?

"
An important detail to keep in mind when debugging or implementing a
program using a static class member is that you cannot initialize the
static class member inside of the class. In fact, if you decide to put
your code in a header file, you cannot even initialize the static
variable inside of the header file; do it in a .cpp file instead.

"

 

[Victor Bazarov]

I read the following sentence from a c++ website, but can not
understand why. can anyone help me with it?

"
An important detail to keep in mind when debugging or implementing a
program using a static class member is that you cannot initialize the
static class member inside of the class. In fact, if you decide to put
your code in a header file, you cannot even initialize the static
variable inside of the header file; do it in a .cpp file instead.

"

The Standard requires that every static data member is defined at the
namespace level. In order to comply with the One Definition rule, you
are more likely to succeed if you place the definition of the static
data member in a .cpp file (instead of a header which can be included
in more than one translation unit). Initialisation accompanies the
definition. That's why you should initialise static data members in
a .cpp file (and only in one .cpp file).

V

 

[Alf P. Steinbach]

* Victor Bazarov:

The Standard requires that every static data member is defined at the
namespace level. In order to comply with the One Definition rule, you
are more likely to succeed if you place the definition of the static
data member in a .cpp file (instead of a header which can be included
in more than one translation unit). Initialisation accompanies the
definition. That's why you should initialise static data members in
a .cpp file (and only in one .cpp file).

Initialization accompanies definition of a constant except in the case
when a declaration of a static constant in a class supplies the
initializer, in which case the definition (if any, and then outside the
class) is sans initializer.

Example:

struct S
{
static int const x = 42; // Not a definition, per §9.4.2/2.
};

If the address of S::x is used, or in the standard's terminology, if
S::x is "used", a definition is formally (but with current compilers not
necessarily in practice) required, outside the class:

int const S::x; // A definition, per §9.4.2/4.

Not directed at you, but at other readers: this construct is only
supported for integral types and/including enum types.

Directed at whoever thought up this crazy scheme: ugh.

 

[James Kanze]

I read the following sentence from a c++ website, but can not
understand why. can anyone help me with it?

"
An important detail to keep in mind when debugging or implementing a
program using a static class member is that you cannot initialize the
static class member inside of the class. In fact, if you decide to put
your code in a header file, you cannot even initialize the static
variable inside of the header file; do it in a .cpp file instead.

"

Static class data members aren't members of any particular class
instance. Unlike the other members of the class, the
declaration in the class is not a definition, so you need a
definition elsewhere.

 

[Phil Hobbs]

The Standard requires that every static data member is defined at the
namespace level. In order to comply with the One Definition rule, you
are more likely to succeed if you place the definition of the static
data member in a .cpp file (instead of a header which can be included
in more than one translation unit). Initialisation accompanies the
definition. That's why you should initialise static data members in
a .cpp file (and only in one .cpp file).

V

This is such a pain, I agree. Some years ago, I started doing this:

// foo.h

class Phew [

static int barre;

...
}

#ifdef COMPILING_MAIN
int Phew::barre;
#endif

// end foo.h

and insisting that all modules containing main() define COMPILING_MAIN.
That way, all the static members get defined exactly once, and their
definitions are right there with the class declaration. One could use a
different #define name if one were making lots of shared libraries, but
this trick makes it much easier to keep things straight.

Cheers,

Phil Hobbs

 

[James Kanze]

This is such a pain, I agree. Some years ago, I started doing this:

// foo.h

class Phew [
static int barre;
...
}

#ifdef COMPILING_MAIN
int Phew::barre;
#endif

// end foo.h

and insisting that all modules containing main() define COMPILING_MAIN.

And what happens if the module containing main() doesn't include
your header?

I'll admit that I don't see where it is such a big thing. I'll
just define the variable in whatever file I define the
constructor in.

That way, all the static members get defined exactly once, and their
definitions are right there with the class declaration.

But why do you want the definitions right there with the class
definition. You don't require that for functions; why is it a
problem to define static variables in a separate source file,
but not functions.

 

[Phil Hobbs]

This is such a pain, I agree. Some years ago, I started doing this:

// foo.h

class Phew [
static int barre;
...
}

#ifdef COMPILING_MAIN
int Phew::barre;
#endif

// end foo.h

and insisting that all modules containing main() define COMPILING_MAIN.

And what happens if the module containing main() doesn't include
your header?

I'll admit that I don't see where it is such a big thing. I'll
just define the variable in whatever file I define the
constructor in.

That way, all the static members get defined exactly once, and their
definitions are right there with the class declaration.

But why do you want the definitions right there with the class
definition. You don't require that for functions; why is it a
problem to define static variables in a separate source file,
but not functions.

--
James Kanze (GABI Software) email:[email protected]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

It's normally considerably easier to have the module containing main
include all the headers with static members. That's an easy rule to
remember.

Cheers,

Phil Hobbs

 

[Ian Collins]

*Please* don't quote signatures.

It's normally considerably easier to have the module containing main
include all the headers with static members. That's an easy rule to
remember.

What about static members of private classes in libraries? How would
you know (or even be able to) include the library's headers? What about
static member functions?

As James said, it's much easier to define them in the same module as the
class definition. After all, static members are no less members of the
class than its member function.

 

[James Kanze]

It's normally considerably easier to have the module containing main
include all the headers with static members. That's an easy rule to
remember.

And how is the author of the module containing main supposed to
even know which headers exist with static members?

 

[Victor Bazarov]

*Please* don't quote signatures.

James' signature is not up to requirements. The two dashes _must_
be followed by a space to make the proper signature delimiter. So,

[..]

V

 

[Default User]

James' signature is not up to requirements. The two dashes must
be followed by a space to make the proper signature delimiter. So,
formally it's not a signature. <g>

Yeah, some of mentioned it to him before. I know he's using Google
Groups, and initially I thought that it might be eating the extra
space, but he said not and fixed it for a while, but soon was back to
the broken form. I don't know what the deal is.




Brian