Where are the static members stored in the momory?

[VJ]

Hi,
I apologize if this question has been asked many times on the group!

I am new to programming,
I know that there are three section in address space- one for code, one
for stack, and the third for Heap.

I just want to know how and where static members are stored in the
address space given to particular program. Is this different from the
way it is done in C?

Thanks in advance,

 

[Victor Bazarov]

I apologize if this question has been asked many times on the group!

It hasn't, AFAIK. Not many times, anyway.

I am new to programming,
I know that there are three section in address space- one for code, one
for stack, and the third for Heap.

You know that? From where? I heard those things, but then I hears also
that there exists "constant data section" and other stuff unrelated to
the subject of this newsgroup.

I just want to know how and where static members are stored in the
address space given to particular program. Is this different from the
way it is done in C?

It's probably not different [much], but it's simply unspecified where
the static data members are stored. Essentially, in the same space where
all static data resides, I believe. But what I believe is immaterial,
since it's in fact unspecified.

V

 

[Samee Zahur]

I just want to know how and where static members are stored in the

address space given to particular program.

AFAIK the standard doesn't specifiy anything about it, so any
compiler/platform can do anything as long as it functions right. But
usually, they go into the heap - somewhere everyone can 'see' it.

Samee

 

[sam]

AFAIK the standard doesn't specifiy anything about it, so any
compiler/platform can do anything as long as it functions right. But
usually, they go into the heap - somewhere everyone can 'see' it.

Do you meant all functions/variables goes to the heaps should be able to
be called by other classes/functions of the application?
What about private members? where they stored in the system?

Sam.

 

[Victor Bazarov]

Do you meant all functions/variables goes to the heaps should be able to
be called by other classes/functions of the application?
What about private members? where they stored in the system?

Where what is stored is *not specified*. You may stop asking about it
now.

'private' specifier only works during compile time. If you manage to gain
access to it during run-time, you should be able to see the value just
like for any other object, private or not. Access specifiers exist to
protect from programming errors, not from malicious hacking activity.

V

 

[Thomas Matthews]

Hi,
I apologize if this question has been asked many times on the group!

I am new to programming,
I know that there are three section in address space- one for code, one
for stack, and the third for Heap.

I just want to know how and where static members are stored in the
address space given to particular program. Is this different from the
way it is done in C?

Thanks in advance,

Next time, try searching the newsgroup and the FAQ first.
I have answered this and other similar questions many times.

The only requirement for static member variables is that
they are stored in memory that has read and write access.
The memory could be on your computer, a harddrive, a
tape drive or a flash memory device, to name a few.

The compiler must ensure that a static member variable
has all the protection and accessibility rights according
to the standard. The standard does not tell _how_ to
do this.

The only time I really care where a variable is stored
is when I am working on an embedded system. I don't
want non-constant variables stored in ROM. I also
have to make sure that there is enough memory for
all of the variables, including temporary ones
(ones with short duration).

If the compiler wants to use stacks, heaps, linked
lists or other structures, it can. I don't care.
I'm more interested in making my program work
correctly than where the compiler places variables.

If my program is not working correctly, there is
no use bothering with optimization or worring about
where the compiler places the variables. [1]

----
1. There have been times when a piece of hardware
was stomping on the variables or when the variables
needed to be aligned and weren't. This is when
I need to know where the variable is stored.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[himanshu]

hi everyone i`m a first timer on groups.
from what i`ve infered your statement that "static data can be stored
on the stack" does not fit.
static data area is the place where the computer stores the static data
where its values are to remain the same for the different instances of
the variable.another thing ; the static datamembers of the class are to
be initialized during the compilation time the same area also stores
the initialized global data also.
static data members also have fixed memory address once the program has
been loaded into the memory.
One more thing if we could store the data in the stack then the basic
requirment that the static data should keep its value during function
calls would fail during recursive function calls where the stack
pointer will be moved down by the function and it will over-ride the
previous value.

 

[sam]

Next time, try searching the newsgroup and the FAQ first.
I have answered this and other similar questions many times.

The only requirement for static member variables is that
they are stored in memory that has read and write access.
The memory could be on your computer, a harddrive, a
tape drive or a flash memory device, to name a few.

The compiler must ensure that a static member variable
has all the protection and accessibility rights according
to the standard. The standard does not tell _how_ to
do this.

The only time I really care where a variable is stored
is when I am working on an embedded system. I don't
want non-constant variables stored in ROM. I also
have to make sure that there is enough memory for
all of the variables, including temporary ones
(ones with short duration).

With embedded system, how can you make sure those non-const variables
are not writing to ROM? If there is RAM in the embedded system, aren't
all variables (including const and non-const) created in RAM by default?

Sam

If the compiler wants to use stacks, heaps, linked
lists or other structures, it can. I don't care.
I'm more interested in making my program work
correctly than where the compiler places variables.

If my program is not working correctly, there is
no use bothering with optimization or worring about
where the compiler places the variables. [1]

----
1. There have been times when a piece of hardware
was stomping on the variables or when the variables
needed to be aligned and weren't. This is when
I need to know where the variable is stored.

 

[msalters]

sam schreef:
th short duration).

With embedded system, how can you make sure those non-const variables

are not writing to ROM? If there is RAM in the embedded system, aren't
all variables (including const and non-const) created in RAM by

default?

AFAIK, no. AFter all, const variables must be initialized. i.e.
const int i; // no value yet
is illegal. There's always an initial value, e.g. 42. Now, this must
obviously be stored in the ROM of an embedded system, or else it will
be gone on powerloss (same as the code, must be in ROM too). Now, why
would you relocate the variable from ROM to RAM? There's nothing in
C++ that requires such a copy. (one exception: embedded systems with
separate memory spaces, in which ordinary pointers can't refer to ROM.
That's moee related to the CPU than C++, IMO )

Regards,
Michiel Salters

 

[msalters]

himanshu schreef:

from what i`ve infered your statement that "static data can be stored
on the stack" does not fit.
static data area is the place where the computer stores the static data
where its values are to remain the same for the different instances of
the variable.another thing ; the static datamembers of the class are to
be initialized during the compilation time the same area also stores
the initialized global data also.
static data members also have fixed memory address once the program has
been loaded into the memory.
One more thing if we could store the data in the stack then the basic
requirment that the static data should keep its value during function
calls would fail during recursive function calls where the stack
pointer will be moved down by the function and it will over-ride the
previous value.

So? Remember that 'stack' is just an common implementation, with a
number of variants. It's perfectly possible to add all globals to the
stack, before main() is called. That means they end up on the bottom
of the stack, below all other variables.

Your assumption about stack pointer movement is wrong, though. Yes,
if you call a function recursively, the same name will refer to
another object. However, all objects on the stack are still there:

void foo( int* ptr )
{
int i = 0;
if( p == 0 )
foo(&i);
}
int main() {
foo(0);
}
Now, when the stack contains main()-foo(0)-foo(0x...),
there are two copies of i. One can be accessed simply as 'i', the
other can be accessed as '*ptr'. The previous _value_ is not
"over-ridden". The _name_ for *ptr is simply out of scope.


Regards,
Michiel Salters

 

[sam]

sam schreef:
th short duration).


default?

AFAIK, no. AFter all, const variables must be initialized. i.e.
const int i; // no value yet
is illegal. There's always an initial value, e.g. 42. Now, this must
obviously be stored in the ROM of an embedded system, or else it will
be gone on powerloss (same as the code, must be in ROM too). Now, why
would you relocate the variable from ROM to RAM? There's nothing in
C++ that requires such a copy. (one exception: embedded systems with
separate memory spaces, in which ordinary pointers can't refer to ROM.
That's moee related to the CPU than C++, IMO )

Here may be a bit off topic, but since you seems have alot of
programming experience in embedded systems, I have further question here.
If I have a embedded system platform like Soekris or Portwell, how could
I instruct the CPU to load my system+application in ROM?

Thanks
Sam