Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Bug Reports / [DBPro 7.7RC7] – Scope Problem With Global Variables

Author
Message
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 25th Oct 2011 04:00 Edited at: 30th Oct 2011 18:24
The DBPro compiler does not return an error message when a Local variable declared in a function is declared by the same name as a Global variable, or when a function parameter is declared by the same name as a Global variable.

If a function parameter is declared by the same name as a Global variable the Local declaration of the parameter takes precedence over the declaration of the Global variable and prevents you from accessing the value of the Global variable.

If a Local variable declared inside a function is declared by the same name as a Global variable the Local declaration takes precedence over the declaration of the Global variable and prevents you from accessing the value of the Global variable. The method by which DBPro declares variables prevents you from getting the value of the Global variable anywhere in the function if there is a Local variable declared by the same name within the function.





[img][/img]


WindowsXP SP3,Vista,Windows 7 SP1, DBpro v7.7RC7
Stab In The Dark Editor
The coffee is lovely dark and deep,and I have code to write before I sleep.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 25th Oct 2011 15:34
Um... yes. That's the point of local variables and parameters - they're local.

- If they didn't take precedence over globals, then there would be no point to them.
- If they triggered an error because they obscure an existing global then you'd be forced to change code that worked OK just because of a clash of names (when importing a function from another project for example).

That last point also includes such things as writing a function, then later adding a global that causes a clash - you've now broken code that you didn't change.

I know of no programming language that operates in the way you suggest DBPro should.

Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 30th Oct 2011 18:06 Edited at: 31st Oct 2011 02:03
We were not suggesting that the DBPro compiler should handle local variables differently,
we were simply pointing out that local variables declared in a function can
shield global variables by the same name and that currently there are no warnings
in place which can alert the user to this fact.

We agree that Local variables should take precedence over Global variables,
however the logic of this might not be evident to all user of DBPro
especially user who are using DBPro as their first programming language.
This is not necessarily a bug with the DBPro compiler as the code will still compile
but this is a lack of functionality in the DBPro compiler and or the existing DBPro IDE.
There are scenarios where a DBPro programmer could inadvertently break existing code
which was working simply be declaring a local variable by the same name as a global variable.
In these cases the IDE or compiler should prompt or warn the user about the naming conflict
and explain how DBPro handles scope. This would shorten the learning curve required
for someone who is new to programming and or the DBPro language. Below is an example of how
someone could inadvertently break a function which was previously working by declaring
a local variable by the same name as a Global variable.



[img][/img]


WindowsXP SP3,Vista,Windows 7 SP1, DBpro v7.7RC7
Stab In The Dark Editor
The coffee is lovely dark and deep,and I have code to write before I sleep.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 30th Oct 2011 22:57
Could you edit your snippet so it fits neatly within the screen? Having to continually scroll back and forth just to read a single sentence gets irritating after a while. I'm sure you don't want to irritate those who might be inclined to agree with you, do you?

Your observation is one of the reasons why I gave up using global variables in other languages that I've used - and always passed everything I needed via function arguments so everything was local. Everything was simple then.

IanM will probably tell me that that is a very inefficient way of solving the problem - but it worked for me. But now I use DBPro.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 31st Oct 2011 15:49
Quote: "Below is an example of how someone could inadvertently break a function which was previously working by declaring a local variable by the same name as a Global variable."

I would argue that your code is broken, not the compiler.

The nearest thing I can find in the help file is:
Quote: "Local arrays can only be accessed by the function in which it was created"

... which to be honest is a bit crap (and not entirely unexpected), but it doesn't say 'accessed from the point it is defined', only 'accessed by the function'. I'd assume that the scoping rules are identical for variables too.

Quote: "IanM will probably tell me that that is a very inefficient way of solving the problem - but it worked for me."

It really depends on what you are passing - passing objects/arrays by reference is no more inefficient than passing an integer. Besides, what is 'fast enough' is usually completely different to 'most efficient', and 'fast enough' is usually my aim.

About the only thing I would comment on is readability of the code - if you have so many parameters that remembering how to call the function becomes difficult, then you have too many.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Oct 2011 17:22
Quote: "if you have so many parameters that remembering how to call the function becomes difficult, then you have too many."


I've never encountered that problem. Structures?

Regarding readability, the use of globals makes matters far worse unless you have a decent IDE which accurately warns/informs you of the variables currently in scope. How much code do you want to read before discovering that a variable has already been declared global in some distant bit of code?

I agree with your earlier comments about local variables taking precedence.

Anyway, Stab in the Dark software has granted my request. Thanks.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 31st Oct 2011 20:17
Quote: "Structures?"

Yes, as the Windows API (usually) does them: allocate a structure (which may be on either the stack or the heap), fill the structure out, then pass the address of it to the function.

Good example from Windows API
Bad example from Windows API

Quote: "Regarding readability, the use of globals makes matters far worse"

Agreed, limiting use of globals for readability is also up there with limiting them because of their potential side-effects on implicit-locals in functions.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Oct 2011 23:02
Regarding your good and bad examples, yes, it's incredibly easy to miss a parameter out or get them in the wrong order when confronted with a long list (i.e. more than one item ). Structures reduce, but don't quite eliminate, those possibilities.

I suppose I really ought to learn C++ ...

Login to post a reply

Server time is: 2024-03-29 14:28:18
Your offset time is: 2024-03-29 14:28:18