C keyword static

[Celicu]

Ok, I understand how to use this keyword. What I'm interested in is how it is actually accomplished. Let's say you have a static variable declared in a function. That variable is created on the stack. When the variable leaves scope (function returns), the variable needs to get popped off the stack. Where does its value get stored? Does the compiler automatically allocate some memory on the heap for it? It has to get stored somewhere, because when the function is called again and the variable is in scope, it gets put back on the stack with its previous value, right?

 

[MonkeyShave]

I'm not a compiler writer, but if somebody asked me to implement static function variables in C, I'd use a global variable. Implementations use the stack for auto variables only because it provides convenience (it maps directly onto C's variable scoping rules for auto variables). C's static function variables share many characteristics with global variables, however, so I'd implement them in a similar fashion. I would alter (decorate) the name of the static variable to prevent use from outside of the declaring function, but that's pretty easy to do (global static definitions in C often use decorated names as well to prevent the linker from using those declarations).

 

[bassman]

AFAIK, local static variables are usually in the runtime data segment, not on the heap or the stack.

 

[mikeblas]

No need to decorate, MonkeyShave. The static symbol is just private and not given to the linker as an externally accessible symbol.

Function-local statics have some interesting problems; often, they should be declared const and aren't, and really suck down performance. Or, they should be thread-local instead of function-local.

 

[Celicu]

Interesting, thanks for the responses!

 

[ameoba]

gcc -s
?

 

[nameless_centurian]

if i may hijack a thread, which yall can ignore me if you disapprove...


how does a computer allocate space for variables at run-time?

if i do

pointer ==> some 32 bit integer, how is this accomplished at run-time? you can't exactly use a label.

 

[Xipher]

something called the heap and the OS

and don't forget, the addresses in your program aren't physical, but virtual.

 

[nameless_centurian]

something called the heap and the OS

and don't forget, the addresses in your program aren't physical, but virtual.

i'll look into that, thanks!

 

[mikeblas]

if i may hijack a thread, which yall can ignore me if you disapprove...

Most people prefer that you create a different thread. Your question will be seen by more people, and once answered, it'll be easier for other people searching to find the answer. There's a method to the madness.

how does a computer allocate space for variables at run-time?

It depends on a few things: the type of variable, the storage class of the variable (and therefore the language the variable was declare in), and the implementation of the compiler, and the operating environment.

In C or C++, I can't think of any storage class that causes a variable to be allocated on the heap. operator new will get memory and construct objects, but most people don't call that "allocating a variable".

if i do

pointer ==> some 32 bit integer, how is this accomplished at run-time? you can't exactly use a label.

I don't know what you're doing; there is no "==>" operator in C or C++. Which language are you using?

If you mean this:

	int n;
	int* p = &n;

then the above answer applies: the allocation for both p and n depends on where the declarations were and what storage class specifiers you've used.

That addresses a programmer sees are virtual and not physical are pretty much irrelevant, unless you're writing a device driver or working in a priveleged execution ring on your own OS.

 

[RancidWAnnaRIot]

AFAIK, local static variables are usually in the runtime data segment, not on the heap or the stack.

i believe this is correct..

 

[nameless_centurian]

Most people prefer that you create a different thread. Your question will be seen by more people, and once answered, it'll be easier for other people searching to find the answer. There's a method to the madness.



It depends on a few things: the type of variable, the storage class of the variable (and therefore the language the variable was declare in), and the implementation of the compiler, and the operating environment.

In C or C++, I can't think of any storage class that causes a variable to be allocated on the heap. operator new will get memory and construct objects, but most people don't call that "allocating a variable".


I don't know what you're doing; there is no "==>" operator in C or C++. Which language are you using?

If you mean this:

	int n;
	int* p = &n;

then the above answer applies: the allocation for both p and n depends on where the declarations were and what storage class specifiers you've used.

That addresses a programmer sees are virtual and not physical are pretty much irrelevant, unless you're writing a device driver or working in a priveleged execution ring on your own OS.

the ==> was my attempt to say "pointing to." many apologies.

so if i do this

int *cow=new int;

how is this accomplished? i've been told it was done at run-time. i realize i should have clarified this earlier, but i am not that great at communication my thoughts at times.... but i am speaking of dynamic memory.

how is dynamic memory allocated at run-time?

thanks for your patience, mikeblas.

 

[generelz]

the ==> was my attempt to say "pointing to." many apologies.

so if i do this

int *cow=new int;

how is this accomplished? i've been told it was done at run-time. i realize i should have clarified this earlier, but i am not that great at communication my thoughts at times.... but i am speaking of dynamic memory.

how is dynamic memory allocated at run-time?

thanks for your patience, mikeblas.

mikeblas said:

operator new will get memory and construct objects, but most people don't call that "allocating a variable".

The new operator generally allocates objects on the heap. so the varaible cow will be a 32 bit memory address ON THE STACK in the stack frame of whatever context (function, etc.) that you're in, however the memory at that (virtual) address that is read when the pointer is dereferenced is stored in your application's heap space.

 

[mikeblas]

int *cow=new int;

how is this accomplished? i've been told it was done at run-time. i realize i should have clarified this earlier, but i am not that great at communication my thoughts at times.... but i am speaking of dynamic memory.

how is dynamic memory allocated at run-time?

thanks for your patience, mikeblas.

cow isn't dynamic. If it's local to a function, it's allocated by the compiler on the stack when your program runs. If it's global, it's in the data section of your executable image; it's either a spot in the file that gets mapped into memory, or a note in a file that the OS satisfies as your program loads.

cow is a variable, but you're not allocating it at runtime.

The right hand side of the expression happens at run-time. It isn't allocating a variable; it's dynamically creating an object.

For the right-hand side, the compiler calls operator new, which is just a special function, and asks it for a single integer object. operator new either calls the operating system and asks for memory, or calls malloc() and asks it for memory -- and it eventually asks the operating system for memory.

The implementation of operator new() and malloc() can vary widely. Maybe there's three groups of implementations:

1) For operating systems that have robust, flexible, and efficient memory managers (like modern versions of Windows) the implementation probably turns around and asks the OS for the variable, directly.

2) For operating systems that don't have such great memory allocators (like older versions of Windows), maybe the implementation gets a giant amount of memory from the OS in one call and hangs onto it... then, sub-allocates that memory as more calls come in. If malloc() is asked for 16 bytes, it chops it out of a block that's 64K that it got before. If that 64K is depleted by a bunch of calls, another large block is obtained. If a request comes for something larger than 64K, then it just turns around and asks the OS for that size directly.

3) For embedded systems, the OS might not play a role; maybe the available memory is just there, and the application just chops it up as it sees fit. This is called an "arena alloctor" or a "slab allocator". Some embedded sysetms don't allocate memory dynamically at all in order to avoid memory leaks altogether.

Memory allocators are interesting to study; there's many different ways to skin the cat, all with different characteristics.

"pointing to" could come about many different ways, not only operator new. Here's a demonstration of some of those ways:

#include <malloc.h>
#include <new>

int x;

void fooey()
{
	int* cow;

	// from the heap, probably
	cow = new int;

	// from a specific location we know:
	cow = (int*) 12345;

	// placement new syntax
	cow = new((void*) 12345) int();

	// from our image
	cow = &x;

	// from the stack, statically:
	static int r;
	cow = &r;

	// from the stack, dynamically;
	cow = (int*) _alloca(sizeof(int));
}

 

[mikeblas]

The new operator generally allocates objects on the heap. so the varaible cow will be a 32 bit memory address ON THE STACK in the stack frame of whatever context (function, etc.) that you're in, however the memory at that (virtual) address that is read when the pointer is dereferenced is stored in your application's heap space.

Not precisely.

cow may or may not be on the stack. If it's local to a function, it's on the stack unless the compiler decided to enregister it (or eliminate it completely!) as an optimization. If it's global, it's stored in the program's image, or fluffed-up out of the program's image at load time. If it's a member of a class or structure, it was allocated in whatever way the containing structure was allocated.

The address that cow holds probably does come from the heap, given the way operator new is usually implemented, yes.

&cow and cow are both virtual addresses, if you've got an OS that supports VM -- but I don't see how that's relevant.