Global Inside Procedure

[grabiller]

Hello,

For the purpose of binding function pointers to PB global variables from an external library, I'm using a Macro inside a Procedure which declare a Global variable for each function (and retrieve the actual pointer of the functions and set the variables).

Using this Macro allow me to type the function names once, instead of first declaring the global variables outside the procedure then use the Macro for which I have to retype the function names (and I have more than 500 functions). It makes the source code clearer and shorter.

These variables can then be accessed *outside* this Procedure, even with EnableExplicit on.

My question is: while it works perfectly well, is it 'legal' in a PureBasic sense to use the Global statement *inside* a Procedure ?

Because I don't want to have the "native types can't be used with pointers" syndrome/surprise in a near future by learning that 'this' new version of PureBasic forbid the use of the Global statement from within a Procedure.

So.. should I be confident or worried using the Global statement inside Procedures ?

Thanks,
Guy.

[skywalk]

I often use 'mylib_Init()' procedures that define all my globals,constants,etc., so I am counting on Global to be allowed inside procedures.

[luis]

I believe a specific usage inside procs is not documented/suggested. If I'm wrong, please correct me. So it's not forbidden also (a good sign come from the fact this type of code is currently compilable and no-one ever thought about reporting this as a bug).

Even if it were specifically documented/suggested I think with PB you can make only bets based on probability.

The language changed in the past (sometimes breaking compatibility) and there is no guarantee it cannot change in the future.

The case of the "native pointers type" subject on analysis show two possible weakness:

1) was generating confusion
What ? *hello.s does not need to point to a string ?
What ? *ptr.b is different from *ptr.byte ?

2) the type wasn't affecting the code generated (*ptr, *ptr.b, *ptr.i, etc. had the same meaning for the compiler)

Now ask yourself if you see something similar for Global inside a procedure, why it shouldn't be allowed inside a procedure, and note its position in the source (without EnableExplicit) is determinant for the scope of a variable when referencing it through code. Ask what the cost of the change you fear would be for the existing code base and compare this with the "NPT" case above.

Even a reply from Fred wouldn't (and shouldn't) keep him bind to this if something he cannot foresee now (since the language is not finalized) will happen in the future.

MY personal opinion is you can go for it with a good degree of confidence.

Because I don't want to have

If you don't WANT then you are using the wrong tool, experience taught you this already. If you would like to avoid it if possible... then I would use the "method" above.

[Fred]

Global is OK in procedures

[grabiller]

Thanks Fred.

[MachineCode]

Just remember that the global variable must still be declared BEFORE any use of it. Look at this:

Code: Select all

Procedure ShowGlobalVar()
  Debug var
EndProcedure

Procedure SetGlobalVar()
  Global var=1
EndProcedure

SetGlobalVar()
ShowGlobalVar()

This would APPEAR that the debug output shows 1, but it actually shows 0. Just mentioning it for the benefit of newbies.

[skywalk]

EnableExplicit

[BorisTheOld]

Just mentioning it for the benefit of newbies.

In that case, perhaps a well formed example might be better.

@skywalk

Don't you just love EnableExplicit? I wouldn't be without it.