BBC BASIC for Windows
Programming >> BBC BASIC language >> Local DIM
http://bb4w.conforums.com/index.cgi?board=language&action=display&num=1369463347

Local DIM
Post by Matt on May 25th, 2013, 06:29am

Hi,

In a procedure, what's the difference between:

1.
Code:
LOCAL text%
DIM text% 255 


2.
Code:
LOCAL [none]
DIM text% LOCAL 255 


Would this normally accomplish the same thing?

Matt
Re: Local DIM
Post by admin on May 25th, 2013, 07:37am

on May 25th, 2013, 06:29am, Matt wrote:
Code:
LOCAL text%
DIM text% 255 

Code:
DIM text% LOCAL 255 

Would this normally accomplish the same thing?

No, the two uses of LOCAL are completely different; they just happen to share the same keyword. LOCAL text% makes the variable text% local, DIM text% LOCAL 255 makes the allocated memory local, i.e. it allocates it from the stack rather than from the heap. As a rule you would want to make the variable local as well, so typically you'd have:

Code:
      LOCAL text% : REM Makes text% local
      DIM text% LOCAL 255 : REM Allocates memory from the stack 

Richard.
Re: Local DIM
Post by Matt on May 25th, 2013, 1:12pm

on May 25th, 2013, 07:37am, Richard Russell wrote:
DIM text% LOCAL 255 makes the allocated memory local, i.e. it allocates it from the stack rather than from the heap.


As they both work, and I would assume that they are both acceptable, why would you rather have the memory allocated from the stack? Is there a potential problem, or is just good practice?

Matt
Re: Local DIM
Post by admin on May 25th, 2013, 5:29pm

on May 25th, 2013, 1:12pm, Matt wrote:
Is there a potential problem, or is just good practice?

There's a massive potential problem - a memory leak! As a rule you never have a choice of when to allocate memory from the heap or the stack; for example if you're allocating memory inside a PROC or FN it will generally be essential to allocate it from the stack. A memory leak is the very last thing you want because it's so insidious - it may not be noticed until your program eventually crashes maybe days or months later!

Richard.