CSC161 2010F, Class 20: Control Flow: Miscellaneous

Overview:
* Modifying loop control.
* More extreme modifications with goto.
* Leftover questions.
* New questions.
* Lab.

Admin:
* Sam's approximately weekly rant
* Reading for Friday: K&R 4.1-4.3.
  * By 9pm Thursday, send one of the following three messages
    * I did not understand the following: ....
    * The reading seemed clear.
    * I did not do the reading by 9pm.  I'll do better next time.
* EC for this week's CS Extra on Drupal.
* EC for this week's Convocation on Chemistry.
* Office hours shifted until 2:00-4:00ish today.
* Questions on Exam 1?
  * Can we send you a gzipped tarball?
    * Yes.
  * How are we supposed to get you the paper copy at 11 p.m.?
    * Under my door is fine.
  * Is it okay if we forge the timestamp on the email?
    * I wonder how you sign the academic honesty statement.
  * Does our RPN calculator need to take command-line inputs?
    * No.
  * Can we assume that each input is followed by whitespace, so that
    we don't have to deal with +- or 23+ ?
    * Yes

Leftover questions

* How do you decide when to make a function void and when to 
  make a function return int?
  * If it's computing a value, you should return an int
  * If it's not computing a value, but you want to return information on
    the process, you should return an int
    E.g., scanf, a process that might fail.
  * If there's no reason to return anything, use void
* What is /=?  Did we learn this and I just forgot?
  x /= exp is a shorthand for x = x/exp;
* j-=gap is in the place that would be occupied by increment things, but I don't know what j- is.  Or perhaps it is -=.  
  * Interesting error in the early design of C
    -= and =- were the same operator
    += and =+ ...
    i=-2
* I don't quite understand comma operators.  They seem to have something to do with two things being connected, or perhaps both true.  I don't understand the advantage of using 
  c=s[i], s[i]=s[j], s[j]=c;
as opposed to 
  c = s[i];
  s[i] = s[j];
  s[j] = c;"
  * It means "Do this then this then this" (an alternate to ; for sequencing operations)
  * We use it in places in which we can only have one statement, such as in the initialization or increment part of a for loop.
* I don't understand ShellSort.  Or maybe I just don't understand
  nested loops.
  * Too bad, so sad

Modifying loop control.

* Sometimes we want to exit a loop "in the middle"
  * We've designed an infinite loop
  * E.g., we're looking through a file or array for something and we
    find it.  We don't need to look through the rest.
  * Solutions:
    * break;
      while (test())
        {
          if (found ())
            break;
        }
    * Sentinel
      done = false;
      while (test() && !done)
        {
          if (found_whatever())
            done = true;
        }
* Sometimes we want to exit one iteration of the loop, but keep looping
  * An invalid value, but there may be useful values later
  * One strategy: continue
    while (val = getvalue())
      {
        if (invalid (val))
          continue;
        stuff_for_valid_values (val);
        more_stuff_for_valid_values (val);
      }
  * One verbose alternative Write a helper procedure
    while (val = getvalue())
      helper (val)
    void 
    helper (value val)
    {
      if (invalid (val))
        return;
      stuff_for_valid_values (val);
      more_stuff_for_valid_values (val);
    }
  * What's the alternative if we don't use continue?
    while (val = getvalue())
      {
        if (invalid (val))
          ;
        else
          {
            stuff_for_valid_values (val);
            more_stuff_for_valid_values (val);
          }
      }
* If we don't need them, why do we have them?
  * They can make code easier to read / cleaner.
  * And if K&R don't like them, why do we have them?
    * They don't like wild use of them, which leads to more confusing code.
    * It's hard to trace code with lots of continues and breaks.
    * It's hard to analyze code with lots of continues and breaks.

More extreme modifications with goto.
* Famous paper: "Goto considered harmful"
  Biggest problem: When you reach a point in the program, you may not
    know how you got there, so it's hard to analyze anything about what's
    known or not known.

  while (x < 10)
    { 
      ...
    }
  // what do I know about x at this point?
  // Without break: x>=10
  // With break: Nothing

  if (x > 0)
    x = -x;
foo:
  // What do I know about x at this point?
  // Without goto: x <= 0
  // With goto: Nothing

New questions

* Why do we use labels and goto?
  As a convenient way to escape from bad situations

Lab!