Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!rutgers!mcnc!ece-csc!ncrcae!hubcap!hutch
From: hutch@hubcap.UUCP (David Hutchens)
Newsgroups: comp.lang.c
Subject: Re: gotos
Message-ID: <1464@hubcap.UUCP>
Date: 21 Apr 88 14:50:46 GMT
References: <2200@louie.udel.EDU>
Organization: Clemson University, Clemson, SC
Lines: 93

From article <2200@louie.udel.EDU>, by new@udel.EDU (Darren New):
> 
> How about: (pseudocode)
>    for (i = 0; i < max_in_table && key != name[i]; ++i) 
>       if (keypressed()) goto handle_key;
>    seek(helpfile, offset[i]);
>    if (keypressed()) goto handle_key;
>    linecount = 0;
>    do {
>       read_line_from_file();
>       ++linecount;
>       if (keypressed()) goto handle_key;
>       if (read_line[0] == special_flag_char) goto handle_key;
>       insert_spaces_and_color_codes();
>       if (keypressed()) goto handle_key;
>       display_text_line();
>       if (keypressed()) goto handle_key;
>       } while (linecount < 24);
>    handle_key:
>    c = wait_for_key_then_read_it();
>    switch (c) {
>       case 'A': ...
>        ...
>       }
> 
> I contend that if the reading and formatting and displaying are sufficiently
> slow, such behaviour can be desirable (i.e., on microcomputers).
> I would like to see a goto-less version of this that is easier to understand.
>                              - Darren New
>                                Graduate Student
>                                University of Delaware.
> 
>    
  for (i=0; i<max_in_table && key!=name[i] && !keypressed(); i++);
  if (!keypressed()) {  
    seek(helpfile,offset[i]);
    looking_for_flag = 1; 
    linecount = 0; 
    while (looking_for_flag && linecount<24 && !keypressed()) {
      read_line_from_file();
      linecount++;
      looking_for_flag = (read_line[0] != special_flag_char);
      if (looking_for_flag && !keypressed()) {
        insert_spaces_and_color_codes();        
        if (!keypressed()) {
          display_text_line();
        }    
      } 
    } 
  } 
  c = wait_for_key_then_read_it();
  switch (c) {
    case 'A': ...
    ...
  }
 

Consider it done.  The important thing to note is that I don't care
if the precise algorithm you used can be done without a goto.  In
fact, it is the algorithm that is the problem.  It is stupid to
write a piece of code with gotos and then translate it to "structured"
code.  I put structured in quotes because such code is not structured
at all.  Indeed, in my implementation I may call keypressed a second
time after I've already received a true response.  This could be
fixed easily enough with another local variable, but that would just
make it harder to understand.  I did use a looking_for_flag to maintain
some information.  I'm just waiting for the first fool to tell me
it is not as efficient as your solution.  ("I contend that if the
reading and formatting and displaying are sufficiently slow," nobody
could possibly notice these few microseconds.)

The reason you don't see structured solutions is that you allow those
silly gotos to control your reasoning.  I insist on remaining in
charge of my code.

Actually, I'd write the first lines as:
  for (i=0; i<max_in_table && key!=name[i]; i++);
  if (!keypressed()) { ....
since unless max_in_table is a bigger number than the available memory
on most micros (your stated environment) I can check the whole array
in less time than a few calls to keypressed() will take and certainly
in less time than a user will be able to notice.

I also note that there is no action taken in the case that
  i==max_in_table (other than seeking to God knows where).
I suspect missing logic in your code.

In summary, think about the problem and don't let gotos get in the way.

			David H. Hutchens
			Clemson University
			gatech!hubcap!hutch
			hutch@hubcap.clemson.edu