paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) (01/30/91)
Is the following statements legal in K&R C, and ANSI C?
typedef char BUFFER[20];
.
.
.
BUFFER sb;
This seems to work on both the K&R compiler and the ANSI compiler at my work
place, but is this going to break when the program is ported?
Can anyone also tell me what is the most common style convention for type
names, I usually put them all in capitals.
Thanks
Paul Siu
paul@tredysvr.tredydev.unisys.comhenry@zoo.toronto.edu (Henry Spencer) (01/30/91)
In article <1212@tredysvr.Tredydev.Unisys.COM> paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) writes: >Is the following statements legal in K&R C, and ANSI C? > typedef char BUFFER[20]; Yes. >... is this going to break when the program is ported? There is probably some old compiler somewhere that will balk. It's impossible to avoid that. (Geoff Collyer and I could tell you some stories about compilers vs. C News...) >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. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
avery@netcom.UUCP (Avery Colter) (02/03/91)
Hmmmmmm....
My instinct right now is telling me that
typedef char[20] BUFFER
is more consistent...
But I'll take the word of the more experienced that the first def
can be done too.
--
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"henry@zoo.toronto.edu (Henry Spencer) (02/03/91)
In article <22642@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: >My instinct right now is telling me that > >typedef char[20] BUFFER > >is more consistent... Nope, syntax error. Typedef is semantically a special case, but not syntactically: a type declaration looks *exactly* like a declaration of an ordinary variable except for that funny word "typedef" on the front. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
browns@iccgcc.decnet.ab.com (Stan Brown) (02/05/91)
In article <22642@netcom.UUCP>, avery@netcom.UUCP (Avery Colter) writes: > My instinct right now is telling me that > > typedef char[20] BUFFER > > is more consistent... > > But I'll take the word of the more experienced that the first def > can be done too. typedef char BUFFER[20]; is legal C. I believe that what you wrote is not legal C. The general rule for writing typedefs is: write a normal variable declaration, stick 'typedef' on the front, and the variable name becomes the type name. Thus BUFFER is the name of a type that is array (20 long) of char. Hey--this is all my opinion, nobody else's. Rely on it at your peril. email: browns@iccgcc.decnet.ab.com Stan Brown, Oak Road Systems, Cleveland, Ohio, USA +1 216 371 0043
scott@bbxsda.UUCP (Scott Amspoker) (02/06/91)
In article <1212@tredysvr.Tredydev.Unisys.COM> paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) writes: >Is the following statements legal in K&R C, and ANSI C? > typedef char BUFFER[20]; > BUFFER sb; >This seems to work on both the K&R compiler and the ANSI compiler at my work >place, but is this going to break when the program is ported? Looks good to me but you never know how bad some compilers can be. >Can anyone also tell me what is the most common style convention for type >names, I usually put them all in capitals. You're not alone here. We tend to use uppercase names for typedefs also. -- Scott Amspoker | Basis International, Albuquerque, NM | This space available (505) 345-5232 | unmvax.cs.unm.edu!bbx!bbxsda!scott |
avery@netcom.COM (Avery Colter) (02/08/91)
One of the high masters has given me a sound rapping on my shoulder
about typedefs.
So I went back to read the books I have, and guess what, they didn't
detail the typedeffing of arrays.
In fact, all they detailed were typedefs of pointer to simple objects
and of structures.
So, these two books left me with the mistaken notion that typedef
was some kind of macro with two arguments, the second being the
name of the derived type and the first being like a typecast.
Make not this mistake, fellow students,
lest the master give YOU a sound rapping.
So, for those who also might not have books
which were very clear about typedefs....
My impression now, preparing my shoulder for more, is that
typedef is tacked in front of a normal declaration in order
to have the name treated as the name of a type rather than
the name of an object, and that declaring a variable of the
derived type is equivalent to making a non-typedef declaration
exactly like that to which typedef was prepended, only with
the new variable name occurring exactly where the derived
type name was in the typedef declaration.
In other words:
type embellished-name
says "name is an object, and the application of the given embellishements
to this object yields a value of the leading type".
Note: put "tag" in place of "object" when the name refers to an
array or other composite that is not strictly an object.
So, float (*thing)(int); says, "thing is an OBJECT whose indirection
is a function of one int parameter whose result is a float".
A pointer to a float function of int.
float (*thing[23])(int); says, "thing is the TAG of a 23-member array
of objects whose indirections are tags of functions with int parameters
which return float values." Or, "23-member array of pointers to
float functions of int".
(Array names are not strictly objects, right? Like a pointer, a direct
reference to it yields an address value, but unlike a pointer the
array name's value itself cannot be changed.)
typedef type embellished-name
says "name is a type, objects of which yield values of the base type
when subjected to the prescribed embellishments".
And therefore, typedef float (*thing[23])(int); says,
"thing is NOT an object or a TAG, but a TYPE, and tags of this TYPE are
23-member arrays of pointers to float functions of int".
--
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"volpe@camelback.crd.ge.com (Christopher R Volpe) (02/08/91)
In article <23128@netcom.COM>, avery@netcom.COM (Avery Colter) writes: |>(Array names are not strictly objects, right? Like a pointer, a direct |> reference to it yields an address value, but unlike a pointer the |> array name's value itself cannot be changed.) Actually, array names do in fact refer to objects, that is, they are unmodifiable lvalues. In most contexts, a reference to it is converted to an address value (i.e. pointer to first element), but this doesn't occur if it is the operand of '&' or 'sizeof' or the left operand of '='. ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
henry@zoo.toronto.edu (Henry Spencer) (02/10/91)
In article <23128@netcom.COM> avery@netcom.COM (Avery Colter) writes: >My impression now, preparing my shoulder for more, is that >typedef is tacked in front of a normal declaration in order >to have the name treated as the name of a type rather than >the name of an object, and that declaring a variable of the >derived type is equivalent to making a non-typedef declaration >exactly like that to which typedef was prepended, only with >the new variable name occurring exactly where the derived >type name was in the typedef declaration. Essentially correct; your shoulder can relax :-). The one small addendum I would make is that there are a few circumstances which can arise only through the use of typedefs, because they are syntactically impossible in normal declarations. For example: typedef int a_t[10]; const a_t a; attempts to make a const array of int, instead of the array of const int one would get through a combined declaration. In fact, the result is the same, because there is a clause in ANSI C stating specifically that the const "falls through" in this case, affecting the inner type rather than the array as a whole. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
bhoughto@pima.intel.com (Blair P. Houghton) (02/11/91)
In article <16562@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >In article <23128@netcom.COM>, avery@netcom.COM (Avery Colter) writes: >|>(Array names are not strictly objects, right? Like a pointer, a direct >|> reference to it yields an address value, but unlike a pointer the >|> array name's value itself cannot be changed.) Perfect. >Actually, array names do in fact refer to objects, that is, they are >unmodifiable lvalues. As long as we understand that referring to an object (in this case unambiguously) and being an object are two different things. Pointers, arrays, structs, and unions are called "derived types" by the ANSI standard[*]. They can refer to object types, but can not be used in the same ways object types can be used (and vice-versa; e.g., you can't apply the '.' or '->' operators to an int). [*] functions are also derived types, but do not refer to objects. (See sec. 3.1.2.5, Types, ANSI X3.159-1989.) --Blair "After about ten years of this, you'll be able to egrep my refs to the std and sort|cat them into a complete copy...it's the 'ten years' part that scares most people."
john@IASTATE.EDU (Hascall John Paul) (03/02/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. Nice; until some standards body steals your name out from under you. Not to start ``style wars'' again, but another common scheme is: #define FOO 4 typedef struct { char f_thing; int f_thang[FOO]; } Foo; (or FooType, or fooType) Foo foo; -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50011 (515) 294-9551