Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A For-Next bug in 1.2.8-s682
#13
boriel Wrote:Not exactly: the code that computes the FOR upper limit expression is the same (regardless its static or dynamic calculated on each iteration). The difference is that once it's used it's discarded (dynamic) or must be stored to be reused later (static). Other than that, there's no difference. I was to implement that anyway (there's another thread in this forum asking for that), but leaving the possibility to use a dynamic for if one wants. I meant: can't see why we must enforce dynamic removal once static is the default behaviour.

Found it:
<!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/help-support/topic434.html#p1124">help-support/topic434.html#p1124</a><!-- l -->
boriel Wrote:Notice also that FOR upper limit is evaluated ON EACH iteration (like C). So if len(a$) changes, the loop will shorten. So better use a temporary var l to store initial LEN(a$).

Arrays subscripts starts from 0 to N-1 (like in C). But this behavior can be changed using --sinclair or --array-base switch.

NOTE: I'm planning (for compatibility) an --string-base (so LEN and string-slicing will work exactly as in Sinclair BASIC, by specifying --string-base=1). Also with FOR, stating --constant-for etc...

Then how about evaluating the expression once and have internal variables
for Lower, Higher and Step limits that do not chance as I assume that that
is the traditional way in BASIC, or only the upper limit as the loop is already running. It could make for a speed gain.
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)