bevan@cs.man.ac.uk (Stephen J Bevan) (01/30/91)
In article <1991Jan29.210100.8105@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes : > In article <1212@tredysvr.Tredydev.Unisys.COM> > paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) writes: > >Can anyone also tell me what is the most common style convention for type > >names, I usually put them all in capitals. > > Insofar as there is a consensus, it's to put them in lower case with a > suffix "_t", e.g. "uid_t" as the type for userids. What is the purpose of the "_t" ... etc. postfixes ? It obviously makes any variables defined by a typedef'd type very clear, but is that important? I think not. ``Recommended C Coding Standards''(v5.3) mentions them in section 11, but only says ``Typedeffed names often have "_t" appended to their name''. I'm still left with the question, why have postfixes? Stephen J. Bevan bevan@cs.man.ac.uk
henry@zoo.toronto.edu (Henry Spencer) (02/01/91)
In article <BEVAN.91Jan30084205@rhino.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes: >What is the purpose of the "_t" ... etc. postfixes ? >It obviously makes any variables defined by a typedef'd type very >clear, but is that important? I think not. The purpose is the same as the convention of using uppercase for macro names: to give the poor programmer a little bit more help in figuring out what's going on, and to minimize namespace collisions. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (02/01/91)
In article <BEVAN.91Jan30084205@rhino.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes: >What is the purpose of the "_t" ... etc. postfixes ? >It obviously makes any variables defined by a typedef'd type very >clear, but is that important? I think not. Some people find it helpful, others don't. The primary legitimate reason for this convention is to ensure that type names do not collide with other uses of identifiers. Unfortunately, systems that have <sys/types.h> (e.g. POSIX ones) generally allow the inclusion of <sys/types.h> to define a large number of nonstandard type names, so that in a program including that header it is in fact UNWISE for the application itself to define its own names of the form *_t. This is yet another aspect of the "name space pollution" issue, brought somewhat under control by X3J11 and to a lesser extent by P1003(.1), but still a real problem for C applications.
avery@netcom.COM (Avery Colter) (02/08/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >systems that have <sys/types.h> (e.g. POSIX ones) generally allow the Hmmmm, must mean ORCA/C is a POSIX compiler. I do know the <types.h> in that one mainly defines types of use to the native toolbox, while the _t types are mainly scattered throughout the header files which use them the most, i.e. time_t and clock_t in <time.h>, div_t and ldiv_t in <math.h>, etc. -- Avery Ray Colter {apple|claris}!netcom!avery {decwrl|mips|sgi}!btr!elfcat (415) 839-4567 "I feel love has got to come on and I want it: Something big and lovely!" - The B-52s, "Channel Z"
avery@netcom.COM (Avery Colter) (02/08/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >The purpose is the same as the convention of using uppercase for macro >names: to give the poor programmer a little bit more help in figuring >out what's going on, and to minimize namespace collisions. It might be, since these seem to be so widespread, that the standards committee might have sanctioned certain of these xxx_t types as being standard parameter or return types of some of the standard library functions. In the same way that FILE, a typedef'd structure, is the standard type for a filename under <stdio.h> -- Avery Ray Colter {apple|claris}!netcom!avery {decwrl|mips|sgi}!btr!elfcat (415) 839-4567 "I feel love has got to come on and I want it: Something big and lovely!" - The B-52s, "Channel Z"
gwyn@smoke.brl.mil (Doug Gwyn) (02/09/91)
In article <23133@netcom.COM> avery@netcom.COM (Avery Colter) writes: >gwyn@smoke.brl.mil (Doug Gwyn) writes: >>systems that have <sys/types.h> (e.g. POSIX ones) generally allow the >Hmmmm, must mean ORCA/C is a POSIX compiler. I do know the <types.h> >in that one mainly defines types of use to the native toolbox, >while the _t types are mainly scattered throughout the header files >which use them the most, i.e. time_t and clock_t in <time.h>, >div_t and ldiv_t in <math.h>, etc. Aargh! <sys/types.h> and <Types.h> are NOT synonymous. ORCA/C does not provide <sys/types.h>. ANSI C requires that certain *_t types be defined in certain standard headers, and as an honest attempt at a conforming implementation, ORCA/C does just that. Note that APW <Types.h> follows no canonical pattern in the name space that it usurps, unlike the *_t convention (mostly) followed by POSIX <sys/types.h>. (There are some "modifier" patterns for denoting derived types such as "pointer to" and "handle for".)
gwyn@smoke.brl.mil (Doug Gwyn) (02/09/91)
In article <23134@netcom.COM> avery@netcom.COM (Avery Colter) writes: >It might be, since these seem to be so widespread, that the standards >committee might have sanctioned certain of these xxx_t types as being >standard parameter or return types of some of the standard library >functions. Yes, the C standard does that. However, the types are associated with relevant standard headers rather than a separate <sys/types.h>.
greywolf@unisoft.UUCP (The Grey Wolf) (02/14/91)
Is there/will there ever be a compile-time / cpp-time evaluation as to
what types are defined? For example:
#if typed(stat_t)
.
.
#endif /* typed(stat_t) */
or even:
#if typed(struct stat)
.
.
#endif /* typed(struct stat) */
This would eliminate the need for putting that stuff in .h files like
#ifndef _STAT_H_
#define _STAT_H_
.
.
.
#endif /* !_STAT_H_ */
There are many times I've wanted such a beast.
Also, do typedefs ever make it into an object's/executable's nlist?
'Twould be real nice to be able to determine defined types from the
nlist of the compiled code.
--
thought: I ain't so damb dumn! | Your brand new kernel just dump core on you
war: Invalid argument | And fsck can't find root inode 2
| Don't worry -- be happy...
...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolfkarl@ima.isc.com (Karl Heuer) (02/14/91)
In article <3377@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >Is there/will there ever be a compile-time / cpp-time evaluation as to >what types are defined? For example: >#if typed(stat_t) ... Unlikely. In the traditional implementation, the preprocessor has no way of knowing anything about declared types. >This would eliminate the need for putting that stuff in .h files like >#ifndef _STAT_H_ A simpler solution would be to make typedefs idempotent, like macros. (Since a conforming implementation must already handle nested-scope typedefs like typedef int foo; void f(void) { typedef int foo; } I doubt that handling same-scope typedefs correctly would be any worse.) Unfortunately, ANSI didn't define it that way, so the best you can do in a portable header is to use a guard macro. >Also, do typedefs ever make it into an object's/executable's nlist? I believe some compilers will do this if debugging is enabled. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
gwyn@smoke.brl.mil (Doug Gwyn) (02/15/91)
In article <3377@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >Is there/will there ever be a compile-time / cpp-time evaluation as to >what types are defined? >#if typed(stat_t) No, because there ARE no types during preprocessing. >There are many times I've wanted such a beast. Lots of people would like it, too, but it would be a substantially different language. Keep this in mind when designing a new general- purpose programming language. >Also, do typedefs ever make it into an object's/executable's nlist? Different object file formats have different support for this, but note that a typedef does NOT define a new type, merely an identifier that can be used to represent existing types. Thus no "strong typing" of such types is permitted, which limits its utility for debugging etc.
chip@tct.uucp (Chip Salzenberg) (02/16/91)
According to karl@ima.isc.com (Karl Heuer):
>A simpler solution would be to make typedefs idempotent, like macros.
For what it's worth, this solution is used in C++.
--
Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
"I want to mention that my opinions whether real or not are MY opinions."
-- the inevitable William "Billy" Steinmetz