When is a static data member defined?

[Ioannis Vranos]

Here's just something to think about:

[...]


Here is an interesting side effect:



#include <iostream>

class C {
int v;
public:

C(const int& v = 0)
:v(v)
{}

static const C c;
};

const C C::c = 1066;

int main()
{
using std::cout;
using std::endl;

C obj;

cout<<&obj.c<<endl;

cout<<&obj.c.c<<endl;

cout<<&obj.c.c.c<<endl;

}


All c here are the same static object. Interesting.

 

[Chris Johnson]

After examining the object files emitted by the compiler for various builds,
I can see that if the static member is not used, it is not even present in
the object file containing the entry point.

Since I am not a language lawyer I am positive I will be corrected
promptly. Since C++ implementations are allowed to defer the
contructions of objects defined in a given translation unit until the
first use of any object or function defined in the translation unit it
would not suprise me at all if a compiler 'optimized' it away in this
circumstance. I do not know the "legal" wording of it but I believe it
is referred to as lazy evaluation and in spirit of the Golden Rule of C++
- you don't pay for something you don't use. That could be speed, size,
etc.

I do not know if this is technically correct as 'bible' though, just my
simple understanding.

 

[Victor Bazarov]

Victor Bazarov wrote:




We aren't talking about a function. IIRC, a function in C++ is specifically
_not_ an object in any sense of the word.

Function is not an object. However, just like any other non-temporary
object, every [ordinary] function is designated by a name. When
a non-const object is declared in the namespace scope, its name has
external linkage, just like a function (unless otherwise specified).
That means they have some kind of symbol by which they are recognised
from another module (or translation unit).

If used anywhere, a symbol (name) has to be _defined_ exactly once (the
One Definition Rule) to make a well-formed program. If _not_ used
anywhere, a symbol does NOT have to be defined. See 3.2/3.

I'm not really doubting that the
memory is allocated when the definition is compiled. I'm just wondering
how how the pieces are put together. In view of the fact that the point of
definition of a static member object of class type is where a constructor
will be invoked, it makes sense that it will be physically allocated when
that definition's object code representation is loaded.

After examining the object files emitted by the compiler for various builds,
I can see that if the static member is not used, it is not even present in
the object file containing the entry point.

Well, you're closer to understanding how this works, I trust. I am not
sure how we can help you further without going into the implementation
details. Perhaps if you find a book on compilers and linkers or talk to
people in a newsgroup for a particular implementation of the language,
you might learn more about that particular implementation or about how
to implement a language in general.

An example of something that is very common yet not considered part of the
language definition: virtual function mechanism implementation. On all
implementations I know it is done using a so called 'virtual function
table', a list of addresses of class functions is stored somewhere in
memory and a pointer to that table get stored in every object of that
class at the time of construction. Short name for that pointer/pointers
is 'vtbl'. Yet there is no mention of it in the Standard. Why? Because
it is considered an implementation detail. See why I am reluctant to go
into linking and how it works or should work?

V

 

[Steven T. Hatton]

Victor Bazarov wrote:




We aren't talking about a function. IIRC, a function in C++ is
specifically _not_ an object in any sense of the word.

Function is not an object. However, just like any other non-temporary
object, every [ordinary] function is designated by a name. When
a non-const object is declared in the namespace scope, its name has
external linkage, just like a function (unless otherwise specified).
That means they have some kind of symbol by which they are recognised
from another module (or translation unit).

If used anywhere, a symbol (name) has to be _defined_ exactly once (the
One Definition Rule) to make a well-formed program. If _not_ used
anywhere, a symbol does NOT have to be defined. See 3.2/3.

I'm not really doubting that the
memory is allocated when the definition is compiled. I'm just wondering
how how the pieces are put together. In view of the fact that the point
of definition of a static member object of class type is where a
constructor will be invoked, it makes sense that it will be physically
allocated when that definition's object code representation is loaded.

After examining the object files emitted by the compiler for various
builds, I can see that if the static member is not used, it is not even
present in the object file containing the entry point.

Well, you're closer to understanding how this works, I trust. I am not
sure how we can help you further without going into the implementation
details. Perhaps if you find a book on compilers and linkers or talk to
people in a newsgroup for a particular implementation of the language,
you might learn more about that particular implementation or about how
to implement a language in general.

An example of something that is very common yet not considered part of the
language definition: virtual function mechanism implementation. On all
implementations I know it is done using a so called 'virtual function
table', a list of addresses of class functions is stored somewhere in
memory and a pointer to that table get stored in every object of that
class at the time of construction. Short name for that pointer/pointers
is 'vtbl'. Yet there is no mention of it in the Standard. Why? Because
it is considered an implementation detail. See why I am reluctant to go
into linking and how it works or should work?

V

The virtual function table is discussed extensively in the TC++PL(SE). The
idea that it is not topical here is absurd.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Victor Bazarov]

[...]
The virtual function table is discussed extensively in the TC++PL(SE). The
idea that it is not topical here is absurd.

I totally agree. Can you tell me who said it wasn't topical here (besides
you, that is)?