QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Dimster on December 14, 2020, 10:22:12 am
-
Does the Dim Shared variable replace the need for Parameters and Argument passing in all cases?
-
As far as I know, yes. You shouldn't need to pass any parameters to a function provided you didn't require usage of a variable that you had not defined as SHARED. However, I do not recommend doing this. The variable might accidentally get changed along the way while being passed around without you realizing it. Certain variables I will make global/shared because I plan on reading a return value anywhere in the program, similar to how I do my MySQL code. I have a variable, called "affectedRows", that I set in my function. It isn't necessary to pass to the function because that's just one more parameter and would look sloppy. However, if I want to read it, I just print/store/check the value in it to verify function operations. It's up to you and how you like to style your code, though. It's just my preference to shy away from using global/shared variables unless they are constants.
According to Stack Overflow, don't do global variables. Instead, pass parameters.
https://softwareengineering.stackexchange.com/questions/347199/parametrize-methods-vs-global-variables (https://softwareengineering.stackexchange.com/questions/347199/parametrize-methods-vs-global-variables)
-
Does the Dim Shared variable replace the need for Parameters and Argument passing in all cases?
I would say definitely not, there are times, many, when you need to keep variables private. Indexes are a great example you don't want the i in the main module interfering with the i in the subroutine or vice versa. But true, there is allot of grey area when it could go either way.
This is opinion only but I think subroutines are better written without shared variables, they would certainly be more universal and independent.
Sharing arrays makes sense unless you have routines to work on arrays.
STATIC is interesting, you only "share" a variable with the routine that needs it, preserving it's value(s) between calls to the subroutine.
-
I would say definitely not, there are times, many, when you need to keep variables private. Indexes are a great example you don't want the i in the main module interfering with the i in the subroutine or vice versa. But true, there is allot of grey area when it could go either way.
I think he ment," if I DIM SHARED My_Variable then do I need SUB My_Sub(My_Variable)?"
Which the answer would be No you don't need the Argument then.
Although if you DIM SHARED I then you would have an issue keeping your indexes separate at all.
Which I think would be more of a "When should you not DIM SHARED a variable?" situation.
Variables are a many splendid,and frustratingly horrible thing!
-
I think he ment," if I DIM SHARED My_Variable then do I need SUB My_Sub(My_Variable)?"
Which the answer would be No you don't need the Argument then.
OK maybe a more sensible question, but that could also be easily tested. ie you could find the answer with a tiny bit of a code experiment.
-
Thanks guys - I guess it's a little more dicey to rely on a Dim Shared Array to pass values to a Subroutine without Arguments & Parameters than it is a single Dim Shared Variable.
-
@Dimster
Can you give us an example in some code that you have?
-
SHARED, or via parameter, it doesn’t make much difference, except to limit scope.
If you DIM SHARED variable in your main program, that variable is available in *ALL* parts of your program. Every SUB and FUNCTION that sees that variable will interact with that variable.
If you pass via parameter, only the main program and that particular SUB/FUNCTION will share that value (and only then, if variable types match).
For example:
DIM SHARED I AS LONG
I = 123
PRINT I
FOO
PRINT I
FOO2
PRINT I
SUB FOO
I = 234
END SUB
SUB FOO2
I = 345
END SUB
Compared to:
I = 123
PRINT I
FOO I
PRINT I
FOO2
PRINT I
SUB FOO (I)
I = 234
END SUB
SUB FOO2
I = 345
END SUB
-
I use a lot of DIM SHARED variables, but I generally try to keep the number of SUB/FUNCTIONs that actually change them fairly limited. I'll pass them as arguments, but am careful not to change them except where necessary. I've heard it said that good programming practice shouldn't need many SHARED variables, Bplus makes a good case why. Well.... I'm not the caliber of programmer to follow that advice very well, but neither do I argue with it.
-
@SpriggsySpriggs
I have no particular coding routine that is problematic for me. The question came up in my mind because in my program I have written the data flow both ways, seems I lean to the method/style that OldMoses has described. But in the interest of "cleaning up" some of the coding routines I was thinking of just using Dim Shared everything (variables and arrays) thus the "in All cases" question.
-
I was thinking of just using Dim Shared everything (variables and arrays) thus the "in All cases" question.
Oh yuck, I think your thinking is pointed the wrong way ;) if you want to share everything go back to GOSUBs and do not pass GOTO and collect $200. ;-)) But sure OK for little apps.
When I was reworking Word Search, I did find taking all the app's shared variables and putting them in a Type and sharing that, helpful for organization and remembering what was shared and what wasn't. It also helps make clear what the variable is connected with but I had to carry around a little reference card for the Type.
There seem to be 2 kinds of subroutines, ones needed for the app and general ones that could be handy in all sorts of apps. Sharing with the routines written for the app seems highly efficient because you don't need to add them to parameters list. The thing to be careful about Sharing is using a same variable name in a General Handy subroutine and this is pretty much taken care of if you Type all your shared variables for the app. Dim a short name of that type and then share that in main code module declarations area. Good for when lines of code start to exceed 300 - 500.
-
@bplus
I'd love $200 right now. I'm dabbling with an AI program which has tons of data and tons of decision structures. I'm using a modular approach and last time I combined all the modules the program is over 25,000 lines of code. If I can keep the coding uniform and simple, it appears to result in more accuracy - ie both math calculations and reliable decision results. This is a never ending project - I took it up a couple of years ago when I discovered QB64 and AI/Block Chain were gaining popularity in the news - so just learning as I go along. As they say it's the journey and not the destination that is the real joy in life.
To go with just Dim Shared everything, I would think I would need every variable and every array to carry a unique name - plus reserve something unique for the for/next and do loops. I guess I'd need the IDE to keep track of all the variable and array names or i'll need to do that manually. Pretty daunting task right now - hard to remind myself " it's the journey that counts"
-
Ha! maybe you could leverage that journey by sharing some more details about it, 25,000 LOC!, AI what sort, Chain? never heard of it. (I've not heard of allot of things though.) You got me curious ;)
I hope you aren't writing what should be stored as data as lines of code, unless of course you are making Christmas submissions to the forum ho, ho, ho!
-
@bplus
I misspelled Blockchain - it's all one word and not two separate words as I wrote it. I think you maybe aware of this coding structure which presently is the basis for Crypto Currencies. I'm interested in the way each link has a proof item which links one block in the chain to another.
As to what sort of AI, well that's a very fluid thing. The more I learn about AI the more I mold/remold my coding. At the moment I am not going down the route of Game Theory, in the narrowest of meanings of that term (ie a Game where the computer has a limited scope of moves to keep within the meaning and goals of a game. Although some of those Learning routines are pretty clever). I'm more intrigued with some of the aspects of Human Intelligence which we bantered about on this forum years ago when I first joined. The idea that a baby is hard wired with some skills at birth - the inputs it gets, the learning it goes through and ultimately the success it achieves to live on it's own. It's that learning aspect which seems to be the essence of intelligence.
So if you and I were babies would our inputs begin as Dim Shared inputs (ie that better be food) or do all the inputs come with Arguments (ie taste good, smell good, feels good) and Paraments (ie I like it, I hate it, too hungry to care) . At the moment I'm trying to work with "Success" for want of another term. I have coded a lot of perceptrons with weights and biases and trying to build a learning routine common to them all but defining what Success looks like, has the thinking cap on.
Anyway - give a guy a platform - like "what sort of AI" - and he'll be there forever ranting on.
-
If we’re talking coding styles, here’s m general rules for DIM SHARED vs paramters:
1) If the sub/function (I’m just going to say SUB for both, from here out) needs to do something for multiple cases, I *always* use parameters. An example of this would be SUB Sort (array() AS LONG). Here, it doesn’t make sense to DIM SHARED array(), as I may have 5 or 6 different arrays I want to sort. What am I going to do? SUB Sort_array_a, SUB Sort_array_b, SUB Sort_array_c... That doesn’t make a lick of sense.
2) If the same variable is going to be used in multiple SUBs, I’ll DIM SHARED it. Once again, it just doesn’t make sense to me to: SUB Capitalize(text$), SUB StripCRLF(text$), SUB AddCHR10 (text$), SUB PrintOut (text$), SUB Blank (text$)... All these routines work with the same singular variable — why the heck isn’t it just DIM SHARED? Save the typing — prevent carpet tunneling!
3) If a variable is going to mainly be referenced without changing, I’ll DIM SHARED it. Fro example: DIM SHARED ScreenX, ScreenY. I might have one routine that checks if the user has resized the window, which sets my ScreenX/Y, but that’s not going to change anywhere else. Elsewhere it’s just read and used; not changed. Why not just DIM SHARE it?
4) Sub usage also affects things. If I’m just writing a SUB for internal use in a singular, specific program, then it doesn’t matter. As long as the proper data is interchanged from the main module and the SUB, it’s all good. If, however, I’m writing a SUB to pull out for my toolbox, or a library, then I want it to be as self-contained as possible. Parameter passing is preferred then over DIM SHARED. Why have to $INCLUDE two files, when one can do just as good?
And anytime not covered by these general rules, I tend to just go with whatever suits my taste at the moment. At the end of the day, the biggest concern is: Does the code work, or not? If it does, then all is good. If not, the SHARE or pass whatever is needed so it does. ;D
-
Hi Steve
Ya, it's your rule #1 which is what I was referring to in the comment above about Dim Shared Arrays as being dicey.
Thanks Steve
-
Hi
nothing to add to your professional experience, but I must remark this: [ This attachment cannot be displayed inline in 'Print Page' view ]
-
Thanks Tempodi - you are right - I did not consider Shared.
-
Thanks Tempodi - you are right - I did not consider Shared.
I thought he was talking about CONST's that are automatically SHARED, we've been talking about SHARED all along.
-
I thought he was talking about CONST's that are automatically SHARED, we've been talking about SHARED all along.
He's talking about:
SUB example
SHARED foo
... do junk
END SUB
It's a way to share information between subs and the main module, without having to rely on passing via parameters. For me, I generally tend to go this way when there's unchanging variables like the ScreenX, ScreenY resolutions which I talked about above, or when my parameter list has gotten so long it's unwieldly to keep as a single line, such as below:
SUB Boxed_Text (x, y, wide, tall, text$)
Shared font, fontcolor, fontbackground, workscreen, framecolor, framethickness, fontplacement
Shared fontstyle, captionstyle, captionthick, captionfont, captionfontcolor, captioncolor
Shared close_button, minimize_button, maximize_button, move_button, scrollbar_vert, scrollbar_hort
... do stuff
END SUB
Many of these things might not change from call to call to the SUB, and it'd be impossible to keep up with all those dang options and ever use the command properly, so the main changeable stuff is passed via parameter, and the rest is passed via SHARED inside the sub itself.
-
Don't forget the use in TYPE...
Pete
-
@Pete thanks for sharing.
-
"sharing" :D :D :D
-
Please tell me
Sharing what? Wit, Dumb or Democrat?
-
None of the above. Making it functional, using SHARED, just spoils one of the the puns. Okay, fine, but now it requires more explanation...
dimwit.dumb
= "All Democrats are idiots.":
CALL idiots
-
Now THAT should have been in the voting machines. ;)
-
Well Andy, I'm pretty sure Dominion software is coded in FreeBASIC, so what could go wronnnnnnng?
Pete
-
And here's one final tip: case your shared variables differently to you local ones.
So if you normally write local variables as 'local_var', consider starting shared variables with a capital letter: 'Shared_var'.
That way when you're reading a section of code you know immediately what's coming from outside the subroutine, and whether changing a variable's value will affect other parts of the code.
-
Hey Luke - that's a helpful tip. Thanks for same.
-
And here's one final tip: case your shared variables differently to you local ones.
So if you normally write local variables as 'local_var', consider starting shared variables with a capital letter: 'Shared_var'.
That way when you're reading a section of code you know immediately what's coming from outside the subroutine, and whether changing a variable's value will affect other parts of the code.
Only old people of diminished mental capacity would ever need to use a "trick" like that to sort out shared variables from local variables... Thanks for the tip, Fred.
Jack
-
Hi Pete
I like your red hair
BUT... you have posted a demo of DIM SHARED and not about SHARED!
this one is a demo of SHARED!
dimwit.dumb
= "All Democrats are idiots.":
CALL idiots
idiots2
And Thanks, with your modded demo I have learnt that it is possible to declare a variable that includes a point in its name! In Idiots dimwit.dumb is a single type of variable with a point in its name!
-
Isn't a period a valid character in a variable anyway?
DIM x.a AS INTEGER, x.b AS LONG
-
Yes Steve
in fact I have said
I have learnt that it is possible to declare a variable that includes a point in its name
for the simple reason that I have always used the character period only when I have typed an UDT. But this is an my habit that let me think that period is invalid for normal name of variable, so now I have learnt this new possibility in writing a name of variable.
-
I'm glad it shed some light on something new for you... It just goes to show us all that Democrats are, indeed, useful idiots.
Pete :D
Trump 2020, and beyond!