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 / declaration problems

Author
Message
Irgendwer
21
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Germany
Posted: 15th Oct 2005 02:32
The way DBP parses declarations seems strange to me. Concider this small example:

The compiler complains about the variable x being declared twice what is in my opinion not what it's supposed to do. If we just change the location of the subroutine, it works like a thread.

Isn't a subroutine supposed to do exactly the same, no matter where it's implentation is written? I think so, but correct me if I'm wrong.
OSX Using Happy Dude
20
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 15th Oct 2005 06:22
As x is global, you are trying to define it twice (in the first example).

Come to the third DarkBasic Pro Sci Fi Con - Be there and be square
Blog:http://spaces.msn.com/members/BouncyBrick/
Web Site:http://www.nicholaskingsley.co.uk
D Man
21
Years of Service
User Offline
Joined: 3rd Oct 2002
Location: Germany
Posted: 15th Oct 2005 15:38 Edited at: 15th Oct 2005 15:39
I can see the point of that bug report.
It is important where subroutines are placed in the DBP-sourcecode what is not as its supposed to be in my opinion.
To me it seems as if gosubs are not consequently thought to the end.
There are two different approaches; either explicitly declared variables are local to each procedure or declarations in sub routines are parsed in the right order (i.e. the order the program runs, not the order the sourcecode looks like).

God is real, unless declared integer.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 16th Oct 2005 15:05
DBPro isn't an interpreter, it's a compiler, which means that the best it can do is to accept variable declarations in sourcecode order. It just reads the code line by line until it's done.

Here's how the compiler deals with your first piece of code:


... and here's how the compiler deals with the second:


Quote: "either explicitly declared variables are local to each procedure or declarations in sub routines are parsed in the right order"


That's what functions are for, and don't declare variables in subroutines. Easy fix.

Quote: "the order the program runs, not the order the sourcecode looks like"


The only way for a compiler to do this would be for the compiler to actually execute your code ... and that makes it an interpreter, not a compiler.

For free Plug-ins and source code http://www.matrix1.demon.co.uk
D Man
21
Years of Service
User Offline
Joined: 3rd Oct 2002
Location: Germany
Posted: 17th Oct 2005 16:18 Edited at: 17th Oct 2005 16:19
Quote: "The only way for a compiler to do this would be for the compiler to actually execute your code ... and that makes it an interpreter, not a compiler."


Thats not true.
It could easily be fixed using a second parser-run.

Concider this small example:



No error is returned here, just because x has become global.
Your explanation does not justify the above in my opinion, because the declarations are in the exact same order as before.
I think, that global declarations might always overwrite implicit given types before, so why not threating all declarations in gosubs as "global" (not really, because they should not be visible to functions, but for the moment causing the same action as globals would do).

This is of course no showstopper, but I think it can be concidered as flaw.

God is real, unless declared integer.

Login to post a reply

Server time is: 2024-03-29 11:03:50
Your offset time is: 2024-03-29 11:03:50