local variables deleted by whome ?

[mangesh]

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

Regards
Mangesh .

[Scott McPhillips [MVP]]

mangesh wrote:

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

Regards
Mangesh .

In almost all machines local variables are stored in the machine's
stack. This is the same stack that stores the return address that a
function uses to return to its caller. The local variables are
"deleted" by changing the stack pointer. Both allocation and deletion
are highly efficient operations (almost zero overhead) performed by
assembly language and are closely related and part of the call/return
assembly language.

--
Scott McPhillips [VC++ MVP]

[benben]

mangesh wrote:

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

Regards
Mangesh .

Answer: the CPU.

Explanation:

1. Your compiler generates code that pops the stack frame.
2. Your OS loads your program (which obviously contains the code that
pops the stack frame)
3. When the execution goes out of scope, the CPU reads the instructions
that pops the stack frame and it does what it is told.

Regards,
Ben

[Puppet_Sock]

mangesh wrote:

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

Well, you've missed a candidate, and it's the one that does the
work. It's your program.

The compiler creates your program. The compiler is not necessarily
even loaded when your program runs. In fact, the compiler might not
be on the same machine. Hey, in theory, the compiler might have
been completely erased from all machines everywhere, not even a
backup existing, when your program runs. (Though I suppose that
does not happen all that often.)

The OS does not know about the variables in your program. Nor care.
It grabs your program out of storage and sticks it in the part of
memory that contains programs while they execute, then passes
control to your program. And that's just about it while your prog
is running. There may be some other services like disk access or
swapping and so on. But the OS does not know about variables.

For simple variables like ints, all your program does to delete the
variable is change the stack pointer so that the variable is no
longer in the part of the stack your program expects to be data.
For variables that are instances of a class with a destructor,
your program calls the dtor for that object before it changes
the stack pointer. All that goes on "behind the scenes" where
you don't have to pay attention to it. Thus such variables are
called "automatic variables." It is part of your program, in stuff
created by the compiler. But the work is done by your program.
Socks

[Mike Wahler]

"mangesh" <ma************@walla.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

It's deleted by code created by the compiler;
this code is part of your program.

-Mike

[Ron Natalie]

mangesh wrote:

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

Regards
Mangesh .

I would like to say that a's lifetime ends. Delete implies
that somehow the delete operator applied. As for what is
responsible for calling the destructor and deallocating the
storage, the language just says it's the "implementation" which
is the environment that the C++ program exists in.

In most cases the compiler emits code that in conjuction with
runtime libraries handles the deallocation.

[Salt_Peter]

"mangesh" <ma************@walla.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

consider following code :

void fun()
{
int a ;
//..do something
}

when function exit , a is said to be deleted . My confusion is who
deletes a , compiler or os . And if by os which part of os .

Regards
Mangesh .

fun() has a scope, just like any other function. Any object that is created
on the stack here has local scope and a strictly defined lifetime (governed
by the function's scope). Who deletes int a is the program since it invokes
the integer destructor when the function scope ends. What destroys the
integer is its own destructor - in this case: the d~tor in a
compiler-provided primitive type.

Why not create a class that displays it all for you:

#include <iostream>
#include <ostream>

class Temp
{
public:
Temp() { std::cout << "Temp()\n"; }
~Temp() { std::cout << "~Temp()\n"; }
};

void fun()
{
Temp fun_temp;
} // fun_temp's d~tor is invoked here

int main()
{
Temp main_temp;
fun();
} // main_temp d~tor is invoked here

Think of each function as a distinct stack. Terminating each function
unwinds its own stack.

Note: you don't call the d~tor(s), these get invoked as part of the stack
unwind. This happens naturally in C++ unless you stored the object(s) on the
heap.