Path: utzoo!attcan!uunet!nuchat!moray!urchin!p4694.f506.n106.z1.fidonet.org!Lynn.Lively
From: Lynn.Lively@p4694.f506.n106.z1.fidonet.org (Lynn Lively)
Newsgroups: comp.lang.c
Subject: Re: structure typedefs
Message-ID: <19042.261CB815@urchin.fidonet.org>
Date: 5 Apr 90 16:41:53 GMT
Sender: ufgate@urchin.fidonet.org (newsout1.26)
Organization: FidoNet node 1:106/506.4694 - Fulcrum's Edge, Spring TX
Lines: 62

In an article of <29 Mar 90 23:52:37 GMT>, goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes:

 BG>Of course, whether naming structs and types in this manner is good
 BG>programming practice is another question entirely.  The coding
 BG>standards for the project that I work on require that we always
 BG>create a typedef for any structs we invent.  Whenever possible (which
 BG>is most of the time), the struct itself has no self-references and
 BG>can thus be unnamed:
 BG>
 BG>        typedef struct
 BG>
 BG>        {
 BG>        a_type  a;
 BG>        b_type  b;
 BG>
 BG>        }       foo_bar_type;
 BG>
 BG>
 BG>Only when there is need for self-reference does the structure get a
 BG>name, and to avoid confusion that name is produced by replacing the
 BG>"_type" in the typedef name with "_tag":
 BG>
 BG>        typedef struct foo_whiz_tag
 BG>
 BG>        {
 BG>        a_type                  a;
 BG>        b_type                  b;
 BG>        struct foo_whiz_tag *   next;
 BG>
 BG>        }       foo_whiz_type;
 BG>

 Bob,
     Another good way of doing it (The one I use) is to have the name of the  
typdef in all caps (like FILE is in stdio.h). If I have a self reference i  
often use the suffix _elem to the lowercase of the type name.

typedef struct list_elem
  {
    ... other fields ...
    struct list_elem * next;
  } LIST;

BTW: I'm currently working on a project using DG C compiler and and generally  
very pleased, but there is one thing that I didn't much like. The way the  
VARARGS macros are set up are not consistent with ANSI (At least, not with the  
reference I have on it (Mark Williams ANSI C Reference)), I have written a set  
of my own that are compliant if you're interested. Also I think there might be  
a bug in your implementation of va_start(), you (DG C, not you personally) add  
1 to the pointer which backs up to the item before the rightmost known  
argument, but the vsprintf() (The only 'v' function I used so far) seems to  
expect the address of the rightmost known argument. This caused me a good deal  
of problems before I rewrote the macros. Also, is there another manual I  
should have besides the C reference and C standard runtime library reference?  
Some of the functions are hardly mentioned (of course the ones I'm interested  
in using (specifically the multi-tasking functions)), I've been gleaning what  
information I can from the header files but this is slow going. Any help would  
be appreciated (BTW: Thanks for WORM.C and DINNER.C they may save me, in that  
they are GOOD example programs).
 Your Servant,
      Lynn