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.
Global Inside Procedure
- grabiller
- Enthusiast
- Posts: 309
- Joined: Wed Jun 01, 2011 9:38 am
- Location: France - 89220 Rogny-Les-Septs-Ecluses
- Contact:
Global Inside Procedure
guy rabiller | radfac founder / ceo | raafal.org
Re: Global Inside Procedure
I often use 'mylib_Init()' procedures that define all my globals,constants,etc., so I am counting on Global to be allowed inside procedures.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Global Inside Procedure
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.
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.
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.Because I don't want to have
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Global Inside Procedure
Global is OK in procedures
-
- Addict
- Posts: 1482
- Joined: Tue Feb 22, 2011 1:16 pm
Re: Global Inside Procedure
Just remember that the global variable must still be declared BEFORE any use of it. Look at this:
This would APPEAR that the debug output shows 1, but it actually shows 0. Just mentioning it for the benefit of newbies.
Code: Select all
Procedure ShowGlobalVar()
Debug var
EndProcedure
Procedure SetGlobalVar()
Global var=1
EndProcedure
SetGlobalVar()
ShowGlobalVar()
Microsoft Visual Basic only lasted 7 short years: 1991 to 1998.
PureBasic: Born in 1998 and still going strong to this very day!
PureBasic: Born in 1998 and still going strong to this very day!
Re: Global Inside Procedure
EnableExplicit
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
-
- Enthusiast
- Posts: 542
- Joined: Tue Apr 24, 2012 5:08 pm
- Location: Ontario, Canada
Re: Global Inside Procedure
In that case, perhaps a well formed example might be better.MachineCode wrote:Just mentioning it for the benefit of newbies.
@skywalk
Don't you just love EnableExplicit? I wouldn't be without it.
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
~ Spike Milligan