Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP
Newsgroups: comp.lang.c
Subject: Re: portability and standards
Message-ID: <1103@killer.UUCP>
Date: Mon, 6-Jul-87 14:35:46 EDT
Article-I.D.: killer.1103
Posted: Mon Jul  6 14:35:46 1987
Date-Received: Sat, 11-Jul-87 16:44:27 EDT
References: <2290@calmasd.GE.COM> <4715@columbia.UUCP> <107@snark.UUCP>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 78
Summary: Just why did I get a degree? Or When Do I Get To Use Goto's and Global Variables?

In article <107@snark.UUCP>, eric@snark.UUCP (Eric S. Raymond) writes:
> In article <3399@ihlpg.ATT.COM>, bgb@ihlpg.UUCP writes:
> >
> > [a sensible technique for preventing inconsistencies in globals usage]
> >
> 
> I submit, though, that this whole discussion rests on a false premise --
> that it is somehow a Good Thing to have a separate globals module with no code.
> Every time I've seen such a module it has been evidence for poor data
> design in the program. Globals are bad style, the data design equivalent
> of goto statements.

I have written code that needs goto's to keep from growing into a massive
maze of if-then-else's, unneeded functions, and totally unreadable code.

The goto is nice when you want to give up, or handle a special case - if you
go using it as a way to avoid for, while and do loops you need to have
your head examined for remnants of FORTRAN or BASIC.

But then I follow some-body-or-other's advice and *document* my goto's with
come-from's - i.e. How Did I Get Here? 

> The major difference between abstract data type (ADT) decomposition and the
> more primitive kind of functional decomposition that Algol-descended languages
> like Pascal and C were designed to support is precisely the status of
> global data.

I thought C came from BCPL?  And besides, what the h*ll is he saying here?
I used globals in Pascal whenever they were needed.  Some variables get to
be a real bother to pass all over gods creating, and wrapping them up into
a big structure you pass all over the place is a bother.
 
>  In fact, in
> an ADT design environment you quickly develop a perception that globals
> are ugly, because they represent places where the data elements of what
> should be ADTs are leaking into each other.

All this is good and fine for toy code.  No, I take that back.  Somethings
*do* work as ADT's very well.  But the entire world does not live in ADT
land.  What do you do with a simple status variable like errno that is
modified by all of the system calls?  Add pointers in the file status
blocks to all point to errno?  Ask a VMS programmer wether they prefer
FAB's and RAB's to file descriptors and errno.
 
> [Returning to earth now...]

Please do.

> C wasn't particularly designed for ADT building, but it's powerful enough
> to support it pretty well. In my C code, each .c source file implements an
> ADT and has an associated .h file that defines the interface.
> [ stuff deleted ] There may be lots of data areas that are
> publically visible, but there are no 'globals' that aren't definitely owned
> by some ADT somewhere.

Sounds like nice design, when it applies.  But what if the variable has
to live for quite a while, is used by 15 or 20 routines, and isn't all
that abstract?  For example, a file descriptor returned by a special file
open routine?

> I find this approach leads to code that is cleaner, better organized and
> much easier to maintain. The mental effort required to identify would-be
> 'globals' as part of an ADT including their handler code is usually
> fairly trivial, nor is there any run-time overhead necessarily involved
> in partitioning things this way.

I suppose all of the ADT glue is useful for libraries and packages that are
used many times, and may have many different functions.  Well de[fs]i(n|gn)ed
interfaces do not exclude global variables however.  Nor do global variables
have to produce unreadable code. That seems to be what /* */ are for - to
add some intelligence to the source code.  The most readable code I've
seen has tended to be assembler - for just that reason.  Every assembler
programmer I know has always documented well, even to excess in many
occasions.  The best C code is the same way.  Look at the source for
the chess program that was just posted.  I seem to remember that it was
well documented.  That or rogue, I forget ...

- John.