Hello Lutz Vieweg,
The limitation below is still there. So, you'll find problem if you
declare nested block scope variable with same name.
f() {
int i;
{
double i; // this causes problem
}
}
If you use different name there is not problem.
f() {
int i;
{
double d; // this is fine
}
}
I could fix this but there are a couple of issues.
1) Convenience in interactive session
In interactive session, you use { [statements] } to give commands.
You do quite often
root[0] { TClass *p=new TClass(...); }
If cint is stringent about the block scope polisy, *p is destroyed
right at the closing '}'. So a user can't use *p in the consequitive
command line session. This is quite inconvenient. Maybe I need special
handling for the interactive session.
2) Speed
Doing strict block scoping will slow down the execution.
Change itself is mid difficulty.
I'm aware of the issue for a long time but leaving it due to above reasons.
Masaharu Goto
> Variables can be declared in global or function scope.
> Unlike ANSI, local variable has function scope. If a local variable
> is once declared in a function, it will be alive until execution gets
> out from the function even if it is declared within sub-block. In ANSI
> C, local variables have block scope.
>
> func()
> {
> int i;
> for(i=0;i<10;i++) {
> int n; /* block scope */
> printf("n=%d\n",n++);
> }
> /* n is still alive here in cint, n should be already
> dead in ANSI C */
> }
>
> If this is not true anymore, please tell me. I'm using
> local variables inside {...} inside functions _very_ often.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:19 MET