+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: DIM - AS - VARIABLE TYPE likely bug (/showthread.php?tid=2651)
RE: DIM - AS - VARIABLE TYPE likely bug - bplus - 05-06-2024
(05-06-2024, 04:10 PM)Dimster Wrote: Hi bartok .. thanks very much for asking this question. I do understand you are feeling somewhat under attack personally and I completely see where you did get a satisfying answer to your query but the subject took on a life of it's own after that point. Your question has highlighted some of the issues I have will my approach to variable names and types. I dim everything and and often get tripped up with string variables. If, at the beginning of my code I have something like Dim Shared A AS String, days later and multiple lines later I'll run into a situation where I have
Print B
Print C
Print A
Print D
And I'll forget that A is printing a string value because it looks like it's the same type as the others.
Where strings are concerned I'm now in the habit of A$ as it pops out
Print B
Print C
Print A$
Print D
Hope you may see the comments here as addressing the issue "DIM - AS - VARIABLE TYPE likely bug" and not bartok personally.
+1 @Dimster, we are all learning here, we all can benefit by information shared by members, @bartok don't get angry please if what's being said is not useful eh, water off a ducks back... Got to say I learned something i did not know from this discussion, thanks for your questions and comments and this whole discussion.
RE: DIM - AS - VARIABLE TYPE likely bug - Kernelpanic - 05-06-2024
The whole thing is becoming more and more like a “dispute over the emperor’s beard” (Streit um des Kaisers Bart) or “That's just splitting hairs.”.
RE: DIM - AS - VARIABLE TYPE likely bug - Dimster - 05-06-2024
I'm likely taking this topic a little more off the issue but rather than starting a new thread hoping it's ok to ask it here ... Is there an order to the assignment of a Type for a variable?
For example
Dim A$
Dim A
Dim A!
In the order above, why would not QB64, upon finding the 2nd Dim statement, simply change the type of A from a string to a single. Similar to a redim. So that in this dim order example the last Dim statement for A (A!) would rule?
I haven't tested this yet but from past coding, this does appear to be the case (ie a 2nd incident of a change in Variable Type but no change in the Variable name) if Dimming locally rather than globally. I think I have in the past had a Dim A$ in one sub and DIM A in another sub without an error message.
Steve's earlier comment about the 2nd encounter of the same Variable Name triggering the error message of Name already in use must only apply to Globally Named variables correct?
RE: DIM - AS - VARIABLE TYPE likely bug - bplus - 05-06-2024
(05-06-2024, 05:56 PM)Dimster Wrote: I'm likely taking this topic a little more off the issue but rather than starting a new thread hoping it's ok to ask it here ... Is there an order to the assignment of a Type for a variable?
For example
Dim A$
Dim A
Dim A!
In the order above, why would not QB64, upon finding the 2nd Dim statement, simply change the type of A from a string to a single. Similar to a redim. So that in this dim order example the last Dim statement for A (A!) would rule?
I haven't tested this yet but from past coding, this does appear to be the case (ie a 2nd incident of a change in Variable Type but no change in the Variable name) if Dimming locally rather than globally. I think I have in the past had a Dim A$ in one sub and DIM A in another sub without an error message.
Steve's earlier comment about the 2nd encounter of the same Variable Name triggering the error message of Name already in use must only apply to Globally Named variables correct?
yeah tested you will be enlightened to know a! is already used,
global = shared or constant i say yeah, before i tested ;-))
RE: DIM - AS - VARIABLE TYPE likely bug - Kernelpanic - 05-06-2024
There is only one thing that comes to mind regarding this thread (Where are the chips?):
RE: DIM - AS - VARIABLE TYPE likely bug - SMcNeill - 05-06-2024
(05-06-2024, 05:56 PM)Dimster Wrote: I'm likely taking this topic a little more off the issue but rather than starting a new thread hoping it's ok to ask it here ... Is there an order to the assignment of a Type for a variable?It applies to variables in the same NAMESPACE.
For example
Dim A$
Dim A
Dim A!
In the order above, why would not QB64, upon finding the 2nd Dim statement, simply change the type of A from a string to a single. Similar to a redim. So that in this dim order example the last Dim statement for A (A!) would rule?
I haven't tested this yet but from past coding, this does appear to be the case (ie a 2nd incident of a change in Variable Type but no change in the Variable name) if Dimming locally rather than globally. I think I have in the past had a Dim A$ in one sub and DIM A in another sub without an error message.
Steve's earlier comment about the 2nd encounter of the same Variable Name triggering the error message of Name already in use must only apply to Globally Named variables correct?
Code: (Select All)
Dim a As Double
Sub foo
Dim a As Long
'dim a as single
End Sub
Take the above example, as an example.
Written as is, it causes no errors with the IDE, nor any problems with compiling and running (and doing nothing as the code does nothing).
However, if you unremark that 'dim a as single, it suddenly tosses an error on you!!
Why??
You're trying to dimension a variable with the same name, in the same scope/namespace!
That first Dim a As Double, applies only in the main module. It's not DIM SHARED, so it's not a global variable. The scope is limited. The second Dim a As LOng, is inside the SUB foo -- it's a variable only local for the SUB and not in scope anywhere else. Having it be the same name, but a different type than the original a, isn't a problem.
That dim a as single, however, now has two variables named "a" being defined in the same scope -- both as local variables in SUB foo. THIS IS NOT ALLOWED!! ERROR!! ERROR!! THE IDE IS REVOKING YOUR COMPILING PRIVILEDGES!!
So it's a rule of "Can't define the same variable-without-a-suffix as a type more than once, *while in the same namespace/scope range*."
As for your explicit example of:
Code: (Select All)
Dim A$
Dim A
Dim A!