Path: utzoo!attcan!uunet!husc6!mailrus!uflorida!novavax!proxftl!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Efficient coding considered harmful?
Message-ID: <182@twwells.uucp>
Date: 16 Nov 88 12:43:15 GMT
References: <3105@hubcap.UUCP> <34112@XAIT.XEROX.COM> <1700@dataio.Data-IO.COM> <137@twwells.uucp> <1349@mcgill-vision.UUCP>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 50
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <1349@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
: The truth of this depends on what you mean by "structured programming".

Try this version of structured programming: the physical structure of
the program should mirror the logical structure of the program.

: An unfortunately large segment seems to believe that structured
: programming means sticking strictly to certain rules, such as "never
: use a goto, ever" or "no function body larger than a page, ever"
: (though they never say whether terminal page or paper page, curious).
: And, as I am sure you are aware, blind adherence to rules cannot, in
: itself, produce good programs, regardless of the rules.  Good
: programmers write good programs without needing rules; bad programmers
: can't write good programs even with rules.  I suspect their reason for
: existence is that good programmers' output tends to follow them (not
: always, though!), so in a wonderful inversion of cause and effect, some
: people deduce that following the rules will make for good programs.
: (Using such rules as guidelines may also help nudge in-between
: programmers the right way.)

All of which I heartily agree with.

: I have been guilty of going the fixed-size route on occasion, and
: doubtless will be in the future.  Why?  Because allocating requires
: that I know the size ahead of time.  If there were some way to inquire
: of "the system" how much data remains to be read before the next
: newline....but there isn't, and probably never will be.  For most
: programs, the user-interface flaw implied by fgets() is less painful
: than the time it would eat up for me to go the general route.

Write a function to handle it once and for all.  Then always use the
function. This is what I'm going to start doing.

: #if HASHSIZE & (HASHSIZE-1)
:       a %= HASHSIZE;
: #else
:       a &= HASHSIZE - 1;
: #endif
:
: Of course, I daresay there aren't that may hashing algorithms that work
: well for both power-of-two table sizes *and* non-power-of-two sizes.
: But the choice of algorithm is not the point here.

My own feeling is that if HASHSIZE isn't known to be a power of two,
one should live with the %. The alternative is to turn one's code
into a morass of #if's. Ugh.

---
Bill
{uunet|novavax}!proxftl!twwells!bill