static data member

[gs]

Hi,

I want to know that when memory get allocated to static data member of
a class.

class A
{

static int i;
}

int A::i=1;

main()
{
}

Here in this case when memory will get allocated to static member I
mean whether it will be at compile time or at run time after main get
called.

 

[Ron AF Greve]

Hi,

That will imediately take up memory in most (if not all systems) when the
program gets loaded (assuming it is not in a separate library).

Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

 

[Ron Natalie]

Hi,

I want to know that when memory get allocated to static data member of
a class.

Static storage is static. You can think of it always being there.

Perhaps the question you also want to know is when it gets initialized.
In this case, since it is of POD type and initialized with a constant
expression it also has static initialization, which pretty much means
that it's initialized before anything executes (including dynamic
initialization and well before main).

In common practice, static storage allocation and static initialization
is done as the program is loaded into memory for initial execution.

 

[Craig Scott]

Static storage is static. You can think of it always being there.

Perhaps the question you also want to know is when it gets initialized.
In this case, since it is of POD type and initialized with a constant
expression it also has static initialization, which pretty much means
that it's initialized before anything executes (including dynamic
initialization and well before main).

I have previously posted a fairly detailed summary of what the C++
standard says about when static objects are created/initialized, which
you can find at http://preview.tinyurl.com/2rsal2 . I'd be interested
if there are parts of the standard not mentioned in that post which
support your statement, particularly the "before anything executes"
and "well before main" comments. I think my original post does not
sufficiently address the situation of a POD type initialized with a
constant expression and I would like to fill in the gaps.

 

[James Kanze]

I have previously posted a fairly detailed summary of what the C++
standard says about when static objects are created/initialized, which
you can find athttp://preview.tinyurl.com/2rsal2. I'd be interested
if there are parts of the standard not mentioned in that post which
support your statement, particularly the "before anything executes"
and "well before main" comments.

You quote the relevant passage in your posting. Initialization
is in the order: zero initialization, static initialization
dynamic initialization. Note in particular the first sentence
of §3.6.2: "Objects with static storage duration (3.7.1) shall
be zero-initialized (8.5) before any other initialization takes
place." Before, for example, the argc and argv arguments to
main are initialized, as well as before any dynamic
initialization of static objects.

I think my original post does not sufficiently address the
situation of a POD type initialized with a constant expression
and I would like to fill in the gaps.

You're post really neglects reality. The constraints that the
standard imposes if dynamic initialization is deferred until
after main are impossible to meet, and no implementation tries.
(Dynamic linking may open up another can of worms, but what
happens then is implementation defined anyway---although most
systems behave identically here as well.) From a practical
point of view, it's safe to say: zero initialization, then
static initialization, then dynamic initialization, then main.
With the first occasion for your code to run being dynamic
initialization (which means that the zero initialization of
statically initialized objects isn't visible, and may be
skipped).

There's also, of course, the fact that many, many idioms depend
on dynamic initialization before main, and that any compiler
which tried to do otherwise simply wouldn't be used.

If you exclude dynamic linking, it's really fairly simple. If
you don't start any threads before entering main, that means
that threading issues aren't involved either.

 

[Craig Scott]

You're post really neglects reality. The constraints that the
standard imposes if dynamic initialization is deferred until
after main are impossible to meet, and no implementation tries.
(Dynamic linking may open up another can of worms, but what
happens then is implementation defined anyway---although most
systems behave identically here as well.) From a practical
point of view, it's safe to say: zero initialization, then
static initialization, then dynamic initialization, then main.
With the first occasion for your code to run being dynamic
initialization (which means that the zero initialization of
statically initialized objects isn't visible, and may be
skipped).

There's also, of course, the fact that many, many idioms depend
on dynamic initialization before main, and that any compiler
which tried to do otherwise simply wouldn't be used.

I assume you are excluding local static objects here, since it is easy
to verify that at least one very popular compiler delays
initialization of local statics until the first call of the function
in which it resides (as I expect most compilers probably do too).

 

[James Kanze]

I assume you are excluding local static objects here,

Obviously, since they do have a (somewhat) different lifetime.
According to the standard, the constructor may not be called
until the first time the object comes into scope (and should
never be called if the object never comes into scope).

since it is easy to verify that at least one very popular
compiler delays initialization of local statics until the
first call of the function in which it resides (as I expect
most compilers probably do too).

Given that it's required by the standard.

I should have been clearer: I was talking about the
initialization described in §3.6.2: Initialization of non-local
objects. But the standard seems to halfway merge the two: the
first sentence of this sections reads "Objects with static
storage duration (3.7.1) shall be zero-initialized (8.5) before
any other initialization takes place." No "non-local" about it.

In general: zero-initialization and constant initialization take
place for all objects with static lifetime, before any dynamic
initialization takes place. Then, in practice at least, dynamic
initialization of non-local, statically linked statics takes
place, and then main is called.

In the case of dynamic linking, the exact same procedure is
applied to the dynamically linked object (except that there is
no main to be called), before returning from whatever system
function loads the dynamic object. At least today.

 

[Craig Scott]

Obviously, since they do have a (somewhat) different lifetime.
According to the standard, the constructor may not be called
until the first time the object comes into scope (and should
never be called if the object never comes into scope).

I'm wondering then what 6.7/4 means:

"... An implementation is permitted to perform early initialization of
other local objects with static storage duration under the same
conditions that an implementation is permitted to statically
initialize an object with static storage duration in namespace
scope... "

This would seem to indicate that a compiler *is* free to call the
constructor before the function is called (at least under certain
circumstances), perhaps even if the function is never called at all.
I'm not aware of any compiler which does this, but I haven't gone
looking. I know that certain variations of the Singleton pattern
assume that a local static object is only ever constructed if the
function containing it is called (let's ignore the threading issues
for now), but I am wondering if this is a 100% guaranteed according to
the standard?

 

[Alf P. Steinbach]

* Craig Scott:

I'm wondering then what 6.7/4 means:

"... An implementation is permitted to perform early initialization of
other local objects with static storage duration under the same
conditions that an implementation is permitted to statically
initialize an object with static storage duration in namespace
scope... "

"under the same conditions", i think a check of the standard will show
that that means no side effects etc., that the object can be initialized
completely by a simple raw memory copy of data computed at compile time.

in effect, i think a check of the standard will show that the only such
early initializations are those that you cannot detect except by
measuring execution time or tracking the machine code execution.

cheers, & hth.,

- Alf

 

[James Kanze]

* Craig Scott:

[...]

"under the same conditions", i think a check of the standard
will show that that means no side effects etc., that the
object can be initialized completely by a simple raw memory
copy of data computed at compile time.

in effect, i think a check of the standard will show that the
only such early initializations are those that you cannot
detect except by measuring execution time or tracking the
machine code execution.

Yes. I'm not sure of the exact words (and I'm too lazy to look
them up now), but I'm pretty sure that the intent here is to
allow the compiler to use static initialization for things like
complex<double>; a fairly simple analysis of the constructor
allows it to determine the actual bit pattern, and determine
that there are no side effects.

Note that this optimization requires special authorization in
general case, since a conforming program can tell:

#include <complex>

extern int f() ;
int i = f() ;
std::complex<double> z( 1.2, 3.4 ) ;

int
f()
{
return static_cast< int >( z.real() ) ;
}

(Here, i will be initialized with 0 if z is dynamically
initialized, but with 1 if it is statically initialized.)

Off hand, I can't come up with a similar example involving local
statics, but I wouldn't swear that one doesn't exist, either.