Continue does not return to top of loop

[MichaelHooker]

Please bear with me, I only program occasionally - usually two new versions of Delphi come out between my programming stints! I'm using v7 now.

I have a simple but long for loop, which goes like this:

for i := 1 to StrList.Count - 1 do begin
  
  {(1) reads string i from a stringlist - this represents a row of data imported from a SQLite3 database in tab-  delimited form - and allocates the fields to variables}
  {(2) goes on to examine the variables and reformat them as necessary}
  {(3) a series of tests to see if certain variables, or combinations of variables, meet certain conditions. If they do, I want to abandon the tests and return to the top of the loop to examine the next record without further ado...}

  if Whale < Mouse then continue
  else if MyIncome - MyMortgage < 0 then continue
  else if RomeoLovesJuliet = FALSE then continue
  else if...  {and so on}

  {(4) the next stage further processes the data that has   not been discarded - simple, tedious stuff - and displays it in a Memo for a final check}
end;

I don't like all the "else if" statements but to put all the tests together with ORs would create a novel in one line. I can't think of any way of implementing the CASE statement, which is rather inflexible in Delphi. However, the issue is that when a condition is met, "continue" does not skip back to the top of the loop. The unwanted data moves on to step (4) and ends up in the final output.

Obviously I'm doing something wrong, but my coding fits in with the Help and every example I can find. Does anyone have any idea what is happening here, please?

Thanks
Michael Hooker

 

[sggaunt]

To be honest I would think there is very little advantge in using continue. You are still doing all the tests.

I would do it this way..

for i := 1 to StrList.Count - 1 do 
  begin
    if (Whale < Mouse) or
       (MyIncome - MyMortgage < 0) or
       (RomeoLovesJuliet = FALSE) or 
       {and so on}
         begin
           // count the errors or whatever
         end
    else
       begin
         // process the valid stuff
       end;
  end;

Steve [The sane]: Delphi a feersum engin indeed.

 

[MichaelHooker]

there is very little advantge in using continue. You are still doing all the tests

Thanks, but that is exactly the issue. Continue is supposed to go back to the top of the for loop for the next iteration. That's what the Delphi Help says. I'm trying to understand why it doesn't . Maybe I should rephrase the question as: "how do I skip back to the top of the loop for the next iteration and avoid time-consuming unnecessary processing if continue doesn't work?".

I suppose I could skip over the remaining tests with a GOTO EndOfLoop but we're told we shouldn't use GOTO - when we're provided with things like "continue" we shouldn't need to, right?

The nature of the tests, which I didn't explain in detail before, means that going through the whole lot puts some previously-excluded records back into the "wanted" category because they pass one or more of the later tests. The combination of ANDs and ORs that would be necessary to avoid this is pretty mind-boggling, though I could probably short-circuit some of it by declaring a three-state flag WANTED, UNWANTED and CHECK . Boolean TRUE/FALSE won't do. Some of the records can be allocated WANTED/UNWANTED programatically, but the nature of the beast is that some inevitably need user-intervention because they are incomplete or need manual correction. At the moment I'm getting presented with far too many records for my decision which should have been excluded.

Michael Hooker

 

[Glenn9999]

Is there some inner loop that you're not showing? Continue only applies to the loop that it is present in.

 

[sggaunt]

Don't you need to do a 'break' to 'continue' from?


Steve [The sane]: Delphi a feersum engin indeed.

 

[MichaelHooker]

Don't you need to do a 'break' to 'continue' from?

Continue and Break are different varieties of the same thing. Break breaks out and carries on after the end of the loop - it doesn't go back to the top of a loop and continue it.

Anyway, I have just investigated the rather more helpful Help in D2005. It seems that under D2005 I might have got Error 2097:

The compiler has found a BREAK or CONTINUE statement which is not contained inside a WHILE or REPEAT loop. These two constructs are only legal in loops.

program Produce;

procedure Error;
var i : Integer;
begin
i := 0;
while i < 100 do
INC(i);
if odd(i) then begin
INC(i);
continue;
end;
end;

begin
end.

The example above shows how a continue statement could seem to be included in the body of a looping construct but, due to the compound-statement nature of The Delphi language, it really is not.
program Solve;

procedure Error;
var i : Integer;
begin
i := 0;
while i < 100 do begin
INC(i);
if odd(i) then begin
INC(i);
continue;
end;
end;
end;

begin
end.

Often times it is a simple matter to create compound statement out of the looping construct to ensure that your CONTINUE or BREAK statements are included.

That's going to take some thinking about... As far as I can see my code should be OK, but there is a lot of it and my head's starting to hurt again.

Michael Hooker

 

[sggaunt]

Well no you don't need a break before a continue but that might be the way to code it.

Your 'continues' are inside the loop as far as I can see. The example code you posted lacks a 'begin' that's why there is an error, your code does have a 'begin' and 'end' containing the continue. Unless as Glenn says you are not showing everything.


This code has nested loops, the inner loop will 'break' if the condition is met, if this has happened the last 2 steps in the outer loop must not execute. A flag set before the break forces a continue. It cannot be inside the inner loop or the wrong loop would do the continue.
This is working code, perhaps only one 'continue' is valid in a loop? Continue should (and as you can see here) work in 'for' loops as well.

  For a := 1 To Length(phrase) do
      begin
         If copy(phrase, a, 1) = ' ' then
            begin
               Temp := copy(phrase, Pos, a - Pos);
               Pos:= A + 1;
               f := false;
               for b := 0 to 100 do
                   if lowercase(Temp) = lowercase(IgnoredList[b]) then
                      begin
                         f := true;
                        // showmessage('ignored word '+ temp+ ' found');
                         break;
                      end;
               if f then continue;
               inc(num);
               inputword[num] := Temp;

            end;
      end;

I have to say this is the only time I have used continue!

But as I said before you could still end up executing most or all of your tests.


Steve [The sane]: Delphi a feersum engin indeed.

 

[MichaelHooker]

you don't need a break before a continue but that might be the way to code it.

But if you've broken out of the loop, continue won't have anything to continue, will it? There is only one loop here.

Unless as Glenn says you are not showing everything.

None of the "else if" lines have anything but a comparison test - nothing more complicated than:

else if (x=y) OR (Flag = TRUE) then continue

I deliberately kept it simple because, apart from the fact that simple means easier to follow, I wanted to be easily able to comment out some tests or insert new ones, or re-arrange them and see the effect.

I think I'll try again with a series of plain vanilla "ifs" and no "else ifs" - it may be that continue doesn't work once inside an "else" sub-clause.

Anyway, thanks everyone for the help, I'm off to the other PC to carry on trying to sort this one out.

Michael Hooker

 

[DelphiAaron]

according your code the 2nd, 3rd, 4th else is not reached unless all the previous ones are true.

so in essence its

for i := 1 to StrList.Count - 1 do 
 begin
  if (Whale < Mouse) and (MyIncome - MyMortgage < 0) 
   and (RomeoLovesJuliet = FALSE) {and so on} then 
     begin
           // count the errors or whatever
         end
    else
       begin
         // process the valid stuff
       end;
  end;

Aaron

 

[DelphiAaron]

my bad its actually (or) not (and)
same as what sggaunt said, so ignore my post.


Aaron

 

[roo0047]

Whoever told you to avoid the use of GOTO should also have told you to avoid the use of BREAK and CONTINUE.

Complex IF statements can be simplified by breaking them into multiple functions, just as you said; "...simple means easier to follow".

  function ValidAnimal: boolean;
  begin
    result:= (Whale < Mouse)
  end;

  function ValidIncome: boolean;
  begin
    result:= (MyIncome - MyMortgage < 0)
  end;

  function ValidRomance: boolean;
  begin
    result:= (RomeoLovesJuliet = FALSE)
  end;

  function ValidData: boolean;
  begin
    result:= ValidAnimal or ValidIncome or ValidRomance
  end;

procedure SolveIt;
var i: integer;
begin
  for i := 1 to StrList.Count - 1 do
    if ValidData then
      // count the errors or whatever
    else
      // process the valid stuff
end;

 

[MichaelHooker]

Thanks, but...

First I've never used BREAK, it was others who suggested it.

Second I don't have the benefit of any formal training, I have to rely on the advice given in the Help. The Help deprecates GOTO, but not BREAK or CONTINUE. I want to go back to the top of the loop for the next iteration. CONTINUE is the function that does that, and all I wanted to do is make it work as advertised or find an alternative way of returning to the top of the loop. Even without the CONTINUEs, I was under the impression that in an IF...ELSE IF... construction, all further tests in the construction were skipped once one test had been satisfied, which is why it matters what order they are in. It would be called OR IF otherwise. I still don't understand why, as I've been told here, I wasn't skipping the later tests even if the CONTINUE didn't have that effect.

Third, the point of the exercise was to avoid further tests when one is failed. Not to run through a whole series of further tests, some of which could actually put unwanted data back into the final result-set. After much work, I think I've finally managed to avoid that at the expense of having more "doubtful" entries presented for a manual decision. At the end of the day the final decision is not capable of logical resolution in all cases - in some it's a matter of human judgement and experience, but the object of the exercise is to minimise the number of records which require that intervention. It doesn't help that the criteria can vary from day to day either (the weather actually makes a difference).

Fourth, I don't find that your functions easier to follow, quite the opposite in fact. How does your code control the order in which the functions are evaluated and avoid evaluating functions (b), (c), (d), (e), (f) and (g) etc if the result of function (a) is that this particular record is unwanted and need not be processed further?

Thanks

Michael Hooker

 

[roo0047]

First I've never used BREAK, it was others who suggested it.
Second I don't have the benefit of any formal training, I have to rely on the advice given in the Help. The Help deprecates GOTO, but not BREAK or CONTINUE.

We all had to start somewhere. BREAK and CONTINUE do have their purpose, but can be avoided with logic expressions as demonstrated.

I want to go back to the top of the loop for the next iteration. CONTINUE is the function that does that, and all I wanted to do is make it work as advertised or find an alternative way of returning to the top of the loop.

A FOR loop will always return to the top unless interupted by BREAK or an EXCEPTION.

Even without the CONTINUEs, I was under the impression that in an IF...ELSE IF... construction, all further tests in the construction were skipped once one test had been satisfied, which is why it matters what order they are in. It would be called OR IF otherwise. I still don't understand why, as I've been told here, I wasn't skipping the later tests even if the CONTINUE didn't have that effect.

BREAK ... CONTINUE is not relevant to IF ... ELSE. Boolean evaluation depends on directives {$B+} or {$B-} {$BOOLEVAL ON} or {$BOOLEVAL OFF} in Compiler Options. So does the order, not the order you list them in the IF statement.

Third, the point of the exercise was to avoid further tests when one is failed. Not to run through a whole series of further tests, some of which could actually put unwanted data back into the final result-set. After much work, I think I've finally managed to avoid that at the expense of having more "doubtful" entries presented for a manual decision. At the end of the day the final decision is not capable of logical resolution in all cases - in some it's a matter of human judgement and experience, but the object of the exercise is to minimise the number of records which require that intervention. It doesn't help that the criteria can vary from day to day either (the weather actually makes a difference).

Try using other loop controls. WHILE <expression> DO may be more suited for your needs:

  while ValidData and (i <= (StrList.Count - 1)) do begin
    //process the valid stuff
    inc(i);  //next StrList item
  end;

Order can only be guaranteed by seperation (of your IF statements)

  function ValidData: boolean;
  begin
    if ValidAnimal then
      if ValidIncome then
        if ValidRomance then
          result:= true
        else
          //process InValid Romance
      else
        //process InValid income
    else
      //process InValid Animal
  end;

Fourth, I don't find that your functions easier to follow, quite the opposite in fact. How does your code control the order in which the functions are evaluated and avoid evaluating functions (b), (c), (d), (e), (f) and (g) etc if the result of function (a) is that this particular record is unwanted and need not be processed further?

By processing the invalid results within the particular function called:

  function ValidIncome: boolean;
  begin
    result:= (MyIncome - MyMortgage < 0);
    if not result then
      if MessageDlg('Your mortgage is more than you make.  Continue processing?',
                    mtConfirmation, [mbYes, mbNo], 0) = mrYes then
        result:= True  //user override
  end;