reg@vaxine.UUCP (Rick Genter) (03/01/84)
<This line intentionally left non-blank.>
In the past there have been various coding style discussions (arguments?
abuse?) regarding features such as indentation, where to put the braces, etc.
I now wish to bring up an issue which I have not seen raised before, but find
to be fairly important.
What is the opinion of the net community regarding the use of typedefs? I
am currently working on a project involving a *very* large software system
(roughly 100,000 lines of C code). Most of the types have been typedef'd to
more meaningful names. This is fine except for one specific case:
typedefING ARRAY TYPES SUCKS.
Perhaps I should explain. There are places in the software system I am
working on which want to use a data structure as an array (mostly looping over
the elements on the array to perform some operation on all elements of the
array). There are also places which want to use the same data structured as a
struct (compute some equation using the 2nd and 5th element of a 6 element
array).
When a typedef represents a struct, I don't have much trouble. For
example, if I have:
typedef struct {
float thing1;
float thing2;
float thing3;
float thing4;
float thing5;
float thing6;
} Things;
then it's nice to say:
Things group;
group.thing3 = group.thing5 - group.thing4;
Manipulate (& group)
Manipulate (g)
Things *g;
and so on. Now look what happens when I have:
typedef float Things[ 6 ];
Things group;
group[ 3 ] = group[ 5 ] - group[ 4 ];
Manipulate (group) <- If I put the &, I get a warning from cc
Manipulate (g)
Things g; <- If I put the *, I get something totally
different that what I want!
I guess the problem boils down to the fact that arrays are treated
differently than any other type in the language. I have heard complaints
registered against C since structures became lvalues, but at least structs end
up getting treated more like all other types, such as:
If I want the address of the struct, I say & struct;
If I want a pointer to a struct, I say * struct;
If I want to pass a struct, I say routine(struct);
Getting back to my original question, what are the attitudes of other
hackers towards typedefs? After hacking at a lot of the code in this software
system (about 1/3 of it) I am finding that I would be much better off (and the
code would be much more readable) if the structs are typedefd but the arrays
aren't. Are there any other reasonable alternatives?
Rick Genter
Automatix Inc.
...!linus!vaxine!reggreg@sdcsvax.UUCP (03/02/84)
In general, typedefs should be avoided. There are only a couple of cases where typedefs make sense -- primairly to improve transparency or to provide portability. Another way of saying the same thing is that if you ever make use of the fields of a typedef, then you should NOT be using typedefs. Only if you always use the object as a primitive are typedefs proper. Typedefs are one way that C begins to lean toward more modern forms of structuring, like information hiding. But like many of the tools provided by C, it must be used with care and discipline. Typedefs draw a very thin veil over the actual definition of the object. It is thin enough so that you can see through it if you really need to. The fact that it is there means that you shouldn't need to, unless you are the one that implemented the type (in which case, the functionality should be provided by subroutines or macros with the actual mechanism hidden). Now, don't get me wrong -- typedefs are fun and useful. But the overuse of typedefs can confuse rather than make clearer.
greg@sdcsvax.UUCP (03/03/84)
Oops -- no signature on the referenced article. Here it is: -- Greg Noel, NCR Torrey Pines Greg@sdcsvax.UUCP or Greg@nosc.ARPA
mcewan@uiucdcs.UUCP (mcewan ) (03/16/84)
#R:vaxine:-20800:uiucdcs:27600032:000:1 uiucdcs!mcewan Mar 15 16:40:00 1984