Is it safe to assume that in EBasic, types defined in a Sub are local to that Sub and are destroyed (or stop existing, or are no longer referenced anywhere) once the routine exits?
-S
Yes local variables inside a sub exists only inside that sub.
There's only 2 places I've run into problems in a sub.
Directly manipulating passed variables that are passed by reference(all strings) can sometimes mess people up but other times it is a useful thing to do.
The other thing is defining a global variable with the same name as a local variable. I believe the local overrides the global and can produce unwanted results if you don't realize what you are doing.
Larry
Thanks, Larry. I made the assumption that local types would be treated like any other local variable - but I didn't want to bet money on it until someone specifically said yes.
I would expect the local to override the global in a Sub, and I'm glad to receive confirmation of that as well.
-S
Quote from: Larry McCaughn on April 23, 2008, 03:59:53 PM
The other thing is defining a global variable with the same name as a local variable. I believe the local overrides the global and can produce unwanted results if you don't realize what you are doing.
It would be nice if there was a warning about this. It's tripped me up a couple of times, too. Both times I didn't realize they had the same name and it took a few minutes to figure out what was going on.
Barry
barry,
If you program a lot and use a lot of global variables it might be best to prefix all your globals with something like "g_varname" so you always know for sure.
Larry
Local variables taking precedence over globals is standard in every compiler I have ever used, sorry if you're surprised by it ;)
I'm not surprised that local variables take precedence. What catches me is when I have a global variable that I haven't dealt with recently, and I give a local variable the same name and don't realize that I did it.
My suggestion that there be a warning about that wasn't a complaint about your compiler. It was an idea. Someone with a less negative attitude might have taken the suggestion as an opportunity, even if for some future time.
Being helpful around here is getting too painful.
Barry
Quote from: barry on April 24, 2008, 04:35:25 PM
Being helpful around here is getting too painful.
That's what I said when Microsoft ignored my suggestions. ;)
I have experience with several compilers and you would be hard pressed to find a better forum than this one. Larry's suggestion about g_ is one I use religiously. Scope bugs are nasty.
?? No negativity implied or meant. I even used a smiley ;)
I even made sure it was meantioned in the users guide after I saw the thread, and said I was sorry you were surprised by it.
Paul.
I wasn't surprised that that's how it works. That's how I would expect it to work. I've run into the problem of forgetting I've already used a name in a lot of compilers. If it's a re-definition the compiler warns me unless it's a local variable. Then I have to figure out why my code isn't working right.
I've never seen a compiler that would warn you if you accidentally use the same variable name for a local variable that's already being used by a global variable but, in reading this thread it occurred to me that it probably isn't difficult to implement and that it might be worthwhile.
Barry
I think perhaps the reason you get no warning is because it is valid to use a variable inside a sub that has the same name as one in the main program.
I often use 'i' j' k .. etc' for loop control variables - both in the main section and in subroutines. Since they are separate entities, there is no problem. In CBasic, if you 'stop' the program in a subroutine and examine the variables, you will see two variables with the same name - one tagged as local, the other as global. I imagine it's the same in EBasic. A small console test program would verify it .. :)
The subroutine variable won't interact with the main program variable, or any other subroutine variable of the same name - so no problem should arise. Subroutines can be regarded as independent in this respect.
Of course, if you change the value of a variable inside a subroutine and think it would have changed globally, you would be disappointed 'cos it won't. :)
The only way to do that is by using an array element passed to the subroutine as an argument. If you change that within the subroutine, it will be changed globally.
best wishes, :)
Graham
Quote from: GWS on April 25, 2008, 11:50:27 AM
Of course, if you change the value of a variable inside a subroutine and think it would have changed globally, you would be disappointed 'cos it won't. :)
Unless I'm missing something that's not true in all cases; thus this discussion.
If you declare x as GLOBAL in your main program then it is available to all subroutines. If you then use x in a subroutine
without declaring it IN the subroutine then x will have whatever value that it was last set to in another part of the program. If you change it in the subroutine it changes it for every other part of the program that uses it. I use that technique all the time to, in essence, pass a whole lot of info to a subroutine.
Larry
QuoteIf you declare x as GLOBAL in your main program then it is available to all subroutines.
Larry, Yes that is so - Global means globally available - I'm assuming a variable declared both in the main and the sub. Then they are independent.
Locodarwin, do you think you could focus a little more on programming discussion, rather than fanning misunderstandings.
It's always difficult to convey one's meaning in a few words - even with the use of smilies.
Graham :)
Graham,
I haven't used CB so I was attempting to clear up, in my simple mind ???, any difference between CB and EB for future reference. :) :) :) :) :)
Larry
Quote from: GWS on April 25, 2008, 01:30:03 PM
QuoteIf you declare x as GLOBAL in your main program then it is available to all subroutines.
Larry, Yes that is so - Global means globally available - I'm assuming a variable declared both in the main and the sub. Then they are independent.
Locodarwin, do you think you could focus a little more on programming discussion, rather than fanning misunderstandings.
It's always difficult to convey one's meaning in a few words - even with the use of smilies.
Graham :)
Actually, what I was trying to do is explain why winkies don't always come across as smilies.
I operate under the assumption that people can accept a little criticism, particularly when they are able to dole it out. We're all adults here. Therefore, your removal of my comment seems a little...strange.
Will this comment, too, be removed? C'mon, now. You wouldn't like that if I did it to you.
By all means, let's focus on the topic. And let's do it without making people feel stupid for asking simple questions.
-S
Graham is the moderator and has full authority to remove or edit posts that he feels are offensive.
Please stay on topic or the thread will be locked.
Paul Turley
Ionic Wind Software
Hi Larry,
I've tried this simple console program in debug mode, and it behaves just the same in CB or EB.
openconsole
int x
cls
x = 5
test()
do:until inkey$<>""
closeconsole
end
sub test
int x
x=2
stop
return
endsub
That is, you find two variables named 'x' - one is global and the other is local. So they will not interact.
If you miss out the definition in the subroutine, then of course only the global 'x' exists, and it is accessible in all subroutines.
all the best, :)
Graham
Graham,
I tend to program with projects more so then single source file exes.
I use include files with a awful lot of these (super-simplified):
$ifdef C100
global x : int x
$else
extern x :int
$endif
C100 is an identifier for a specific source file. the above declares x global in one src file and makes it global to all other source files in the project.
if I'm in another source file's subroutine and I forget to put in a AUTODEFINE "OFF" statement in that source file then I can use x without declaring it (which the lack of a AUTODEFINE "OFF" will allow me do even if I had never defined x globally) then I wind up thinking I'm using a local variable when I'm actually using a global one defined in another source file.
The times I've run into the problem I've usually been in the middle of a project and I'm pasting in some code to modify/merge into a new source file.
I guess you could really call it sloppy programming but when I'm in the heat of the battle that's what I do and then go back and clean it up.
Its happened enough to me in the past that I'm much better at protecting myself from ME.
In the past I've always looked at it as one of those "pay attention, dummy" type things and didn't fret about it much other than to kick myself in the hindparts for not remembering. ;D
Larry
Ah .. the joys of large projects .. :)
best wishes,
Graham
Hi all and this discusion is very interested for me.
Maby i do something wrong with global variables
in my interpreter becose all executing is in subs
and dont work with shared grafic cards?