🚀 go-pugleaf

In comp.lang.c article <816208586snz@genesis.demon.co.uk>,
Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
> In article <485hl3$6e7@news0.rain.rg.net> plong@perf.com "Paul Long" writes:

...

> >You're getting close to situation indicators, which I would prefer if
> >I were defining a new language. I think labeled loops are a hack--I
> >would want something both more general and unified, not optional
> >clauses to sundry existing constructs.
> 
> This imposes the same limitation of having to use compound statements as
> the first suggestion.

This is a very strange argument.  Is it really that onerous to include a
control variable that decides whether or not a given level of looping is to
be broken out of?  I speak of a construction such as:

int loop = 0;

for(;;)
{
  loop++;
  while(whatever)
  {
    loop++;
    while(something)
    {
      loop++;
      if(getout)
      {
        loop = 0;
        break;
      }
    }
    if(loop < 2) break;
  }
  if(loop < 1) break;
}

You can construct #defines to handle variable management, and use enums to
handle loop level labels.  All the tools are there for the price of a short
#include file such as:

/*  Filename brkloop.h */
enum looptype_e = {0=outside, firstloop, secondloop, thirdloop};
typedef enum looptype_e looptype;

#define loopcontrol looptype _loop
#define breakout(a) if(_loop < (a)) break
#define newloop _loop++
#define breakto(a) _loop = (a); break

and you wind up with code such as:

#include <brkloop.h>

loopcontrol;

for(;;)
{
  newloop;
  while(whatever)
  {
    newloop;
    while(something)
    {
      newloop;
      if(getout)
        breakto(outside);
      if(gettofirstlevel)
        breakto(firstloop);
      else
        breakto(secondloop);
    }
    breakout(secondloop);
  }
  breakout(firstloop);
}

Simple and straightforward.  Any more elaborate solution can be solved with
the notorious goto command, or setjmp(), and amounts to the same thing.  Is
it not more sensible to use the language tools available to handle the job
with minimal fuss and no extra keywords? I use a similar #include file to
allow the inclusion and retention of heirarchial debugging fprintf()
statements in my programs that can be activated from the command line on
demand to track down problems.  Sure, it increases the size of the
executable, but it has little impact on development time or performance,
and saves time on maintenance and debugging, which are the real time-sinks
involved.

Language extensions that make tracing code more difficult make my skin
crawl, especially when they are unnecessary.  #include files and libraries
can be constructed to handle any task, as long as you're not too lazy to
use the facilities at your disposal.  These kinds of libraries and files
are the work of a half-hour, on a one-shot basis, so surely the investment
in time is insignificant.

-- 
              David C. Wright | wrightd@merlin.magic.mb.ca

    As we anarchists say: "There's no government like no government."