9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Installing the updates
Date: Tue,  1 Aug 2000 09:32:35 -0700	[thread overview]
Message-ID: <200008011632.MAA24052@cse.psu.edu> (raw)
In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU>  of "Tue, 01 Aug 2000 12:03:38 EDT."References: <200008011603.MAA05857@egyptian-gods.MIT.EDU>  <200008011603.MAA05857@egyptian-gods.MIT.EDU>

> It would be nice if Pike could present a compelling argument. 
> [...]
> Where's the horror here?  Computers are fast.  Pushing extra work on
> programmers and creating an unnecessary portability issue is a high
> cost.  Reading a header file five or more times during compilation is
> a low cost (and one which can be optimized away for ifdef-protected
> headers; I'm told gcc does so).

The horror is that many header files don't get 'the dance' right. Even OS
header files are screwed up sometimes. Before I read Notes on Programming
in C I had put all #include calls into my program's local header file
because that was how I had always seen it done.  When I started writing
libraries, I found all kinds of problems with the compiler complaining
about multiple definitions (both my own and the system headers).

I think it even makes good sense from an interface perspective. The header
file shows the interface for program file. The program should hide all
the implementation details, which means you shouldn't be able to tell
which system calls the program makes to get the job done. Realizing that
you keep including the same files may also force an eye toward keeping
solid boundries across the different files (one does x, and only x. The
next only handles y).  Of course, if the file hides a bad job (say,
calls to strtok(2)) then you're screwed anyway.

Why do people object to this rule? It's not hard to follow, right?
It's really not that much extra work, in my opinion. Of course there
are a few that always get included, stdlib for example, but I've found
only a few overlaps in a library I've just written. It's spread over
9 files, and you can see that there isn't *that* much overlap:

; grep '#include' *.c|cut -d: -f2|sort|uniq -c|sort -nr
      8	#include <stdlib.h>
      5	#include <string.h>
      5	#include <limits.h>
      5	#include <errno.h>
      4	#include <unistd.h>
      4	#include <sys/types.h>
      4	#include <sys/stat.h>
      4	#include <stdio.h>
      4	#include <fcntl.h>
      2	#include <time.h>
      2	#include <stdarg.h>
      2	#include <pthread.h>
      1	#include <sys/poll.h>
      1	#include <sys/file.h>
      1	#include <strings.h>
      1	#include <ctype.h>
      1	#include <assert.h>

Jim


  reply	other threads:[~2000-08-01 16:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-31 15:15 rob pike
2000-08-01  8:53 ` Douglas A. Gwyn
2000-08-01 12:12   ` Howard Trickey
2000-08-02  9:11     ` Douglas A. Gwyn
2000-08-01 14:31   ` Ralph Corderoy
2000-08-01 16:03     ` Greg Hudson
2000-08-01 16:32       ` James A. Robinson [this message]
2000-08-01 17:05         ` James A. Robinson
2000-08-02  9:39       ` Douglas A. Gwyn
2000-08-02  9:11     ` Douglas A. Gwyn
2000-08-03 14:51     ` ozan s. yigit
  -- strict thread matches above, loose matches on Subject: below --
2000-08-02  9:47 forsyth
2000-08-02  9:52 ` Boyd Roberts
2000-08-01 17:06 Russ Cox
2000-08-02  8:32 ` Bruce G. Stewart
2000-08-01 16:27 rob pike
2000-08-02 10:53 ` Ralph Corderoy
2000-08-01 16:26 rob pike
2000-08-02 21:49 ` Steve Simon
2000-08-01 13:35 rob pike
2000-08-01 18:34 ` Greg Hudson
2000-08-02  9:53 ` Douglas A. Gwyn
2000-08-01 13:06 rob pike
2000-08-01 13:10 ` Lucio De Re
2000-08-01 12:55 rob pike
2000-08-02  9:39 ` Douglas A. Gwyn
2000-08-01  6:04 Russ Cox
2000-08-01  5:42 Russ Cox
2000-07-31 17:09 Russ Cox
2000-07-31 15:57 jmk
     [not found] <djhender@telusplanet.net>
2000-07-31 14:53 ` Doug Henderson
2000-07-31 17:38   ` Scott Schwartz
2000-07-31 20:10     ` Steve Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200008011632.MAA24052@cse.psu.edu \
    --to=jim.robinson@stanford.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).