Shouldn't this trigger a compiler error?

[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.

[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.

[skywalk]

haha, if PB had an optimizer, then 'if 1=0' code would be dropped and EnableExplicit would catch the undefined variable.

[Shield]

No, this would happen at a later stage so the variable would already have been recognized.

[Little John]

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.

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!

[skywalk]

~ 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'.

[Little John]

~ 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?

[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.

[Little John]

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.

[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.

[Shield]

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.

[Demivec]

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.

[Kukulkan]

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.

[Dude]

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."

[Kukulkan]

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.

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...