Declaring variables

[Flashmatix]

Hi everyone!

I started Java 2 weeks ago, I used to do C++.

In the code:

private void imageLabelMouseEntered(java.awt.event.MouseEvent evt) {
int times = 0;
System.out.println("Entered " + ++times + " times");
}

every time it calls this method times gets set back to 0. This is where it gets initialized, but shouldn't it then be set to 0 only once as in C++? I want it to be a local variable.

Thanks

Theo

[Norm]

I want it to be a local variable.

What do you mean by local?
It looks like you want its value to be preserved over calls to a method. If its local to a method, then it is created and initialized each time the method is entered.
If you move the definition and init of the variable outside the method, it won't be created new each time the method is entered.

[Eranga]

I hope he's talking about a global(may be a static) variable Norm. May be confusing with local and global(variable scopes) ;)

@Flashmatix, using a local variable you can't do it. As Norm explain you have to define outside of the method. Then it initialized only one time.

int times = 0;

private void imageLabelMouseEntered(java.awt.event.MouseEvent evt) {
     System.out.println("Entered " + (++times) + " times");
}

[udayadas]

Hi,

I have been working as a trainer from last couple of years.I have seen people complaing over this issue, especially who have migrated from C++ background...

The story is...C++ has the way to preserve the value of any local variable even the cotnrol goes out of scope.But that is not the case with Java.

In case of Java, when ever the program controls enters a method, a new stack-baloon is created to hold the local variables.The baloon remains alive as long as the control is in the method scope.Once you leave the method...the baloon busts...and all values are lost.

If you want to keep the values alive then such variables should not be declared local..rather make it global.

[Norm]

C++ has the way to preserve the value of any local variable

Could you give us a code example of this please?
This seems to violate the definition of local. Or what is the definition of local for C++? Would it work like a global variable(ie holds value across method calls) but is only be available to a single method? Other methods can't see it.

[fishtoprecords]

The story is...C++ has the way to preserve the value of any local variable even the cotnrol goes out of scope.

Its been nearly 15 years since I did professional C++, so my memory is fuzzy. But your description sure sounds like a recipe for a memory leak to me.

[udayadas]

I am not giving u the code,instead follow the link..it will be more clear..

h t t p : // en.wikipedia.org/wiki/Local_variable

[Norm]

I took a C++ course years ago and have forgotten it all. I looked it up and found:

static int times = 0;

Local in scope but long living over calls to a method

[Eranga]

Could you give us a code example of this please?
This seems to violate the definition of local. Or what is the definition of local for C++? Would it work like a global variable(ie holds value across method calls) but is only be available to a single method? Other methods can't see it.

Yes Norm, I'm really confusing with that comment. As you said it's violate the local variable definition.

I've little experience about C++. In call-by-reference it's possible to modify locals outside of the scope. Other than that I never heard about the visibility outside of the scope, of the locals. In that case, it really should cause for a memory leak, and that is the devil in C++

[udayadas]

I am not mush of a C/C++ person ..still I found something that might be of your intrest..

static variables declared inside a block are local to that block, similarly to auto variables. The following function uses the local static variable calls to track the number of its invocations:

int count_calls()
{
static int calls=0; //local static
return ++calls;
}

Unlike auto variables, local statics aren't destroyed upon leaving their function; they remain in existence until the program terminates. As such, they provide private and permanent storage for a function. When that function is invoked again, it will access the same calls variable.

How does this feat work? static objects aren't allocated on the stack, but on a permanent storage section that remains active throughout the program's execution. Implementations usually allocate a special block in each .exe file for objects that remain in existence as long as the program is running. Namespace-scope objects (e.g. globals) and local statics are stored in this block. If you have the address of calls, you can manipulate it even when the name calls is not in scope:

int count_calls(int *& rpi)
{
static int calls=0;
rpi=&calls;
return ++calls;
}
int main()
{
int *pi;
int n=count_calls(pi);
cout <<n<<endl; //output 1
*pi=5; //modify calls, although it's not in scope
n=count_calls(pi);
cout <<n<<endl; //output 6
}

This property of static objects can lead to race conditions in multithreaded apps, e.g. when one thread is assigning a new value to a static variable while another thread is reading its value. The solution is to use synchronization objects that selectively grant access to static variables.

[Flashmatix]

Thanks for the replies! In C++ the variable does not get created and initialized the second time you call a function, only the first time, and remains local to that function until you destruct it. I think they call it dynamic variable declaration or something along those lines. But as I gather Java does not support this.

Thanks

Theo

[Eranga]

Thanks for the replies! In C++ the variable does not get created and initialized the second time you call a function, only the first time, and remains local to that function until you destruct it. I think they call it dynamic variable declaration or something along those lines. But as I gather Java does not support this.

Thanks

Theo

This is a new thing I've heard. May be I've use it in C++, but not sure. I never work on industrial level applications using C++. Thanks for the infor.

[Flashmatix]

Yep, Java does not support this, sigh....