Page 1 of 2
Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 3:54 pm
by Kukulkan
Just encountered this issue:
Code: Select all
EnableExplicit
Procedure test()
If 1=0
Protected t.s = "Hallo"
EndIf
PrintN(t.s)
EndProcedure
OpenConsole()
test()
CloseConsole()
I believe the compiler should complain about undefined t.s. Or not? Searched a long time for a bug because it didn't complain.
It should, at least, trigger a warning in such case.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 3:59 pm
by Shield
PB doesn't have scopes other than functions and modules, so it doesn't matter where a variable is defined within a procedure as long as it is defined first. Not a bug but not elegant either.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 5:26 pm
by skywalk
haha, if PB had an optimizer, then 'if 1=0' code would be dropped and EnableExplicit would catch the undefined variable.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 5:39 pm
by Shield
No, this would happen at a later stage so the variable would already have been recognized.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 7:00 pm
by Little John
Kukulkan wrote:I believe the compiler should complain about undefined t.s. Or not?
Like Shield, I don't expect the PB compiler to complain in this case.
Do not confuse the situation with the following one:
Code: Select all
CompilerIf 1=0
Protected t.s = "Hallo"
CompilerEndIf
If you change your code like this, then the compiler correctly will complain about undefined variable t.
Kukulkan wrote:Searched a long time for a bug because it didn't complain.
It should, at least, trigger a warning in such case.
When I read code like yours above, my eyes are triggering a warning.
I never write code like that.
In other words, for me personally code is much better readable when all protected variables are defined at the
beginning of the respective procedure.
It's that simple!
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 7:42 pm
by skywalk
Little John wrote:~ for me personally code is much better readable when all protected variables are defined at the beginning of the respective procedure.
That is being done despite the user's intention with the 'if 1=0'.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 7:48 pm
by Little John
skywalk wrote:Little John wrote:~ for me personally code is much better readable when all protected variables are defined at the beginning of the respective procedure.
That is being done despite the user's intention with the 'if 1=0'.
Sorry, I don't understand what your reply means.
Can you please explain a little more elaborately?
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 8:13 pm
by skywalk
I seem to recall Fred/freak said all variables within a Procedure are defined despite being defined in a conditional branch. Since the condition is unknown at compile time.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 8:27 pm
by Little John
skywalk wrote:I seem to recall Fred/freak said all variables within a Procedure are defined despite being defined in a conditional branch. Since the condition is unknown at compile time.
Yes, Kukulkan's
If branch is evaluated at run time.
What does happen or does not happen at compile time is controlled by
CompilerIf,
CompilerSelect, etc.
Of course,
Protected is evaluated at compile time.
Re: Shouldn't this trigger a compiler error?
Posted: Thu Nov 05, 2015 9:24 pm
by GPI
My personal opinion:
At least the compiler should output a warning, when a variable definition is inside of a structure like if-endif, while-wend, repeat-until, for-next.
It is a realy bad program style.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 12:07 am
by Shield
skywalk wrote:I seem to recall Fred/freak said all variables within a Procedure are defined despite being defined in a conditional branch. Since the condition is unknown at compile time.
In PB (IIRC), every declared variable will be moved to the beginning of the procedure by the compiler.
I prefer to define variables when they are used first, but since that doesn't matter in PB I also put them at the very beginning.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 2:57 am
by Demivec
Shield wrote:skywalk wrote:I seem to recall Fred/freak said all variables within a Procedure are defined despite being defined in a conditional branch. Since the condition is unknown at compile time.
In PB (IIRC), every declared variable will be moved to the beginning of the procedure by the compiler.
I prefer to define variables when they are used first, but since that doesn't matter in PB I also put them at the very beginning.
The memory for the variable is set aside at the start of the procedure but if the variable is also assigned a value as part of the 'Protected' statement the assignment occurs at the place dictated in the code. This was demonstrated in the sample code as well.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 8:47 am
by Kukulkan
Little John wrote:When I read code like yours above, my eyes are triggering a warning.
I never write code like that.
John, this is to demonstrate the problem only. Obviously, this does not make any sense in real code. The situation for me happened in a very old function that I re-designed (sadly to much copy&paste) so the "Protected" slipped into a bigger If condition. Later I wondered why the variable was empty at some point. I assumed that "EnableExplicit" should warn and the "Protected" statement defined some default initialization value.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 8:52 am
by Dude
Kukulkan wrote:I believe the compiler should complain about undefined t.s
It's not undefined. The "Protected" keyword defines it, just like the manual says:
"When enabled, all the variables which are not explicitly declared with Define, Global, Protected or Static are not accepted and the compiler will raise an error."
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 8:58 am
by Kukulkan
Shield wrote:In PB (IIRC), every declared variable will be moved to the beginning of the procedure by the compiler.
I believe it is not. In such case, the value of t.s would have been "Hallo". But it is empty. Thus, the whole declaration was ignored.
By the way, the discussion currently ignores the default value I set using "Protected". If I define a variable using "Protected" together with a default value, the first usage of that variable should contain the initialization value. In my example you can see, that also the assignment of the default value is missing.
No matter if this is good practice or not, I agree to GPI that this should trigger at least a warning during compile time.
Shield wrote:Say what? It's not undefined. The "Protected" keyword defines it, just like the manual says.
My declaration of t.s contained a default value. This was ignored by the compiler as during the first usage of the variable it was empty. But this is not what I defined using "Protected".
Sorry, we might have different opinions here. But that's ok
Fred will have to decide...