static data member

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.

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

"gs" <gs.alcatel@gmail.comwrote in message
news:4ae0472f-e87c-4825-b776-fff630850cce@s19g2000prg.googlegroups.com...

Quote:

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.

gs wrote:

Quote:

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.

On Nov 18, 6:18 am, Ron Natalie <r...@spamcop.netwrote:

Quote:

gs wrote:

Quote:

Hi,

>

Quote:

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).

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.

--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia

On Nov 18, 10:24 pm, James Kanze <james.ka...@gmail.comwrote:

Quote:

On Nov 17, 8:52 pm, Craig Scott <audiofana...@gmail.comwrote:

Quote:

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.

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).

--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia

On Nov 18, 8:28 pm, Craig Scott <audiofana...@gmail.comwrote:

Quote:

On Nov 18, 10:24 pm, James Kanze <james.ka...@gmail.comwrote:

Quote:

On Nov 17, 8:52 pm, Craig Scott <audiofana...@gmail.comwrote:

Quote:

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.

Quote:

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).

Quote:

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.

Quote:

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).

Quote:

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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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

On Nov 20, 12:46 am, "Alf P. Steinbach" <al...@start.nowrote:

Quote:

* Craig Scott:

[...]

Quote:

I'm wondering then what 6.7/4 means:

Quote:

"... 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... "

Quote:

"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.

Quote:

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<doublez( 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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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

static data member

re: static data member

re: static data member

re: static data member

re: static data member

re: static data member

re: static data member

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about