Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Interesting problem with COMMON/DIM SHARED
#1
First of all, FB 0.11 rules big-time, except for this bug I seem to have come across (please tell me I'm doing something wrong, so I don't have to wait for 0.12 :-P)

I have these lines in my main include file (used by every module):

Code:
COMMON SHARED Layers() AS SDL_Surface POINTER
DIM SHARED Layers(1 TO 5) AS SDL_Surface POINTER

That compiles successfully, but any reference to the array at all crashes the program.

So I tried putting the dimensions in the COMMON...

Code:
COMMON SHARED Layers(1 TO 5) AS SDL_Surface POINTER
DIM SHARED Layers(1 TO 5) AS SDL_Surface POINTER

Also compiles fine, but crashes on any reference to Layers().

Lastly, just as a test, regardless of whether or not the array would be common, I tried:

Code:
DIM SHARED Layers(1 TO 5) AS SDL_Surface POINTER

This code worked fine when Layers() was referenced in engine.bas, my main module, but crashed when it was referenced in sdlwrap.bas, my graphics module. When I say "referenced," I mean used generally - I check the contents of Layers( ) with a PRINT statement as a sort of debugging, and the PRINT executes about halfway and crashes.

Tell me I'm doing something wrong. I'd love to continue programming. :-)

As a side note: it seems that if the array is dynamic, everything works fine - as is with my MainFont() array, my Tileset() array, and my Level() array.
color=blue]subxero - admin at this place.[/color]
Reply
#2
FB'S COMMON supports only dynamic arrays.
I read it, can't remember where...
Fortunately differnt people remenbers different parts of the specs, and all togheter make a complete manual. Recalls me Fahrenheit 451 Big Grin
Antoni
Reply
#3
Quote:Fortunately differnt people remenbers different parts of the specs, and all togheter make a complete manual. Recalls me Fahrenheit 451

* Applause *

Any Bradbury references so expertly inserted into the conversations deserve admiration.
ature has its way of warning a person away from danger: The distinct black and white coloration on a skunk, the chilling buzz of a rattlesanke, a redneck handing you his beer and saying "Watch this!"
Reply
#4
Quote:Any Bradbury references so expertly inserted into the conversations deserve admiration.

It would if Ray Bradbury didn't totally suck.

subxero: Common sucks and is bad programming habit. You should pass the list of surfaces as a parameter instead of referencing them as an external list.
Life is like a box of chocolates', hrm, WTF, no it isn't, more like, 'life is like a steaming pile of horse crap.'
Reply
#5
Quote:subxero: Common sucks and is bad programming habit. You should pass the list of surfaces as a parameter instead of referencing them as an external list.

Agreed 1000^1000%.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#6
Yaya, and GOTO is bad.. yadda yadda..


Not everyone knows how to do fancy pointers and stuff..
We use what we've always used, and it works :lol:

Atleast I do..



And btw, did you know, in fb < 0.11, you could use redim on static arrays... weird...
Reply
#7
No pointers, just extra parameters. That way it's easier to get track of your data. At least for me. I don't like having a bunch of inter-module globals. You end not knowing where the data belongs to.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#8
Oh.. you mean like
Code:
MySub arg1, arg2, array()

Sry, my bad, thought you meant some fancy pointer thingy stuff blarg Big Grin
Reply
#9
Quote:
1000101 Wrote:subxero: Common sucks and is bad programming habit. You should pass the list of surfaces as a parameter instead of referencing them as an external list.

Agreed 1000^1000%.
For once I agree with you. COMMONs, GOTOs should never be used! Unless absolutely essential :roll:
Reply
#10
The COMMON can be in the include file, but the DIM SHARED shouldn't be. The variable should be DIMmed only in one module.

Like so:
Quote:DECLARE SUB printBlah
COMMON SHARED blah
DIM SHARED blah

blah = 2
printBlah
END
Quote:DECLARE SUB printBlah
COMMON SHARED blah

SUB printBlah
PRINT blah
END SUB
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)