Date: Tue, 22 Oct 1996 08:23:54 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: John Polstra <jdp@polstra.com>, current@freebsd.org Subject: Re: <sys/queue.h> Message-ID: <Pine.SV4.3.93.961022082114.28970D-100000@parkplace.cet.co.jp> In-Reply-To: <9610211437.AA10256@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
For once we agree. ;-) I'll add that inventing tags even when they aren't readily used is a good habit. Regards, Mike Hancock On Mon, 21 Oct 1996, Garrett Wollman wrote: > <<On Sun, 20 Oct 1996 19:37:04 -0700, John Polstra <jdp@polstra.com> said: > > > True, but that's not the point. The point is, at a certain level, > > a type is a type is a type. You shouldn't have to know whether > > it's represented as a struct or as a union or as an array. By > > using a typedef you enforce not knowing the details of the > > representation, making it easier to change that representation in > > the future without having to change a bunch of code. > > Actually, no. typedefs are the ultimate in un-opaqueness. In the C > programming language, I can utter `struct foo' without knowing how > such a structure is defined. I cannot utter `blurfl_t' without it > having previously be defined somewhere. Furthermore, it is not > permissible to twice utter `typedef struct bar bar_t' in a C program. > > The absolute worst-structured program I know (ISI RSVPD) was written > in the `spaghetti typedef' style, and as a result all of its header > files are so entangled with each other that every source file in the > program must include all of them, even in the absence of any > declarations relevant to that source file. I was able to dramatically > clean this up in the version I was working on by simply eliminating > all the typedefs and referring to the structures by their proper tags > (after inventing tags for them) as bwk and dmr intended.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.961022082114.28970D-100000>